同じソリューションで2つの異なるバージョンのlog4netを参照する


80

log4net1.2.10.0を参照しているNHibernate2.1.2.400を使用しています。同じプロジェクトで、単純なアカウンティングSDKも使用していますが、残念ながら、まだlog4net1.2.9.0を使用しています。

したがって、log4net 1.2.10.0を参照すれば、NHibernateを機能させることができますが、simplySDKは機能しません。およびその逆...

問題のほとんどは、log4netがアセンブリキーを変更したことに起因していると思います。バインディングリダイレクトを使用しようとしましたが成功しませんでした。2つのDLLに同じキーがありません。

NHibernateを再コンパイルしてlog4net1.2.9.0を使用することを検討していますが、それは間違っているように思われます。SimplyAccountingはSDKを更新してlog4net1.2.10.0を使用する予定はありません。

これを処理するための最良の方法は何ですか?解決することは可能ですか?


2
私はstackoverflow.com/questions/1744543/で非常によく似た質問があります…私は再コンパイルに頼りました。これはdll-hellv2.0の登場だと思います。
サンドールDrieënhuizen

1
あなたの質問をチェックしている間、私は私の問題を修正したstackoverflow.com/questions/2460542/2461746#2461746を見つけました。
Joel Gauvreau 2010

すごい!私はCLRをさまざまな場所で見せるのかと思っていましたが、href属性がうまくいくようです。それを指摘してくれてありがとう!
サンドールDrieënhuizen

回答:


149

同様の質問に対するこの回答を使用して解決策を見つけました

log4netのバージョンごとに1つずつ、プロジェクトに2つのフォルダーを作成します。ファイルをソリューションに追加して(参照の追加ではなく)、各log4net.dllを対応するフォルダーに配置します。ビルド時に出力フォルダーに自動的にコピーされるように、copy to outputdirectoryプロパティを常にコピーするように設定できます。

次に、次のようなものを追加して、app.configファイルを変更します。

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

sn -T [assemblyName]を使用して、アセンブリの公開鍵トークンを取得できます。


2
これは私にもうまくいくようです。競合が発生していたプロジェクトの参照リストからlog4netを削除しました。また、log4net.dllがbinフォルダーにないため、hrefパスは「.. \ .. \ .. \ .. \ Lib \ NHibernate-2.0.1.GA \ log4net.dll」のようになりました。ビルドシステムを使用するすべての開発者のマシンでlog4netが配置される場所への相対パス。
jyoungdev 2010年

12
私はこれを取得するかどうかわかりません:log4netが参照されていない場合、どのようにしてコンパイルエラーが発生しませんか?
guidupuy 2012

2
これは素晴らしいです、それは単純なバインディングリダイレクトがAPIの変更のために物事を壊す他のケースも修正するでしょう!
Rhys Bevilaqua 2014

5
@guidupyは、コードが使用するlog4netを参照できますが、プロパティでcopyLocalをオフにします。
ジェフマーティン

4
将来の読者のために(別の回答から見つけたヒントですが、ここに投稿するのが賢明です)... Webアプリケーション(asp.net)の場合、参照には微調整があります:<codeBase version = "1.0.0.0" href = "bin \ folder \ namedll.dll "/>
granadaCoder 2018年

7

レジストリに除外を追加できます。次のキーを追加するだけです。

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

これにより、リストされたアセンブリの.netランタイムスキップ検証が行われます。理論的にはこれはセキュリティの問題ですが、とにかく秘密鍵が公開されているため、影響はほとんどありません。


あなたが言ったように、これはセキュリティの問題です。また、この問題は、ソフトウェアを実行するすべてのワークステーションでこれらの変更を行う必要があることを意味します。複雑なエンタープライズネットワークでは、これらの種類のものが合計されて大きな混乱を引き起こします。なるべく避けたいです。他のソリューションは、自己完結型でポータブルです。
Joel Gauvreau 2016

私が言ったように、秘密鍵はとにかく公開されているので、実際のセキュリティの問題はまったくありません。特にエンタープライズネットワークでは、使用中のすべてのLOBアプリケーションに対してこれを構成するよりも、単一のグループポリシーオブジェクトを構成する方が簡単です。ドメインレベルで一度設定すれば、もう一度考える必要はありません。
Joep Beusenberg 2016

3

バインディングリダイレクトが機能せず、単純なアカウンティングSDKがクローズドソースである場合、考えられる解決策は、log4net1.2.9.0を使用するようにNHibernateを再コンパイルすることです。


3
それはうまくいくでしょうが、nhibernateの特別なバージョンを構築しなければならないことは、将来的にサポートするのが難しいでしょう...ありがとう。
Joel Gauvreau 2010
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.