MicrosoftWindowsのサイドバイサイドアセンブリと分離アプリケーションソリューションを見ています。
ドキュメントによると：
プライベートアセンブリは、アプリケーションとともに展開され、そのアプリケーション専用に使用できるアセンブリです。
と
プライベートアセンブリは、システム上の他のバージョンのアセンブリと並行して動作するように設計する必要があります。
ただし、プライベートアセンブリの展開プロセスは、アセンブリをアプリケーションのフォルダー（またはアセンブリの名前を持つサブフォルダー）にコピーするだけです。したがって、アプリケーションは複数のバージョンのプライベートアセンブリを使用できません。別のバージョンのプライベートアセンブリを配置すると、古いバージョンが上書きされるためです。
誰かが私にこれを説明できますか？
これが実際にそうである場合、リダイレクトを使用する通常のDLLに対するそのようなアセンブリの利点は何ですか？それらは私にはほとんど同じように見え、マニフェストはここでは使用されていないようです。
プライベートSxSアセンブリを使用してdllを展開することは、実際には、物事をより頻繁に失敗させる複雑な方法です。
ただし、いくつかの利点があります。
ただし、指定したベースフォルダーを使用してActivation Context APIを使用して、実行時に独自のアクティベーションコンテキストを作成できます。これにより、プライベートSxSアセンブリが検索されます。この手法を使用して、オプションのアセンブリを動的にロードしたり、必要に応じてさまざまなバージョンのアセンブリをロードして、ある種のプラグインAPIを実装したりできます。
Activation Context APIを使用するには、次のことを行う必要があります。
これらは常にOSローダーによって生成されたコンテキストでロードされるため、静的にバインドされたリソースには使用できないことに注意してください。
オプションでロードする依存アセンブリを記述したアプリケーションマニフェストファイルを作成します。これは、外部に、またはリソースIDが16を超えるRT_MANIFESTリソースとして埋め込まれています。
マニフェストが配置されている場所の詳細をACTCTX構造体に入力し、 lpAssemblyDirectoryが特定のバージョンのプライベートSxSアセンブリを保持するディレクトリを指していることを確認します。CreateActCtxを呼び出して、アクティベーションコンテキストオブジェクトを作成します。
特定のバージョンのdllをロードするときは、ActivateActCtxを使用して適切なアクティブ化コンテキストをアクティブ化し、dllの単純な名前でLoadLibraryを呼び出します。呼び出し後に非アクティブ化するのは、dllがロードされた状態で、アクティブ化コンテキストをアクティブにする必要がなくなったためです。アクティブ化コンテキストを検索する必要があるAPI関数をもう一度呼び出すまでは、アクティブ化コンテキストをアクティブにする必要はありません。たとえば、クラスのウィンドウを作成します。 dllでホストされるか、登録のないcomオブジェクトを作成します。
システムは、dllのロード中に、提供されたlpAssemblyDirectoryでdllとそれに依存するアセンブリを検索します。
各EXEには独自のプライベートDLLがあります。ここで上書きする必要はありません。各EXEを独自のインストールディレクトリに配置します。それらは設計により異なるバージョンのDLLを持つことができ、DLLHellは存在しません。それ以外の場合、それらのDLLは、ファイルシステムまたはレジストリの他の部分に接触し、それを実行するために互いに足を踏み入れる可能性があります。「並行して動作するように設計する必要があります」への参照。これを達成するのはめったに難しいことではありません。