Référence à 2 versions différentes de log4net dans la même solution

J'utilise NHibernate 2.1.2.400 qui fait référence à log4net 1.2.10.0. Dans le même projet, j'utilise aussi le SDK simplement comptable, malheureusement il utilise toujours log4net 1.2.9.0. Donc, je peux faire fonctionner NHibernate si je me réfère à la version 1.2.10.0 de log4net mais que le simpleSDK ne fonctionne pas. Et vice versa ...Référence à 2 versions différentes de log4net dans la même solution

Je suppose que la plupart des problèmes viennent du fait que log4net a changé sa clé d'assemblage. J'ai essayé d'utiliser une redirection de liaison sans succès: les 2 DLL n'ont pas la même clé. J'envisage de recompiler NHibernate pour utiliser log4net 1.2.9.0 mais cela semble être la mauvaise chose à faire et j'ai l'impression que Simple Comptable ne mettra pas à jour son SDK pour utiliser log4net 1.2.10.0 de sitôt.

Quelle est la meilleure façon de gérer cela? Est-il possible de résoudre du tout?

Source

2010-07-01 Joel Gauvreau

J'ai une question très similaire à http://stackoverflow.com/questions/1744543/reference-two-equal-assemblies-only-public-keys-differ J'ai eu recours à la recompilation. Je suppose que c'est l'avènement de dll-hell v2.0. –

tout en vérifiant votre question, j'ai trouvé http://stackoverflow.com/questions/2460542/2461746#2461746 qui a résolu mon problème. –

Super! Je me demandais comment faire pour que le CLR apparaisse dans différents endroits et l'attribut 'href' semble faire l'affaire. Merci d'avoir fait remarquer cela! –

127

J'ai trouvé la solution en utilisant cette answer to a similar question

Vous créez 2 dossiers dans votre un projet pour chaque version de log4net. Placez chaque fichier log4net.dll dans son dossier correspondant en ajoutant un fichier à la solution (sans ajouter de référence). Vous pouvez définir la copie sur la propriété de répertoire de sortie pour qu'elle soit toujours copiée afin qu'elle soit automatiquement copiée dans le dossier de sortie lors de la génération.

Ensuite, vous modifiy le fichier app.config en ajoutant quelque chose comme ceci:

<configuration> 
    <runtime> 
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
     <dependentAssembly> 
     <assemblyIdentity name="log4net" publicKeyToken="681549d62126b7b8" /> 
     <codeBase version="1.2.9.0" href="log4netv1.2.9.0\log4net.dll" /> 
     </dependentAssembly> 
     <dependentAssembly> 
     <assemblyIdentity name="log4net" publicKeyToken="1b44e1d426115821" /> 
     <codeBase version="1.2.10.0" href="log4netv1.2.10.0\log4net.dll" /> 
     </dependentAssembly> 
     <dependentAssembly> 
     <assemblyIdentity name="log4net" publicKeyToken="669e0ddf0bb1aa2a" /> 
     <codeBase version="1.2.11.0" href="log4net.dll" /> 
     </dependentAssembly> 
    </assemblyBinding> 
    </runtime> 
</configuration>

vous pouvez obtenir le jeton de clé publique d'un ensemble en utilisant sn -T [assemblyName]

Source

2010-07-02 03:11:02

Cela semble fonctionner pour moi aussi. J'ai supprimé log4net de ma liste de références pour le projet où le conflit se produisait. En outre, puisque log4net.dll n'est pas dans mes dossiers bin, mes chemins href ressemblaient plus à ".. \ .. \ .. \ Lib \ NHibernate-2.0.1.GA \ log4net.dll" - juste un chemin relatif à où log4net sera sur la machine de chaque dev avec notre système de construction. – apollodude217

+12

Je ne suis pas sûr d'avoir ceci: comment ne pas compiler des erreurs si log4net n'est pas référencé? – guidupuy

@guidupuy Je pense que cela peut être simplement une dépendance d'une référence. C'est pourquoi il peut compiler sans la référence et toujours travailler à l'exécution. – cdpnet

Si la redirection de liaison ne fonctionne pas et que le SDK simplement comptable est une source fermée, une solution possible consiste à recompiler NHibernate pour utiliser log4net 1.2.9.0.

Source

2010-07-01 17:28:43

Cela fonctionnerait, mais avoir à construire une version spéciale de nhibernate serait plus difficile à supporter sur toute la ligne ... merci. –

Vous pouvez ajouter une exclusion au registre. Il suffit d'ajouter ces clés:

HKEY_LOCAL_MACHINE\Software\Microsoft\StrongName\Verification\log4net,681549d62126b7b8 
HKEY_LOCAL_MACHINE\Software\Microsoft\StrongName\Verification\log4net,1b44e1d426115821 
HKEY_LOCAL_MACHINE\Software\Microsoft\StrongName\Verification\log4net,669e0ddf0bb1aa2a

Cela rendra le temps d'exécution .net Ignorer la validation pour les ensembles énumérés. En théorie, il s'agit d'un problème de sécurité, mais comme la clé privée est ouverte de toute façon, il n'y a pratiquement aucun impact.

Source

2016-02-04 09:25:53

Si vous downvote, au moins avoir le courage de dire à haute voix pourquoi. Ma réponse est une réponse légitime à la question et résout en fait le problème. –

Comme vous l'avez dit, c'est un problème de sécurité. En outre, cela implique que vous devez les modifier sur chaque poste de travail qui exécute le logiciel. Dans un réseau d'entreprise complexe, ce genre de choses s'ajoute pour faire un énorme gâchis. Je préfère l'éviter autant que possible. Les autres solutions sont autonomes et portables. –

Comme je l'ai dit, parce que les clés privées sont publiquement disponibles de toute façon, il n'y a aucun problème de sécurité réel du tout. Surtout dans un réseau d'entreprise, il serait plus facile de configurer un seul objet de stratégie de groupe que de le configurer pour chaque application métier utilisée. Vous pouvez le configurer une fois au niveau du domaine et ne plus jamais y penser. –

Référence à 2 versions différentes de log4net dans la même solution

Répondre

Questions connexes