Jochen Kalmbach's WebLog

Moving from DLL-Hell to .NET-Framework-Hell

Several years ago, Microsoft addmitted that they had introduced a so called “DLL-Hell” with the concept of DLLs. They decided to add versioning and SxS to help solve this issue with DLLs.

And with the .NET Framework they told us, that now the DLL hell is over forever… They announced articles like Simplifying Deployment and Solving DLL Hell with the .NET Framework
Most people really belived it; and, no doubt, it really helped to solve many problems (ok, it introduced some minor problems like manifest-files; but this is ok).

But with the .NET-Framework they started to make a similar ”.NET-Framework Hell”. The started with version 1.0, moved to version 1.1 and two month ago, they indroduced version 2.0. And the Framework-Hell really started again.
Running a assembly build with v1.0 on v1.1 is not a big problem. Also in most cases a assembly build for v1.1 can mostly run on v1.0. It is also acceptable that you need to have the new .NET-Framework v2.0 to run apps build with v2.0 (this is what we all expected).

But the really problem is: Some people or companies had build assemblies which exposes native interfaces to other applications, like TWAIN-drivers, on to of the .NET-Framework. And now the problem begins.
These DLLs will be loaded into the EXE and if the EXE already uses the .NET-Framework, the newly loaded DLL must also use the current loaded version of the framework, because it is impossible to load two versions of the .NET-Framework into one process!
So if you build your DLL for version 1.1 and the host-process is build for version 2.0, your DLL will operate against the v2.0 framework! The other way is almost impossible: you can´t build your DLL for v2.0 and run it in an application which uses v1.1.
This is also a reason why global hooks can´t use the .NET Framework.

Also you have the same problem with COM-Interop. If you register your .NET-assembly with regasm .If the EXE uses for instance a second COM object (which uses the .NET-Framework v1.1) and also tries to load your COM objet after loading the other one, then your assembly fails to load if your assembly was compiled aginst v2.0. This is really the biggest point in the .NET-Framework-Hell.

I don´t know what MS is planning to find a solution to this problem…