この質問は、たとえばhereおよびhereなどの SO で以前に尋ねられました。シナリオは、マシンに COM コンポーネントを登録せずに、アプリケーションで COM コンポーネントを使用したいというものです。これは、2 つのマニフェスト ファイルを 1 つをクライアントに、もう 1 つをサーバーに追加することで実現され、残りは OS のサイド バイ サイド機能が処理します。すべてのDLLが同じフォルダにある場合、これは正常に機能するようになりました。
私の特定のシナリオでは、従来の .net 2.0 dll から 4.0 dll にアクセスしようとしています。2.0 dll を変更したくないので、上記の方法でこれを達成できました。ただし、4.0 dll が実行可能ファイル (2.0 dll) のサブフォルダーにある場合。サイド バイ サイド実行が開始されると、4.0 dll が見つかりません。現在、win32 API を呼び出して、マニフェスト ファイルを渡す新しい ActivationContext を作成しています。ProcMon を使用したところ、dll が検索用のマニフェストで指定されたパスではなく、実行可能ディレクトリで検索されていることがわかりました。上記のリンクも証明しているように、.net はマニフェスト内の ClrClass のみを認識しており、プライベート アセンブリ ルックアップ用に提供された AssemblyLocation を無視しているようです。
とにかく、上記のリンクの回避策はGACとAssemblyResolveです。可能であればGACを通過したくありません.4.0 dllをロードできない2.0 dllでサブスクライブする必要があるため、AssemblyResolveは機能しません。
アプリケーションが一時的に別の場所にあると考えて、dllが見つかるようにするハックの種類はありますか?
また、4.0 アプリを呼び出す 2.0 アプリを有効にするサービス (Web、Windows) の使用も認識しています。上記の 3 つ以外の他の可能性は高く評価されます。