2

.netで非常に単純なはずのものは、非常に難しいようです。

MyExtendersというプロジェクトがあり、基本的なタイプへのいくつかの単純なエクステンダーが含まれています。

多くのプロジェクトはMyExtendersを使用しているため、従来のsvnチェックアウトおよびビルドアプローチでは、MyExtendersをsvn：externalとして追加し、リビジョンは最後にビルドおよびテストされた方にロックされています。

同じソリューションにMyExtenderを追加する必要がある2つのプロジェクトがある場合、すべてがヒープに分類されます。両方のMyExtenderをソリューションに追加することはできません。したがって、1つだけを使用する必要があります。これは、リビジョンが異なる場合は、古いプロジェクトをそれを使用して再テストすることを意味します。

おそらく、依存関係を最もよく説明する図は次のとおりです。

SolutionA
->ProjectA
->->MyExtenders r350 (svn:externed by ProjectA)
->ProjectB
->->MyCryptography r800 (svn:externed by ProjectB)
->->->MyExtenders r800 (svn:externed by MyCryptography)

Delphi / Cは、上記で問題なく動作します。すべての参照は、独自のプロジェクトフォルダからのものです。

VSは、ディレクトリ構造を失い、上記を次のように平坦化することを主張しています。

SolutionA
->ProjectA (refers MyExtenders)
->ProjectB (refers MyCryptography)
->MyCryptography r800 (refers MyExtenders)
->MyExtenders r350 || r800 - my choice

そして、私はプロジェクトの1つを変更して、別のMyExtenderを参照するように強制され、そのときは別のリビジョンを参照しました。

明らかに私はそれをすべて間違っています..しかし、あなたはそれをどのように正しくしますか？

4

1 に答える 1

1

これを回避する方法は実際にはありません。同じアセンブリの異なるバージョンに依存する2つの異なるプロジェクトがある場合、プロジェクト間の依存関係をどのように管理するかに関係なく、競合が発生することになります。これがなぜであるかを理解するために、すべてのソースの競合を何らかの方法で解決できると想像してください。展開時に何をしますか？依存関係のどのアセンブリバージョンがロードされますか？どちらの場合でも、他のバージョンを必要とする依存アセンブリが破損する可能性があります。

さまざまなサブシステム間で共有ライブラリを必要とする設計があり、それらのサブシステムが同じプロセス（技術的には同じAppDomain）にある場合は、両方に同じアセンブリバージョンが必要です。

この問題は、サービスインターフェイスやリモーティングチャネルなど、依存するアセンブリを境界で区切ることができれば解消されます。次に、依存関係を個別にバージョン管理できます。Visual Studioは、同じ名前の2つのプロジェクトを1つのソリューションに含めることを好みません。したがって、これを回避する唯一の方法は、プロジェクトファイルの1つをコピーし、名前を変更して、ソリューションにロードすることです。

于 2010-07-03T06:10:55.630 に答える