2

私の問題：

1.0.0.0 としてバージョン管理された署名済みアセンブリ A.dll があります。A.dll を参照する別のアセンブリ (B.dll としましょう) があります。

両方のアセンブリが問題なく読み込まれると、両方のアセンブリが正常に読み込まれます。A.dll のバージョンが 1.0.0.1 に変更され、再コンパイルされた場合、B.dll を再コンパイルする必要がありますか?

A.dll のバージョンが変更された後、B.dll をロードしようとして次の例外を受け取るという正確なシナリオがあるため、私は尋ねます。

Unhandled Exception: System.IO.FileLoadException: 
    Could not load file or assembly A, Version=1.0.0.0, 
    Culture=neutral, PublicKeyToken…

これにより、この質問に対する答えは常にイエスだと思います。ただし、上記の正確なシナリオを持つ 2 つのアセンブリがあり、アセンブリの読み込みに問題がない別の例があります。

この例外の原因となるシナリオ/条件は何ですか? 誰かがこれについて何らかの洞察を提供できれば、それは大歓迎です。ありがとう。

4

2 に答える 2

2

アセンブリに厳密な名前が付けられている場合、それを参照するものはすべてその特定のバージョンを探します。

Visual Studio の「特定のバージョン」がランタイムに影響を与えないことは間違いありません。実際、「特定のバージョン」とは、基本的に「ビルドを実行するときに、MSBUILD が参照されたバージョンを見つけられない場合、ビルドは失敗するべきか、それともファイルシステムで見つかる次のバージョンを使用するべきか?」という意味です。

A を再コンパイルして (アプリケーションを完全にロールアウトするのではなく) 部分的な更新としてデプロイする場合、古いバージョンを参照するものがアプリケーションにあると、古いバージョンのも利用可能です (つまり、上書きしませんでした)。

これが、一部の製品が GAC を使用する主な理由です。同じファイルの異なるバージョンを bin フォルダーに展開しようとした場合 (ファイル名が同じであると仮定した場合)、同じ DLL の複数のバージョンを互いに上書きすることなく保持できるためです。 、通常はそうします)、それらは互いに上書きし、製品内の DLL は 1 つだけになります!

できるもう 1 つのトリックは、「再バージョン化された」DLL をバイナリ ディレクトリの下のサブフォルダーに配置し、app.config を編集してランタイムにそれらの場所を伝えることです。 http://support.microsoft.com/kb/837908

つまり、厳密に名前が付けられたアセンブリは、単なる名前以上のものを使用してアセンブリの ID を決定します。そのバージョンを変更することは、その名前を完全に変更することと考えることができます。

于 2011-10-26T03:17:38.827 に答える
1

アセンブリAが署名されているかどうかは必ずしも重要ではありません。プロジェクトBのAへのアセンブリ参照で「特定のバージョン=true」でコンパイルしましたか？その場合、CLRは厳密なルールを使用して、特定のバージョンのAが受け入れ可能かどうかを判断します。そうでない場合、CLRはそれほど厳密ではないルールを使用するため、Aがバージョンをインクリメントする場合は再コンパイルする必要はありません。

環境によっては、Aが将来のバージョンで互換性を損なうことを心配しないかもしれません。気にならない場合は、アセンブリ参照を「特定のバージョン=false」に変更する必要があります。（職場では、両方の状況があります。たとえば、サードパーティのコントロールに依存している場合、通常は「特定のバージョン= true」を強制しますが、社内の共有コンポーネントを使用している場合は、これを使用するアプリケーションでは、「特定のバージョン= false」であることを確認して、再コンパイルする必要がないようにします。）

特定のバージョンに対してコンパイルする必要があるが、後でバインディングをリダイレクトしたい場合に、構成ファイルを介してこれを回避する方法など、詳細については、MSDN：アセンブリバージョンのリダイレクトを参照してください。

お役に立てば幸いです。

于 2011-10-15T05:34:10.000 に答える