As explained in my previous post about NDepend v2.10.0, this release needed the .NET v3.5 runtime installed to be executed. This is because we are now relying on the library MsAgl for graph layout and drawing and this library needed .NET v3.5. However by analyzing this library with NDepend, we figured out that few methods were dependent on .NET v3.5.

Hopefully, the MsAgl developer Lev Nachmanson was VERY nice and refactored its code to get rid of .NET v3.5 dependency. So I am glad to announce that the new version NDepend v2.10.1 is available and only need .NET Framework v2.0 (or higher) installed.

What’s the lesson learned? First, when we took the decision of depending on MsAgl, we were a bit too quick and didn’t notice this v3.5 dependency issue. When we noticed it, we already had many weeks of development invested and it was too late to think of another library, especially considering that amongst all .NET Graph libraries MsAgl is by far the most compelling choice. Thanks to the MsAgl developer the story ended well. But depending on tier code is always an intrusive decision that must be taken very carefully.

Second lesson learned, amongst all users that downloaded and installed v2.10.0, one complained that he wasn’t able to use this new version. Indeed, he explained us that he was not able to upgrade the .NET framework installed on its company development machines. Here is an excerpt of his mail:

It's our internal policy to keep development machines' runtime environment aligned with production machines environment. This means developing only for the runtime version that users have on their machines when automatically updating by means of windows update.

This is because we can't risk to sell a product to a customer that doesn't want to upgrade his server. Avoiding the runtime update is safer than simply avoiding to install the ultimate SDK version. Moreover installing early versions of new Microsoft releases caused us some troubles in the past, because of bugs fixed in subsequently released service packs. So we prefer to wait a little bit. I know that it might seem quite exaggerate (it seems to me too) but I know that I must trust bad experiences more than my feelings :)

I chose to manage my group in this way under some pressure from my boss to adopt such kind of policies.

I completely agree with this point of view, even thought the .NET v3.5 core contains many appealing new features and turned to SP1 recently. According to me the step from .NET 1.1 to .NET 2.0 was more important than the one from .NET 2.0 to .NET 3.5 (I am not talking about WPF, WCF… but just of the core of the .NET platform, mscorlib, System…). With .NET 2.0, the platform and the tools gained maturity and indeed .NET really became mainstream in 2005/2006. Actually, the .NET 2.0 runtime is so mature that it was barely changed if you compare it with .NET v3.5 runtime. With .NET 2.0, it became more appealing to start a new project with .NET than Java (IMHO). Finally, thanks to its integration with Windows Vista, the .NET 2.0 runtime got quickly deployed on almost all machines on earth. And as a bonus since Visual Studio 2008, the IDE can be used to develop programs that target .NET v2.0. So, targeting .NET v2.0 doesn’t mean that you have to discard all innovations made in development tools and even language.

For all these reasons, targeting .NET v2.0 runtime matters for all ISV that wish to deploy their product on a wide range of machines. For an ISV like us, that is developing tools for .NET developers, it is even more important because developers have solid reasons not to upgrade their machines. We (the NDepend team) will do our best to continue depending on .NET v2.0 for at least one more year.

Personally, my biggest regret from not using .NET v3.5 features is that I cannot use the class System.Collections.Generic.HashSet<T>. I am a big fan of hash table and I am often forced to use a Dictionary<K,V> where HashSet<T> could have been used. I even thought of integrating the code of HashSet<T> in our helpers code but it wouldn’t be legal wouldn’t be? (btw, any information on this point is welcomed).