Using different versions of the same assembly in the same folder

I have the following situation

Project A

 - Uses Castle Windsor v2.2
 - Uses Project B via WindsorContainer

Project B

 - Uses NHibernate
 - Uses Castle Windsor v2.1

In the bin folder of Project A I have the dll Castle.DynamicProxy2.dll v2.2 and NHibernate dlls. Now the problem is that NHibernate is dependent on Castle.DynamicProxy2.dll v2.1 which is not there. How do I resolve this situation.

Solution 1:

I used the following configuration to resolve the issue.

<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="Castle.DynamicProxy2" publicKeyToken="407dd0808d44fbdc" />
                <codeBase version="2.1.0.0" href="v2.1\Castle.DynamicProxy2.dll" />
                <codeBase version="2.2.0.0" href="v2.2\Castle.DynamicProxy2.dll" />
            </dependentAssembly>
            <dependentAssembly>
                <assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" />
                <codeBase version="1.1.0.0" href="v2.1\Castle.Core.dll" />
                <codeBase version="1.2.0.0" href="v2.2\Castle.Core.dll" />
            </dependentAssembly>
        </assemblyBinding>
    </runtime>
</configuration>

Solution 2:

One thing very, very, very important that one might miss if he is not paying enough attention.

The assembly you write in the codeBase version tag, must be strong named.

From the following link: http://msdn.microsoft.com/en-us/library/efs781xb.aspx

For assemblies without a strong name, version is ignored and the loader uses the first appearance of <codebase> inside <dependentAssembly>. If there is an entry in the application configuration file that redirects binding to another assembly, the redirection will take precedence even if the assembly version doesnt match the binding request.

Solution 3:

One solution (or workaround) would be to install both versions in the Global Assembly Cache (GAC) on the machine(s) on which your software needs to run, and reference the assemblies using their strong names. This assumes that the assemblies do indeed have strong names.

Installing into the GAC will be a pain if you have more than a few developers or if you plan to deploy your solution to many computers (eg as an end-user application). In this case, I believe (but I might be wrong) that your only option is to merge one of the two versions into the assembly requiring that version. In your specific case, you need Castle.DynamicProxy2.dll v2.1 to be merged into NHibernate.dll.

You can use a tool called ILMerge to merge the assemblies. The command you will need to run looks something like this (untested):

ILMerge /t:library /internalize /out:Deploy/NHibernate.dll
    NHibernate.dll Castle.DynamicProxy2.dll

The /internalize switch tells ILMerge to mark all types from the second assembly (Castle in this case) internal in the output assembly. Without this, you might get compile errors when you try to compile a project referencing both your new NHibernate.dll and the shelf version of Castle.DynamicProxy2.dll v2.2, as they will contain classes with the exact same names.