Castle の DynamicProxy (具体的には、「ターゲットのないインターフェイス プロキシ」) を使用してカスタム処理のメソッド呼び出しのインターセプトを実行するため、Castle.Core.dll に内部的に依存する .NET ライブラリがあります。アセンブリには厳密な名前が付けられているため、ILMergeを使用してすべての依存関係をデプロイ用の 1 つのアセンブリに結合し、依存関係のタイプを内部化して、消費者に不必要に公開しないようにしたいと考えています。これは、 NuGetの場合に特に重要です。アセンブリに厳密な名前が付けられている場合、パッケージの依存関係を特定のものに設定する必要があります。Castle.Core.dll にも厳密な名前が付けられているため、依存関係のバージョン、またはアセンブリの名前解決が壊れています。プロジェクトを厳密な名前のアセンブリとしてリリースすることは、ユーザーが重視する機能であるため、厳密な名前を削除することはできません。
どうやら、DynamicProxy が適切に機能するには、そのクラスの一部が公開されている必要があります。問題ありません。特定の型を ILMerge による内部化から除外できます。ただし、ライブラリを参照するユーザーがいるだけでなく、Castle.Core.dll も参照している場合に問題が発生します。現在、パブリック型は 2 つのアセンブリによって提供されており、それらへの参照はあいまいです。
ILMerge を使用して Castle.Core.dll を内部化せず、自分のアセンブリと一緒に出荷すると、自分のバージョンとユーザーのバージョンの間でバージョンの競合が発生する危険があります。ILMerge を使用してアセンブリを内部化すると、DynamicProxy が適切に機能するために必要な型の内部化を除外せざるを得なくなります。このアプローチは、あいまいな型のために、私のアセンブリと Castle.Core.dll の両方を参照するプロジェクトを壊します。
これら 2 つの次善の行動方針のいずれかを強いられるのでしょうか? それとも、私がまだ考えていない解決策がありますか？