.Net framework versions and dll hell

With .net version numbers increasing and increasing I recently encountered something which reminded me of dllhell. Which the .net framework promised to end. The nice part is that it already shows up at build time. Not at run time, leading to disappointed customers. Framework versions can be mixed in one solution. Up to the moment one assembly references another assembly built against a higher version. At this moment the VS build process starts to lose track.

The catch is that it’s not always clear you’re mixing framework versions in a solution. Adding a new project will default against the newest framework version. Which is not constant over a solution’s life time. The result can be quite strange. I managed to get away with a circular reference which was not seen because one project was using a version of the other built against an older framework version. And was thus considered a different assembly. Up to the moment I checked the framework version of all projects.

The only good way to solve this descend into hell would be having all projects in the solution on one version. In a big solution with a lot of projects this can be quite tedious. I would love to be able to set the version on the solution level. Or else to have a nice ‘refactoring’ tool to the work for me. R# are you listening ?


This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Erwinus

    Run into the same problem, download a LITTLE app (just a couple of Kbs) and need a framework version I don’t have. To install it, you have to search it yourself that can be lead into frustration (version hell). It is a LITTLE app but needs allot of bullshit around it. After installing the framework it needs updates (look like endless updates). This is not very userfriendly and insane way to deploy an app. Now i understand why Windows is that huge and now I know why there are so many bold hairless men in the world. Think twice to use .NET for your products.

  • http://callumbaird.weebly.com/1/post/2013/06/net-development-is-a-very-worthwhile-business-venture-that-has-highly-improved-the-skills-of-developers-of-the-platform.html Richard Stone

    An interesting discussion is worth comment. I thinks you should write more on this topic, it might not be a taboo subject but generally people are not enough to speak on such topics. To the next.

  • PeterGekko

    Thanks everybody for chiming in and all nice tools. I guess I’ll have to dive into ms-build and creating R# extension to complete the picture ? Would be nice. Given the time :)

  • Rosencreuz

    Versioning concept of the .NET framework is really very complex and difficult to understand. There’s a big need for a simple and easy to understand concept. One of the problems I’ve experienced was about compatibility. We implemented a library with latest version of the .NET Framework. This library was used in an application which was build in an earlier version. Normally, you would expect that it wouldn’t work. But it’s not the case. If latest version of the .NET Framework is installed on the machine, the dependency works fine (which is the case for the developer and test machines). However if latest framework version is not installed, you get an exception (this usually happens in production). This concept is very complex and unintuitive.

  • dingwallr

    It won’t solve all the problems but if anyone finds it useful I wrote a small cmd line tool to detect framework version and architecture mismatches between compiled .net libs: https://github.com/rdingwall/dotnetlibcheck

  • Richard Gardiner

    There is a VS2012 extension – Target Framework Migrator that lets you “Change all your .Net projects Target Framework at once”. I’ve not tried it :-)


  • Shaun Becker

    A lot of times, I will have all of my projects import a common msbuild script to set things like the framework version, product version, and signing key. This allows you to change the framework version in one place and ensures that all projects are consistent.

  • http://blog.decayingcode.com/ Maxime Rouiller

    It can get worse. Let’s say I use log4net for a console service. So I create a new Console project to host the service, then I install topshelf and log4net using NuGet. I start coding and then I realise that my console project is in “client profile”. So I change the project to the full .NET 4.0 framework and recompile. Everything now works. Right?

    Well not exactly. Basically, if you used log4net in another project than that console app, you now have 2 version of log4net. One that is the full .NET 4.0 version and another one that is the .NET 4.0 Client Profile version. The only way to fix that issue will be to uninstall log4net from the console app and reinstall it again. But otherwise, NDepend sees that as 2 different assemblies. I don’t know if there is anything major for log4net between the client profile and the full profile but I can easily see some differences in other kind of third-party libraries.