3

簡単に修正したい興味深い問題があります。VisualStudioのソリューションの「クライアント」プロジェクトと「テスト」プロジェクトの両方で参照される「ライブラリ」アセンブリがあります。問題は、テストプロジェクトがクライアントプロジェクトも参照していることです。ILMergeを使用して、ライブラリアセンブリをクライアントアセンブリとマージして配置する必要があります。ライブラリアセンブリはクライアントアセンブリとマージされるため、テストプロジェクトをビルドしようとすると、最初に参照されたライブラリアセンブリとマージされたアセンブリの両方に存在するライブラリアセンブリの型についてエラーが発生します。

本当の問題は、クライアントプロジェクトのビルド後のステップでILMergeを実行していることです。最善の解決策は、それを実際の展開プロセスに移すことです。ただし、現在のツールでは、実装が困難になります。

タイプが複数のアセンブリに含まれている可能性があり、それで問題ないことを.NETに伝える方法はありますか（実際には同じアセンブリであるが、ある場合には別のアセンブリとマージされているだけです）。

4

3 に答える 3

5

したがって、私が正しく理解していれば、テストプロジェクトにはライブラリとクライアントへの参照があり、クライアントにはライブラリがマージされています...したがって、テストのビルド時に、同じライブラリの2つの参照を取得します。解決策は、テストプロジェクトからライブラリ参照を削除し、必要なものがすべて揃っているクライアントのみを参照することだと思います。

于 2010-11-29T18:10:11.247 に答える
2

私が正しく理解していれば、テストでのみマージされたアセンブリを参照すると、すべてのタイプにアクセスできるようになり、ライブラリアセンブリへの参照が不要になるため、ILMergeの問題が解消されます。

バイナリの「クライアント」出力（マージされたファイル）への参照を追加し、手動のビルド依存関係を追加して、正しいコンパイル順序を制御することをお勧めします。

私のプロジェクトでは、CSPROJファイルを手動で編集し、「CopyFilesToOutputDirectory」ターゲットをオーバーライドして、ビルド中に「クライアント」をコンパイルするだけでなく、マージすることでこれを行いましたが、ビルド後のイベントでもうまくいくはずです（私は同時にいくつかの他の無関係な変更により、ターゲットの動作を変更せざるを得なくなりました）。

次に、マージされたDLLを参照する他のプロジェクトファイルを編集して、次のような参照を使用しました。

<Reference Include="MyMergedLib, Version=1.2.3.4, Culture=neutral, PublicKeyToken=3d58c5c8efc41aa9, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\MyMergedLib\$(OutputPath)MyMergedLib.dll</HintPath>
</Reference>

これにより、VSが常に正しいバージョン（デバッグ/リリース）を取得するようになります。多分これは役に立ちます。

于 2010-11-29T18:24:15.993 に答える
0

この問題を修正するには、（ILMergeの代わりに）カスタマイズされたバージョンのILLinkを使用できます。

または、それを微調整して重複するアセンブリを削除することもできます。

こちらのソースコードを参照してください。ILLinkはC++プログラムであることに注意してください。

于 2010-11-29T18:10:21.730 に答える