問題タブ [assemblybinding]

web.configアセンブリ リダイレクトを外部ファイルに移動しようとしています。その理由は、バインド リダイレクトを 1 か所に保持し、デバッグ構成と運用構成の両方で使用したいからです。

ある程度は機能しますが、相対パスの指定に苦労しています。

web.runtime.configWeb アプリケーションの残りの部分と同じフォルダーに保持したい。linkedConfiguration要素に相対パスを指定することはできますか?

詳細情報: VS 2015 で IIS Express および ASP MVC アプリケーションを使用してテストしました。SysInternals Process Monitor を使用してファイル アクセスを監視すると、相対パスが\\web.runtime.config(無効なネットワーク パス) に解決されるように見えますが、絶対パスを使用すると先頭\\が追加されません。 .

外部参照を持つ C# プロジェクトをコンパイルすると、参照された dll がプロジェクトの出力パス (exe の隣) にコピーされます。

アプリケーションを実行すると、exe の隣に dll が見つかることが期待されます。

私は自分のdllファイルを別のディレクトリDLLに広げる方法を探しています。そして、これらのディレクトリでexeファイルを探します。

例：

の下に「App」というアプリケーションがあり、C:\App\App.exe現在も の下にある「App.dll」という dll ファイルを使用しているとしますC:\App。

C:\App\DllsApp.exeファイルが新しい場所でdllを探すことを認識していることを確認しながら、という名前の新しいディレクトリを作成し、そこにApp.dllファイルを移動したいと考えています。

私はインターネットを検索し、プロービングソリューションを見つけました。これが私のコードです（編集された「App.config」ファイル）：

アプリケーションをコンパイルし、Dlls ディレクトリを作成し、すべての dll ファイルをそのディレクトリに移動しましたが、アプリケーションがクラッシュします。

私は何が欠けていますか？

MEF、Webapi、および OData を使用する Web アプリがあります。MEF の場合、必要に応じてカタログをロードするヘルパー クラスを作成しました (最初のアクセス時)。

以下は、MEF 統合コードです。

私のプロジェクトの 1 つ (実際の Web アプリ プロジェクト) では、次の nuget パッケージを使用しています (特に): WebApi 5.2.3 WebApi.OData 5.7.0

