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
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
I chose to manage my group in this way under some pressure from my boss
to adopt such kind of policies.
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
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).