0

ちょっとした背景: アプリケーションのさまざまな部分から参照される 3 つのコア DLL を使用するアプリがあります。これら 3 つの DLL は GAC にあります。テスト環境には、3 つのテスト Web サイト (同じ Web サイト、異なるバージョン) があり、すべて GAC の DLL と、bin\.

製品の 1 つでこれらのコア DLL の更新が必要な状況に遭遇しましたが、特定のテスト Web サイトがこれらの DLL を参照する唯一のものだったため、アセンブリを GAC に配置したくありませんでした。アセンブリの複数のバージョンを GAC に配置できることは認識していますが、これを行わないことを選択したため、この特定の質問とは関係ありません。

私自身の調査では、回答に非常に自信を持っているように見える多くの人々が示されましたが、それらのほとんどは、実行時のアセンブリの配置に関して異なっていました。多くの人は、GAC が優先されると言いましたが、私自身の経験ではそうでした。他の人は、アセンブリに厳密な名前が付けられていない限り、GAC よりも bin\ を優先すると言いましたが、これは私の経験では正しくありませんでした。

このMSの記事を見つけました：

ランタイムがアセンブリを見つける方法

これは、バインドするアセンブリを決定するために CLR が実行する手順を説明しています。これは、期待どおりに動作しないことが判明しました。これらはすべて、環境問題である可能性が非常に高いです (実際、私はそのように考えます)。

また、これまで読んだ他の質問と似ているが、必ずしも必要な答えではないこのSOの質問も見つけました

最終的に、GAC よりも bin\ を優先する回避策を見つけました。web.config でタグを使用しました。私は、これが SO や他のサイトで断続的に成功することを示唆しているのを見て、私の場合にうまくいったことを嬉しく思いました。

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="dll1" publicKeyToken="ourToken" 
                culture="neutral" />
            <bindingRedirect oldVersion="5.0.0.0" newVersion="5.0.1.0" />
        </dependentAssembly>
    </assemblyBinding>
</runtime>

バージョン 5.0.1.0 は私の bin\ フォルダーにあります。5.0.0.0 は GAC にあります。最後に私の質問ですが、5.0.1.0 は GAC のアセンブリではありませんが、バインド先の正しいアセンブリを見つけるために bin\ を調べる必要があることを CLR はどのように認識していますか? .config にタグを追加する前は、プロジェクトがビルドされたアセンブリ バージョン (5.0.1.0) に関係なく、アプリケーションは GAC の古いバージョンの DLL (5.0.0.0) を優先していました。

これに関するドキュメントを見つけることができませんでした。おそらく、この 5 段落の説明を検索クエリに分解する方法がわからないためです。CLR が何をしているのかを理解できるように、参考資料をいただければ幸いです。

4

1 に答える 1

2

アセンブリの特定の名前とバージョンを検索して、常に最初に GAC を調べます。見つからない場合は、プローブ パスでアセンブリを探します。アセンブリの特定の名前のみを検索します。見つかったら、バージョンが一致するかどうかを確認します。そうでない場合はカブーム。

したがって、最初は常に "dll1" + 5.0.0.0 を探し、GAC で見つけました。他の場所を探しに行く必要はありません。

.config ファイルを変更すると、GAC で "dll1" + 5.0.1.0 が検索されるようになります。そして、そこにそれを見つけません。「dll1」を探しに行き、bin ディレクトリで見つけます。バージョンが一致して嬉しいです。

于 2013-04-01T16:54:18.023 に答える