This article explains how .Net framework takes care of the compatibility issues of the Assemblies with the help of the assembly manifest, version number, strong names, Gac registerations. Before reading this article you are suggested to go through my previous article about Private and Shared Assemblies.
Understanding Assembly's Compatibility Structure
You may remember that while using VB6.0 the DLL HELL problem was very much on the cards whenever you change anything in your DLL want to register it again. It can be eliminated by using the Assembly manifest version information fields. The problem was that a client was simply tied to a particular DLL as in VB6.0 witht he Dll Name. If a new application Dll will be replaced with another DLL that is used by another application, then there was always a possibility that the replaced DLL would not behave properly with the older application until and unless it would contain all those functionalities.
The .NET solution to this is that every assembly has version information carried in the manifest, thus the assembly information for a particular application will carry the dependency information for the particular objects used and within this dependency the manifest of the DLL's that form the objects assembly will be identified and the unique version required for the application will be stored in the manifest for the application in the form of Compatibility Version Numbers . This means that when the client starts to access the assembly, the relevant assemblies are taken together from the GAC and since the GAC can contain different versions of the same assembly with the help of a Strong Name as the Strong Name is the unique identifier, and not identify it with the file name so now the loader can find the exact version needed. Of course this is why the GAC has to have specialist tools to manipulate the files stored since we now have Assembles that have the same name but different versions and different Strong Names.
The compatibility version number is in the following form: Each assembly contains a version number in the form of incompat.compat.hotfix. A change in the incompat portion of the version number means that the new version is not compatible with prior versions. A change in the compat portion of the version number means that this is intended to be compatible with prior versions that share the same incompat version number. A change in the hotfix portion of the version number means that, yes, you've made a change, but it should be considered essentially the same bits as the prior version. The .NET common language runtime then uses this information in making binding decisions.
Hope this will clear everything about DLL Hell.
--------------------------
EnJOY :)
Puneet
|
| Author: Brad oyler 26 Aug 2004 | Member Level: Bronze Points : 0 |
Very informative. However, it may be interesting to also point out the issues that the .Net framework may present in the future with the CLR constantly being upgraded to new versions. I can definitely forsee some versioning hell as well, but I feel is a great tradeoff.
|