多くのdllを含む.net 3.5アプリケーションがあり、アプリケーション全体をビルドせずに特定のdllを再構築しようとしましたが、古いものを新しいものに置き換えた後、新しいdll例外をロードできなかったため、アプリケーションは例外をスローしました: System.IO .FileLoadException: ファイルまたはアセンブリを読み込めませんでした ....特定のバージョンとパブリック トークンを使用してアセンブリを検索することは理解していますが、アプリケーションを再度ビルドせずにこの問題を解決するにはどうすればよいですか? また、アプリケーションは署名されていますが、GAC に登録されていません。PS: アプリのビルドを再度スキップするにはどうすればよいですか? または、dll が再ビルドされるため必須です。
5 に答える
エラーが発生する理由は、アセンブリが署名されているためです。おそらく、アセンブリへの参照で[特定のバージョン]プロパティがTrueに設定されており、変更を加えたアセンブリのバージョン番号が変更されています。多くのシナリオを試しましたが、FileLoadExceptionを取得できたのはこれだけでした。ターゲットフレームワークを4.0などの新しいバージョンに変更した場合は、代わりにBadImageFormatExceptionが発生します。バージョン番号を変更しなかったと言っても、とにかくチェックするか、参照を選択して右クリックしてプロパティを選択することにより、特定のバージョンをFalseに設定します。
あなたの例外はおそらく次のように見えました:
Could not load file or assembly 'LoadedAssembly, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=889080b75eb3bad2' or one of its dependencies. The located assembly's manifest
definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
ただし、参照されているアセンブリが1.0.0.0(または、たとえば任意のバージョン)ではなくなった場合は、コンパイルされたバージョン。下の画像(小さいですが)では、参照プロパティがバージョン1.0.0.0を探しており、特定のバージョンがTrueに設定されており、参照アセンブリが署名されており、実際にはバージョン2.0.0.0であるため、FileLoadExceptionが発生していることがわかります。
これを解決するには、バージョン番号を元に戻して再コンパイルするか、特定のバージョンをFalseに設定して、そのDLLのみを再構築します。アプリケーション全体を再構築する必要はありません。
DEVPATH環境変数を利用しようとしましたか? この環境変数を使用すると、「開発中の GAC」として機能するディレクトリを定義できます。あなたがしなければならないことは次のとおりです。
1) 次の要素を machine.config に追加します (使用する machine.config の場所を再確認してください)。
- C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG または
C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG*
2) DEVPATH という名前の新しい環境変数を追加します。
set devpath="e:\temp\Message_DLL\bin\Debug" /// manually, console
/// or open windows config form - see below
3) その後、UI アプリ/プロジェクトに移動し、DEVPATH ディレクトリに dll への参照を追加します。
"local copy = false, specific version = false"を構成したことを確認してください。ご覧のとおり、ストロング ネーム (スターカー ネーム)はtrueです。
4) ここで、UI アプリケーションを一度コンパイルする必要があります。その後、必要に応じて DLL のソースを変更することができます。DEVPATH 変数により、UI アプリケーションは常に DLL の最新ビルドを選択します。
ノート!VS から UI アプリケーションを起動しようとしましたが、ロード例外で失敗しました。しかし、エクスプローラーウィンドウから開始する - 成功しました。VS から UI アプリケーションを起動すると、CLR が参照されている DLL を別の場所で探すようです。
備考: この設定は、開発時にのみ使用してください。ランタイムは、DEVPATH にある厳密な名前のアセンブリのバージョンをチェックしません。最初に見つかったアセンブリを使用するだけです。
以下の記事/ウェブページもご覧ください。
CodeProject - アセンブリの場所、バインディング、デプロイ
これでうまくいくと思います!
Windows EventLogは、ロードできなかったものに関する詳細情報を提供する必要があります。新しいDLLに別の依存関係を導入しましたか?サードパーティのDLLでC++Runtime 2005をインストールする必要があるという同様の問題に遭遇しました(これは非常に一般的であるため、ほとんどのDevマシンとほとんどのデスクトップに当てはまります)。
この新しい dll を参照するアセンブリを再構築する必要があります。
勝手な推測ですが、DLL が存在するフォルダーが読み取り専用としてマークされているかどうかを確認できますか。
フォルダを右クリック > プロパティ >読み取り専用のチェックを外す> 適用をクリック > すべてのサブフォルダとファイルを選択 > OK.
ソリューションを再構築します。