How the .NET Framework helps to get rid of the DLL Hell Problem? Articles, samples and tutorials

How the .NET Framework helps to get rid of the DLL Hell Problem?

Posted Date: 14-Jun-2004	Category: .NET Framework
Author: Puneet	Member Level: Silver	Points: 10

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.

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

Post Comment:

Notify me by email when others post comments to this article.

Do not include your name, "with regards" etc in the comment. Write detailed comment, relevant to the topic.

No HTML formatting and links to other web sites are allowed.

This is a strictly moderated site. Absolutely no spam allowed.

Name:	Sign In to fill automatically.
Email:	(Will not be published, but required to validate comment)
	Type the numbers and letters shown on the left.

Online Members

How the .NET Framework helps to get rid of the DLL Hell Problem?

Post Comment:

Email subscription