注: この質問は、ファイルの有無にかかわらずMFC/CRT DLL リンク、.manifestマニフェスト ルックアップ (つまり、現在のパスからの強制ロード)、VC redist インストール、および同様の問題を回避することに関するものではありません。
さまざまなアプリケーションで使用される一連の DLL があります。これらのアプリケーションと DLL には、いくつかの製品バージョン (7.0、8.0 など) があります。要約すると、1 つの DLL と 2 つのアプリケーションを使用します。
App.exe依存するCore.DLLGoodApp.exeにも依存しますCore.DLL
App.EXEバージョン 7.0 の場合、バージョン 7.0 が必要Core.DLLです。同様にGoodApp、バージョン X の場合、バージョン X の DLL が必要になります。
DLL はさまざまなアプリケーションで共有されるため、DLL をいくつかの共通パスに配置しました。これにより、DLL がすべてのパスに貼り付けられるのを回避できます。このためにいくつかの\SharedDLLパスが設定されています。PATHそして（仮定）、私はこれのために変数を設定しました。そのため、いずれかのアプリケーションがロードされると、OS は単にこの共通パスから Core.DLL をロードします。
大丈夫だ。しかし、App.exe が 64 ビット/デバッグ、またはその他の構成の場合はどうなるでしょうか。共通 DLL パスにすべての DLL を含めることはできません (32/64、デバッグ/リリース)。同様にApp.exe、バージョン YCore.DLLのバージョン X は使用できません ( X >Y や Y>X ではなく、単にX!=Yであり、X バージョンのアプリはバージョン Y の DLL を使用できません)。
要するに、App-32bit-Release-VersionXにはDLL-32bit-Release-VersionXだけが必要で、他には何も必要ありません! DLL 名が同じなので、1 つの共通パスに入れることはできません。に依存するアプリケーション (および DLL も!) は多数Core.DLLあるため、DLL を EXE のパスにコピーするためにスペースと時間を無駄にしたくありません。
はい、ビルド後のセットアップを使用して、DLL をすべてのパスに適切にコピーします。これは時間を解決しますが、スペースを無駄にします。また、新しいアプリケーションが入ってきたら、その新しいパスにもコピーするように PBS を変更する必要があります。
質問: Windows/MFC/CRT DLL で使用される .manifest 機能を利用するにはどうすればよいですか? 彼らはWinSxSそのようなことのためにフォルダーを利用します。