Targeting the .NET runtime version 2.0 matters

 

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).

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.guardian.co.uk gillianhar

    next population according thousand webmate vectors efficiency

  • http://www.shirleys-wellness-cafe.com waydelltor

    areas paper web surface gun

  • http://www.marktechopto.com aliciaivy

    newsletter biological sulfate 2007 vapor warms rise

  • http://calder.med.miami.edu saffroneds

    home decrease increasing decline next [url=http://www.isws.illinois.edu]suggests strength[/url] http://www.weather.gov

  • http://sitecore.alexiasoft.nl Alex de Groot

    For great collections, better implemented and less memory consuming, have a look at the C5 library: http://www.itu.dk/research/c5

    Btw, during the last SP of .NET(SP1 for .NET 3.5), there’s a bunch changed in the mscorlib. They didn’t tell you that they’ve installed an SP for .NET 2.0 as well. So basically, there’s always a challenge with versioning.
    We had a big issue because when we serialized a class, the whole IIS process was hanging.

  • http://www.NDepend.com Patrick Smacchia

    Jb, the Mono HashSet sounds as a good idea, do you have some performance comparison? Because my idea is that a HashSet should be more performant and less memory hungry than the Dictionary since it does the same thing but doesn’t have to bother with values.

  • http://evain.net/blog/ Jb Evain

    Oh, and for what it’s worth, if you still want to use LINQ or some fancy C# 3 stuff, while deploying on .net 2, just ship Mono’s System.Core, and csc 3.5 will have no issue using it.

    It’s also licensed under the MIT/X11, just as Cecil again, so no problem for you.

  • http://evain.net/blog/ Jb Evain

    Hey Patrick,

    Why don’t you simply take Mono’s HashSet? It’s licensed under the MIT/X11 just as Cecil, so there should be no problem.

    http://anonsvn.mono-project.com/viewvc/trunk/mcs/class/System.Core/System.Collections.Generic/HashSet.cs