私の問題は、MEF クラスがこのアセンブリを読み込もうとするときです (OData と WebApi を使用するアセンブリで、ランタイム エラーがスローされました。これは以下に記録されています。問題は、運用マシンでの展開でのみ発生します。開発ではすべて正常に動作します。

以下のエラーでわかるように、プロジェクトが System.Web.Http バージョン 5.2.3.0 を参照していても、実行時に System.Web.Http.Odata アセンブリが System.Web.Http バージョン5.2 を読み込もうとしているようです。 2.0 (!?!?!?)

私のプロジェクトでは、参照は正しい dll (バージョン 5.2.3.0) に設定され、dll はCopy Local=Trueで設定され、web.config には

このプロジェクト (アセンブリ) には MEF で作成する必要のあるクラスがないため、MEF によるロードから単純に除外できますが、このエラーは私を困惑させ、解決策を見つけたいと考えています。他のアセンブリでも同様の問題が発生します。

ここに私が得るエラーがあります

問題

Microsoft.mshtml Primary Interop Assembly を参照している WPF アプリケーションがあります。NGen を使用してアプリのネイティブ イメージを作成しています。アプリを起動すると、ネイティブ イメージが読み込まれないのではないかと心配しています。

複製情報

たとえば、Visual Studio で新しい WPF アプリケーション "WpfApplication1" を作成し、"C:\Program Files (x86)\Microsoft.NET\Primary Interop Assemblies\Microsoft.mshtml.dll" への参照を追加し、Embed Interop Types を false に設定し、特定のバージョンを設定します。 false に設定し、Copy Local を true に設定します。mshtml.HTMLDocumentClass のインスタンス化など、何らかの種類の Microsoft.mshtml を使用します。アプリをビルドしたら、次のように "c:\Windows\Microsoft.NET\Framework\v4.0.30319" から NGen を実行します。

NGen はエラーを表示しません。アプリを起動した後、vmmap またはプロセス エクスプローラーを使用して、ネイティブ イメージが読み込まれたかどうかを確認しています。残念ながら、作成されたネイティブ イメージを表示しているものはありません。

融合ログ

Fusion ログ ビューアを有効にすると、次のように表示されます。

* アセンブリ バインダー ログ エントリ (2016 年 3 月 13 日 @ 11:30:48 AM) *

操作は成功しました。バインド結果: hr = 0x0。操作は正常に完了しました。

アセンブリ マネージャーの読み込み元: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll 実行可能ファイルの下で実行 C:\Users\azureuser\Documents\visual studio 2015\Projects\WpfApplication1\WpfApplication1\bin\Release\WpfApplication1 .exe
--- 詳細なエラー ログが続きます。

ログ: すべての依存関係の検証を開始します。
ログ: [レベル 1] ネイティブ イメージの依存関係 mscorlib、バージョン = 4.0.0.0、カルチャ = ニュートラル、PublicKeyToken = b77a5c561934e089 の検証を開始します。
ログ: [レベル 1] IL 依存性 PresentationFramework、バージョン = 4.0.0.0、カルチャ = ニュートラル、PublicKeyToken = 31bf3856ad364e35 の検証を開始します。
ログ: [レベル 1] IL 依存 WindowsBase、バージョン = 4.0.0.0、カルチャ = ニュートラル、PublicKeyToken = 31bf3856ad364e35 の検証を開始します。
ログ: [レベル 1] IL 依存 System.Xaml、バージョン = 4.0.0.0、カルチャ = ニュートラル、PublicKeyToken = b77a5c561934e089 の検証を開始します。
ログ: [レベル 1] IL 依存性 PresentationCore、Version=4.0.0.0、Culture=neutral、PublicKeyToken=31bf3856ad364e35 の検証を開始します。
ログ: [レベル 1] ネイティブ イメージ依存システムの検証を開始します。バージョン = 4.0.0.0、カルチャ = ニュートラル、PublicKeyToken = b77a5c561934e089。
ログ: [レベル 2] ネイティブ イメージの依存関係 mscorlib、バージョン = 4.0.0.0、カルチャ = ニュートラル、PublicKeyToken = b77a5c561934e089 の検証を開始します。
ログ: [レベル 2] IL 依存 System.Configuration、Version=4.0.0.0、Culture=neutral、PublicKeyToken=b03f5f7f11d50a3a の検証を開始します。
ログ: [レベル 2] IL 依存 System.Xml、バージョン = 4.0.0.0、カルチャ = ニュートラル、PublicKeyToken = b77a5c561934e089 の検証を開始します。
ネイティブ イメージには正しいバージョン情報があります。
ログ: [レベル 1] IL 依存 UIAutomationTypes、バージョン = 4.0.0.0、カルチャ = ニュートラル、PublicKeyToken = 31bf3856ad364e35 の検証を開始します。
ログ: [レベル 1] IL 依存関係 Microsoft.mshtml、バージョン = 7.0.3300.0、カルチャ = ニュートラル、PublicKeyToken = b03f5f7f11d50a3a の検証を開始します。
WRN: IL アセンブリを読み込めません。(時間 = 0x80131040)。
WRN: 一致するネイティブ イメージが見つかりません。
ログ: C:\Users\azureuser\Documents\visual studio 2015\Projects\WpfApplication1\WpfApplication1\bin\Release\WpfApplication1.exe から読み込まれた IL アセンブリ。

備考

• mshtml コードを含む Microsoft.mshtml 参照を削除すると、期待どおりにネイティブ イメージが読み込まれます。したがって、一般的に、私のシステムではngeningが機能します。
• Windows 7 Ultimate、Windows Server 2012 Datacenter、および Windows 10 の 3 つの異なる OS でこの動作をテストしましたが、同じ結果が得られました。
• 実行して負荷検証を無効にしてsn.exe -Vr *,*も、動作は変わりません
• 実際に GAC から読み込まれる Microsoft.mshtml は、「C:\Program Files (x86)\Microsoft.NET\Primary Interop Assemblies」にあるものとは若干異なる (証明書が異なる) ため、こちらも直接参照してみました。 GACは異なる結果を生成しません
• 「C:\Program Files (x86)\Microsoft.NET\Primary Interop Assemblies」の下にあるものを実行してGACに入れてgacutil -ifも機能しません
• このアプリは、.net 4.5 をターゲットとする VS2013 と .net 4.6 をターゲットとする VS2015 を使用して構築しました。

ソリューション ファイルに 20 個のプロジェクトがあります。プロジェクトの 1 つは、すべてのプロジェクトが参照する標準ライブラリ プロジェクトです。

約 1 年前、新しい nuget パッケージを追加しました。これをPackage Aバージョン 5.0.0.0 と呼びます。コンパイル時に転送されるファイルがたくさんありましたが、最終的には対処しました。パッケージを標準ライブラリ プロジェクト (他の 19 が参照するプロジェクト) に追加しました。

私はNugetを初めて使用するので（おそらく何か間違ったことをしたのかもしれません）、のヘルパーとして機能する新しいパッケージを作成しましたPackage A。ヘルパーがバージョン 3.0.0.0 から 5.0.0.0 に依存するようにすべてを設定しましたPackage A(したがって、私たちよりも低いバージョンの他のユーザーでも機能します)。この新しいパッケージを呼び出しましょうPackage A helper

インストールするPackage A helperと、すべてが正常に機能しています。プル リクエストを実行すると、ソリューション内のすべての app.config が

それがなくても問題なくコンパイルされますが、ビジュアルスタジオは不平を言って警告を出します。何を与える？私のマネージャーは、app.config にあまりにも多くのノイズを追加し、パッケージ A に依存しすぎているため、コードをマージすることを許可しません。

インストールする前に主な依存関係が既に満たされているのに、依存する nuget パッケージを追加すると、Package Aこの新しい bindingRedirect が必要になるのはPackage A Helperなぜですか?

そして、ナゲットパッケージとpackage.configで3.0.0.0-5.0.0.0を指定したときに、なぜ0.0.0.0-5.0.0.0と言うのですか

アップデート：

Package A helperバージョン 5.0.0.0 への参照を使用してビルドするとPackage A、すべての bindingRedirects がすべての app.config で自動入力されず、代わりに警告が生成されます。最小の依存関係でビルドするのが最善だと考えたので、最初は 3.0.0.0 でビルドしました。Visual Studio は依然として警告を発し、bindingRedirects が作成されることを示唆しているため、問題は依然として存在します。

私のnugetパッケージの依存関係を3.0.0.0から5.0.0.0に変更し、5.0.0.0を許可して私のpackages.configを取り除くだけの解決策allowedVersions="[3,6)"ですか? nuget パッケージの有用性と下位互換性を低下させたくありませんが、同時に、メイン ソリューションに必要な警告や bindingRedirects を必要としません。

更新 2:Copy Local参照プロパティを設定してFalse実際に問題を解決しましたが、その理由がわかりません。