Utilisation de différentes versions du même assemblage dans le même dossier

Question

J'ai la situation suivante

Projet A

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

Projet B

  - Uses NHibernate
      - Uses Castle Windsor v2.1
 

Dans le dossier bin de Project AI, vous avez les dll Castle.DynamicProxy2.dll v2.2 et les dll NHibernate. Maintenant, le problème est que NHibernate dépend de Castle.DynamicProxy2.dll v2.1 qui n’est pas là. Comment puis-je résoudre cette situation.

Answer 1

J'ai utilisé la configuration suivante pour résoudre le problème.

 <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>
 

Answer 2

Une chose très, très, très important, que l'on pourrait manquer si il n'est pas assez d'attention.

L'assemblée vous écrire dans la base de code balise de version, doit être fort nommé.

À partir du lien suivant: http://msdn.microsoft.com/en-us/library/efs781xb.aspx

Pour les assemblages sans nom fort, version est ignoré et l' chargeur utilise la première apparition de l'intérieur . Si il y a une entrée dans l'application fichier de configuration qui redirige la liaison à une autre assemblée, le la redirection sera prioritaire, même si la version de l'assembly ne marche pas correspondre à la demande de liaison.

Answer 3

Une solution (ou une solution de contournement) serait d'installer les deux versions dans le Global Assembly Cache (GAC) sur la machine(s) sur lequel votre logiciel a besoin de courir, de référence et assemblées à l'aide de leurs noms forts. Cela suppose que les assemblées n'ont, en effet, les noms forts.

L'installation se fait dans le GAC va être une douleur si vous avez plus d'un peu de développeurs ou si vous envisagez de déployer votre solution à de nombreux ordinateurs (par exemple un utilisateur final de l'application). Dans ce cas, je crois (mais je peux me tromper) que votre seule option est de fusionner l'un des deux versions dans l'assemblée exigeant que version. Dans votre cas particulier, vous avez besoin d' Castle.DynamicProxy2.dll v2.1 pour être fusionnés en NHibernate.dll.

Vous pouvez utiliser un outil appelé ILMerge de fusionner les assemblées. La commande que vous aurez besoin pour exécuter ressemble à quelque chose comme ceci (non testé):

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

L' /internalize commutateur indique ILMerge pour marquer tous types à partir de la seconde assemblée (le Château dans le cas présent) internal à la sortie de l'assemblée. Sans cela, vous risquez d'avoir des erreurs de compilation lorsque vous essayez de compiler un projet de référencement à la fois votre nouveau NHibernate.dll et la durée de la version de Castle.DynamicProxy2.dll v2.2, car elles contiennent des classes avec exactement les mêmes noms.

Answer 4

Je ne pense pas que la solution de Hemanshu Bhojak soit bonne car vous ne voulez pas charger deux versions du même assemblage dans le même contexte. Cet article explique pourquoi:

http://msdn.microsoft.com/en-us/library/dd153782.aspx#avoid_loading_multiple_versions