9

複数のサブプロジェクト (約 20) で構成される .NET プロジェクトがあります。いくつかのソリューションがあり、それぞれが特定のソリューションに関連するサブプロジェクトのみを含んでいます。

任意の解決策を可能にするために、サブプロジェクトはプロジェクト参照によって相互に参照することはなく、直接の dll 参照によって参照されます。HintPath に $(Configuration) を含めるために csproj ファイルを微調整する必要があるため、デバッグ ビルドはデバッグ dll を参照し、リリース ビルドはリリース dll を参照します。

すべてうまく機能しますが、大きな問題が 2 つあります。

  1. VS は、依存関係の計算のために dll 参照を認識しません。新しいプロジェクトまたは参照が追加されるたびに、[プロジェクトの依存関係] ダイアログを使用して依存関係を手動で指定する必要があります。これは面倒です。
  2. Resharper も Visual Assist も使用していません (優れたツールですが、使用していません。当然のことです)。私たちは、標準の "Browse to Definition" コマンド (たとえば、ソース コードのコンテキスト メニューから利用できます) を使用したいと考えています。重大な問題は、あるプロジェクトがプロジェクト参照を使用して他のプロジェクトを参照している場合にのみクロスプロジェクトで機能し、参照先のプロジェクトがソリューションに含まれていても、参照が直接 dll 参照である場合は機能しないことです! ソースに移動する代わりに、メタデータに移動するため、これは本当に残念です。

私たちのように dll 参照を使用し、これら 2 つの問題を何とか克服した人々のアドバイスを求めています。ありがとう。

編集：

「定義の参照」の問題に加えて、プロジェクト参照の代わりに Dll 参照を使用すると、プロジェクト マネージャーに 1 回だけコストがかかることに注意してください。これは、新しいプロジェクトまたは新しい依存関係が追加されたときに、影響を受ける各ソリューションのプロジェクト依存関係を更新することです。導入する必要があります。これらのプロジェクトの依存関係は .sln ファイルに保持され、新しいプロジェクトが到着するか、新しい依存関係が作成されるまで、メンテナンスは必要ありません。これはそれほど頻繁には発生しません。

VS と同じ .sln ファイルを使用する CI サーバーでプロジェクトをビルドするために msbuild を使用しています。すべてのサブプロジェクトを含むメインの .sln ファイルが 1 つあります。

参照が dll 参照であるため、両方のプロジェクトが同じソリューションにあるにもかかわらず、別のプロジェクトの定義を参照できないという、より深刻な問題を強調したいと思います。これは面倒で迷惑です.VSが機能を有効にするためにプロジェクト参照を主張する理由はありません. Resharper や Visual Assist などの他のツールには、この制限はありません。悲しいかな、私たちはこれらのツールを持っておらず、観察可能な将来に持っている可能性は低い.

4

3 に答える 3

7

ビルド構成の問題は次のとおりです。3 つのプロジェクトと 2 つのソリューションがあるとします。

Solution1
- Project1
- Project2
Solution2
- Project1
- Project3

突然、Solution2 をビルドすると、Solution1 のコードの一部がビルドされ、無効な状態のままになります (最新のバイナリは互換性がないか、ビルドする必要がありませんでした)。

すべてのプロジェクトを 1 つのソリューションに含める必要があります。他のソリューションは依存できますが、これらのプロジェクトのコードを積極的に変更するべきではありません。このようにして、外部依存関係を再構築する理由がないため、ビルドされた DLL を参照できます。

要約すると、次の条件を満たすように、時間をかけてソリューションを再構築する必要があります。

  • すべてのプロジェクトは、1 つのソリューションに含まれています。
  • プロジェクトが同じソリューション内の別のプロジェクトに依存している場合は、それをプロジェクト参照にします。
  • プロジェクトが別のソリューションの別のプロジェクトに依存している場合は、それを DLL 参照にします。

上記に加えて、ビルドが他のソリューションから参照される場合にビルドを配置するための「Externals」ディレクトリを作成することをお勧めします。次のように再構築するとします。

Solution1
- Project1
- Project2 -> reference project Project1
Solution2
- Project3 -> reference Project1.dll

この場合、Project1.dll と Project1.pdb のコピーを とExternals\Project1\Debugに配置し、Project3Externals\Project1\Releaseで参照します。External\Project1\$(Configuration)\Project1.dllビルドを他のすべてのソリューションにプッシュする準備ができている場合にのみ、Externals ディレクトリのビルドを更新します。

于 2009-11-09T19:13:52.403 に答える
2

任意のソリューションを許可したい理由はありますか? 単一のソリューションを作成し、そのソリューションにすべてのプロジェクトを配置する方が簡単なようです。可能な限り複数のソリューションを避けるようにしています。

于 2009-11-09T17:52:18.647 に答える
-1

あなたが直面している問題は、ツール セットを正しく使用していないことが直接の原因であるように思えます。Visual Studio には、プロジェクトの依存関係を管理させない場合に、プロジェクトの依存関係を自動的に計算する方法が他にありません。

2つの選択肢があるようです。

  1. Visual Studio を使用してプロジェクトの依存関係を管理する
  2. 別のビルド システム (NAnt など) を使用する

オプション＃1を除外したようですので、これ以上は触れません. したがって、残りはオプション #2 だけです。

NAntを使用して個々の CSproj プロジェクトをビルドし、NAnt ビルド スクリプトを使用してプロジェクト間の依存関係を定義できます。これには 2 つの欠点があります。

  1. あなたはそれをすべて手で管理しなければなりません（あなたはそうする準備ができているように聞こえます）
  2. Visual Studio は、現在と同じように機能しなくなります。

欠点 2 として、Visual Studio はソリューション全体をコンパイルできません。これは、そのロジックが VS から外部ビルド スクリプトに移されてしまうためです。これは、開発者の間で混乱を招き、デバッグ プロセスを妨げる可能性があります。それらが克服できないと言っているわけではありません...開発プロセスのこれらのステップで余分なセットアップが必要になると言っているだけです。

于 2009-11-09T18:44:13.830 に答える