5

とを使用してアセンブリの読み込みを混在させると、奇妙な動作が発生しAssembly.LoadFromますAssembly.Load

Assembly.LoadFromでアセンブリをロードし、後で でアセンブリをロードするときに、奇妙な動作に遭遇しましたAssembly.Load。を使用してアセンブリをロードしてAssembly.LoadFromいます。アセンブリは、実行フォルダーではないフォルダーにあります。

後でテストコードで、このアセンブリをもう一度ロードしようとすると、アセンブリが既にロードされているにもかかわらず、(「ファイルまたはアセンブリをロードできませんでした...」)Assembly.Loadでロードが失敗します。System.IO.FileNotFoundException読み込みは、厳密な名前と厳密でない名前の両方で失敗します (このアセンブリを再び読み込む本来の理由は、 の使用ですBinaryFormatter)。

ただし、アセンブリが実行フォルダーに配置されている場合、厳密な名前と厳密でない名前の両方の場合で、後の読み込みは成功します。この場合、2 つの同一のアセンブリが 2 つの異なる場所から読み込まれていることがわかります。

この問題を再現する簡単なコード サンプル:

Assembly assembly1 = Assembly.LoadFrom(@"C:\a.dll");

// Loading with a strong-name fails
Assembly assembly2 = Assembly.Load(@"a, Version=1.0.0.0, Culture=neutral, PublicKeyToken=14986c3f172d1c2c");

// Also loading with a non-strong fails
Assembly assembly3 = Assembly.Load(@"a");
  1. CLR が既に読み込まれたアセンブリを無視する理由は何ですか?
  2. どうすればこの問題を軽減できますか?
4

2 に答える 2

9

それは変ではありません。ドキュメントによると、Load および LoadFrom でロードすると、アセンブリが異なるコンテキストに配置されます。これは役立つかもしれません。

  1. CLR が既に読み込まれたアセンブリを無視する理由は何ですか?

彼らは異なる文脈にいるからです。

  1. どうすればこの問題を軽減できますか?

同じコンテキストから読み込むか、CLR がアセンブリを見つけられるようにします。たとえば、ハンドラーを にアタッチしAppDomain.AssemblyResolveます。

アセンブリをロードする場所が AppDomain.BaseDirectory の下のサブフォルダーである場合は、App.config にエントリを追加するだけです。

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <probing privatePath="bin;bin2\subbin;bin3"/>
      </assemblyBinding>
   </runtime>
</configuration>

http://msdn.microsoft.com/en-us/library/823z9h8w.aspx

于 2009-01-06T13:20:03.447 に答える