クラスライブラリのapp.configのリダイレクトのバインドは何をしますか？
私がよく使用するVSソリューションは、単一の実行可能プロジェクト（コンソールアプリ、Webアプリ）および多くのクラスで構成されますすべて実行可能ファイルによって参照されるライブラリプロジェクト。
NuGetを使用してパッケージをインストールする場合、プロジェクトごとにapp.configファイルが作成されることがよくあります。通常、参照アセンブリのバージョンを統合するバインディングリダイレクトのリストのみが含まれます。サードパーティのライブラリ固有のコンテンツ（Entity Frameworkのconfigセクションなど）が存在する場合もありますが、ここではそれを無視します。
ソリューションをビルドし、メインの実行可能プロジェクトのバイナリを使用すると、ビルド出力にすべてのクラスライブラリプロジェクトアセンブリと対応する*.configファイルが表示されます（app.configファイルの名前はAssemblyName.configビルド時）。
メインの実行可能ファイルを起動すると、クラスライブラリアセンブリの構成ファイルは有効になりますか？または、この場合に効果があるのは、実行可能ファイルのapp.configファイルだけですか？一部のクラスライブラリプロジェクトにいくつかのバインディングリダイレクトが設定されており、メインの実行可能プロジェクトにいくつかの異なるバインディングリダイレクトが設定されている場合—これらはどのように組み合わされ、優先されますか？
私はこれをオンラインで調査しようとしましたが、私が読んだことから、非実行可能アセンブリのapp.configファイルは（リダイレクトのバインドに関して）役に立たないように見えます。誰かがこれを確認したり、トピックについてもう少し詳しく説明したりできますか？
その場合、バインディングリダイレクトのみが含まれている場合、NuGetによってクラスライブラリに作成されたこれらのapp.configファイルを持つことは実際には望ましくないでしょうか。 NuGetは、クラスライブラリプロジェクトのバインディングリダイレクトを作成すべきではないと感じています。これは、実際に適用される設定に関する混乱を増やすだけだからです。
トピックでこれらの既存のスタックオーバーフローの質問を見つけましたが、それらの受け入れられた答えは、互いの重複としてマークされていても実際には矛盾しています。
なぜNuGetは、NuGetパッケージの更新中にLIBRARYプロジェクトにassemblyBindingでapp.configを追加するのですか？
bindingRedirect .configファイルは必要ですか、それともアプリケーション内のすべてのアセンブリですか？
最初の質問に対する受け入れられた答え は、app.configファイルがコンパイル時に実際に使用されることを示しています。つまり、効果がある可能性があります。 [〜＃〜] msdn [〜＃〜] や MSBuildソースコード などのソースは、コンパイル時に使用される証拠として引用されています。残念ながら、MSBuildの使用方法や、それが実際に有効な引数であるかどうかを理解するには、MSBuildには十分に習熟していません。
クラスライブラリのバインディングリダイレクトを使用したapp.configが何でもできることを証明するために、誰でもシナリオの例を説明できますか？
同様の設定の複数のアプリケーションがあります-Webアプリケーションは、それぞれ独自のナゲットパッケージなどを持つ複数のライブラリプロジェクトを参照します。個人的な経験から、ライブラリプロジェクトのアセンブリバインディングは実行時に考慮されません。
ルートアプリケーション（web/console）で指定されたバインディングのwebまたはapp configは重要なことです。すべてのライブラリプロジェクトは、app.configファイルの「コピーしない」として「出力ディレクトリにコピー」設定を使用してセットアップされています。そのため、出力フォルダーがdllとその構成ファイルで乱雑になりません。
ここにリンクがあります これは、アセンブリがどのようにロードされ、どこで検索されているか、およびそのシーケンスを示しています。記事のどこで個々のプロジェクト構成ファイルについて説明しているのかはありません。
お役に立てば幸いです。
この古いmsdnの記事 によると：
アプリケーション構成ファイルは、アセンブリバインディングを制御するために使用されるXMLファイルです。サイドバイサイドアセンブリの1つのバージョンの使用から、同じアセンブリの別のバージョンにアプリケーションをリダイレクトできます。これは、アプリケーションごとの構成と呼ばれます。アプリケーション構成ファイルは、特定のアプリケーションマニフェストと依存アセンブリにのみ適用されます。埋め込み[ISOLATIONAWARE_MANIFEST_RESOURCE_ID]マニフェストでコンパイルされた分離コンポーネントには、個別のアプリケーション構成ファイルが必要です。 CreateActCtxで管理されるマニフェストには、個別のアプリケーション構成ファイルが必要です。
DllにはISOLATIONAWARE_MANIFEST_RESOURCE_ID setは実際には独立したアプリケーション構成を使用します。それ以外の場合は、メインプロセス構成ファイルに委ねられます。
ISOLATIONAWAREの詳細については、こちらをお読みください 他のMSDN記事 さらに詳しく説明しています。
ISOLATIONAWARE_MANIFEST_RESOURCE_IDは、主にDLLに使用されます。 dllがプロセスのデフォルト以外のプライベートな依存関係を必要とする場合に使用する必要があります。たとえば、dllがcomctl32.dllバージョン6.0.0.0に依存している場合。 comctl32.dllバージョン6.0.0.0に依存するには、タイプRT_MANIFEST、ID ISOLATIONAWARE_MANIFEST_RESOURCE_IDのリソースが必要です。これにより、プロセス実行可能ファイルがcomctl32.dllバージョン5.1を必要としても、dll自体は正しいバージョンのcomctl32.dllを使用します。
答えはmaybeです。ライブラリファイルはプロジェクトのタイプに応じて異なります。一部のライブラリプロジェクトは、ライブラリの構成ファイルが尊重されるコンテキスト（Azure Webロールなど）で実行されますが、これは標準ではありません。
詳細については、私の答え here をご覧ください。
いいえ、実行可能ファイルのapp.configのみが有効になります。たとえば、WCFサービスをホストするコンソールアプリがあり、WCFサービスでConfigurationManager.AppSettingsなどを使用する場合、AppSettingsはコンソールホストapp.configファイルから取得されます。別のコンソールアプリケーション（ConsoleClient）を起動してConsoleHostへの接続を試みた場合、ConsoleClientが「実行中」と言える部分（たとえばメインメソッド）では、ConsoleClientのapp.configを使用します、ただし、WCFサービスの使用を開始するとすぐに、WCFサービスはConsoleHostのapp.configの使用を委任します。 （ただし、この最後の点は、WCFの背後にある詳細により関連していることに注意してください。）
通常、構成ファイルは1つのみであり、実行可能ファイルの構成ファイル（.exe.config、web.config）です。
アセンブリリダイレクトは、実行可能ファイルの構成ファイルに配置する必要があります。
Dllの構成ファイルは、ConfigurationManagerクラスを使用して手動でロードする必要があります。この質問も参照してください ライブラリ（DLL）の 'app.config'と同等