. The DLL Hell in net and its solution

Suppose such a scenario, a company launched two software (called A1 and A2), the two software references the same common assembly (Common.dll), while A1 and A2 are used in Common.dll () method, Now the user installs the two software to their own system separately. At this point the public assembly is copied to a user's path, so it can be referenced by two software simultaneously. After some time, the company upgrades the software A2, the upgrade process needs to modify the Common.dll in the GetMessage1 () function name, renaming it to GetMessage2 (). When the user downloads the A2 software for installation, Common.dll is downloaded and installed to the previous public folder and overwrites the original version of Common.dll. Now the problem, A2 in the user can run normally, but A1 not. Because GetMessage1 () in Common.dll does not already exist, an exception is thrown when running A1.

The following code simulates what happens above.

At first we create a new Common.dll assembly:

     Public Static class Tool    {        publicstaticstring  GetMessage1 ()        {            return " Hello world! " ;        }    }

To create a new console program named T1, we will just generate a Common.dll copy to A1 's Bin directory, and let A1 add a reference to it:

namespace a1{    class  program    {        staticvoid Main (string [] args)        {            Console.WriteLine (Common.Tool.GetMessage1 ());     }}}

The A1.exe has been Commo.dll copied to a separate folder (MyFolder) after the program has been compiled and the A1 can run normally.

We then create a A2 console program in the same way, adding a reference to the Common.dll:

using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace a2{    class  program    {        staticvoid Main (  String[] args)        {            Console.WriteLine (Common.Tool.GetMessage1 ());            Console.ReadLine ();     }}}

At this point, we copy the A2 and Common.dll to the myfolder. At this point under MyFolder run A1 and A2 respectively, found that they are able to run normally.

Now we want to simulate software A2 upgrade. We renamed the GetMessage1 () in the Commo.dll program code to GETMESSAGE2 () and changed the code in A2 to call the GetMessage2 () function. Compile the Common.dll and A2 projects separately.

Common.dll Code:

namespace common{    publicstaticclass  Tool    {        public   Staticstring  GetMessage2 ()        {            return"Hello World" ! " ;        }    }}

Change the A2 code to:

namespace a2{    class  program    {        staticvoid Main (string [] args)        {            Console.WriteLine (Common.Tool.GetMessage2 ());            Console.ReadLine ();     }}}

After compiling common and A2, the Common.dll and A2.exe are copied/overwritten into MyFolder respectively. At this point in the myfolder we will find that A2 can run normally, A1 throws an exception:

The reason is simple, because GetMessage1 has been renamed GetMessage2 when A2 is upgraded, and the A1 runtime throws an exception, of course.

So how do we solve this problem? The answer is: we can version the common, name it strongly, and then deploy the common to the GAC. Each time we make a change/upgrade to common, we add a version number, different software reference different version. Although common's name remains the same, the version number changes every time it is published, and for the GAC they are different assemblies.

Now let's go back to the very beginning, when the function name in common is still GetMessage1, and we strongly type-sign the assembly. The steps are:

1) Right-click the Assembly Selection property (properties) and select signature (Signing)

2) Tick the signature of this assembly (sign the Assembly) and select New from the drop-down list

3) give the key a name in the pop-up box and click OK

So we signed Common.dll a strong type name, and then we need to deploy the Common.dll to the GAC. We can use the command-line tool provided by VS and then deploy it to the GAC with the Gactuil-i command.

Then follow the same steps to have both A1 and A2 add a reference to the Common.dll, which is exactly the same as in the first place above.

Copy the A1 and A2 into the MyFolder, Because A1 and A2 have added Common.dll references, and Common.dll has been deployed to the GAC, you do not need to copy Common.dll to MyFolder because A1 and A2 will find the assembly from the GAC. At this point A1 and A2 are fully functional.

Now all we have to do is simulate the A2 upgrade and modify the Common.dll.

or change the GetMessage1 in common to GetMessage2. Then open Common's AssemblyInfo and change [Assembly:assemblyversion ("1.0.0.0")] to [Assembly:assemblyversion ("2.0.0.0")]. The purpose of this is to change the common to 2.0, to differentiate the previous version. The common is also deployed to the GAC.

Also add a reference to the new version of common in A2 and update the A2 code to use the GetMessage2 version.

namespace a2{    class  program    {        staticvoid Main (string [] args)        {            Console.WriteLine (Common.Tool.GetMessage2 ());            Console.ReadLine ();     }}}

Then copy the A2.exe to the myfolder. Now, under Myfloder, A1.exe refers to GetMessage1 and A2.exe uses GetMessage2, but they refer to Common.dll with the same name, except A1 and A2, which are referenced by different versions. This is A1 and A2 are all working properly.

And in the GAC, we can see that there are two versions of Common.dll

. The DLL Hell in net and its solution