2012-05-03 11 views
1

私はいくつかのプロジェクト(すべてのクラスライブラリ)からなるソリューションを持っています。 A、B、C、D、E.ILmergeとアセンブリの参考資料

A、BおよびCはコア機能を提供するため、一緒に配布する必要があります。 DとEは、あらゆる状況で必ずしも必要ではないアダプタをいくつか提供します。

したがって、配布する前にA、B、Cを1つのアセンブリ(ABCという名前)にILmergeする必要があります。

プロジェクトがコンパイルされると、DとEはABCではなくA、B、および/またはCへの​​参照を持ちます。だから後で他のプロジェクトでABC、D、Eを参照しようとすると、コンパイルエラーが発生します。「インスタンス引数:A.IBooからA.IBooに変換できません。 VSではアセンブリのシグネチャ(名前)が異なることもわかります。

これを修正する良い方法はありますか?

パブリッシャーポリシーを使用している可能性がありますが、それほど美味しくはありません。

また、私は元のソリューションでプロジェクトを結合でき、ILmergeの使用を避けることができますが、私はそうしたくないと知っています。

答えて

2

同様の問題が発生しました。私はタイプが2回参照されていたことが判明しました。組み立てられた組立に1回、別々のプロジェクトに1回。それは地獄のようにイライラしていた。

プロジェクトを削除して、結合されたアセンブリのみをライブラリとして扱うか、プロジェクトをビルド後の操作で組み合わせることができます。

グローバルネームスペース(http://msdn.microsoft.com/en-us/library/c3ay4x3d(v=vs.80).aspx)に別名を付けて、組み合わせアセンブリを参照することもできます。欠点は、あなたは常にアダプタの背後に構築されることです。

実際のプロジェクトを見ることなく、ここで私は何をしますか:私はABCプロジェクトを分けて、それを自分の解決策に入れます。ポストビルドイベントでは、ILMergeを実行します。これは、バージョン管理され、強力な名前が付いていることを確認します。それは、あなたの頭を頭の中に救うでしょう。

プロジェクトDとEは、ABC結合アセンブリへの参照とともに解決策になります。

コードと依存関係を見ずに、わかりにくいです。また、変更の頻度にも依存します。私がABCで2つの解決策を持つDEに対応するために変更を加えると、本当に早くなるでしょう。

+0

いくつかのオプションを提示していただきありがとうございます。私はあなたの場合と同じように、内部と外部の参照を持っています。実際には、私が話しているプロジェクトはこれです:https://github.com/Kostassoid/Anodyne、build.cmdは私がこれまで行ってきたことを「説明する」ことができます。ソリューションを分割するのはおそらく最良のアイデアですが、それは若いプロジェクトであるため、私は非常に頻繁に作業する必要があります。 – Kostassoid