7

背景: 私のチームは、かなり経験の浅い 3 人の開発者で構成されています。社内向けソフトウェアの開発を行っております。現在、いくつかの小規模で個別のソリューションがあります。これらの多くは相互に依存しています。現在、これらの依存関係は、それぞれのリリース フォルダー内の出力 dll を参照することによって作成されています。更新は、依存するソリューションを手動で再構築することによってプッシュされます。

例: ソリューション A はソリューション B の機能を使用します。接続は、ソリューション A が ...\Release\B.dll を参照するように行われます。B への変更は、ソリューション B を構築し、次にソリューション A を構築することによって伝播されます。

これは以前は問題なく機能していましたが、現在は手動の (気が遠くなるような) "バージョン管理システム" (folder1、folder2、folder2New...) から適切なバージョン管理システム (git) の使用に移行しています。

.dll のバージョン管理は推奨されないようです。これは、誰かが A の新しいバージョンをビルドするたびに、B の最新バージョンを入手するために B (およびおそらく 5 つの他のソリューション) もビルドする必要があることを意味します。

これを行うためのより良い方法がなければならないと考えています。関連するソリューションを 1 つのマスター ソリューションに結合することを検討してきましたが、Visual C# Express (使用している) でこれを行う方法がわかりません。

ついに質問があります：

  1. すべてを順調に構築するマスター ソリューションはありますか? -- MSDN からはそう思われますが、Visual C# Express 2008 でこれを行う方法がわかりません。

  2. これは Visual C# Express でも可能ですか? そうでない場合、問題を管理する良い方法は何ですか?

編集以下の素晴らしい提案に感謝します。これが私がやったことの要約です。

要するに、質問に対する答えは、「はい」と「まあまあですが、ほとんどはい」です。私は次のように実装しました: 依存関係のアイデアを得るために、以下の提案に従って実行し、dll または exe の名前からすべての依存関係を指す矢印を使用して、バイナリ製品のマップを描きました。

プロジェクトごとに、対応するソリューションを開きました(最初は1 つのソリューション pr プロジェクトがあったため)。次に、グラフに表示されたツリー構造に各依存関係のプロジェクト ファイルを追加し (ソリューション エクスプローラーでソリューションを右クリックして)、依存関係の依存関係なども含まれるようにしました。次に、古い参照 (.dll を直接指している) を削除し、代わりにプロジェクトへの参照を追加しました。

重要な結果は次のとおりです。

  • プロジェクトのソリューションがビルドされると、すべての依存関係がビルドされるため、展開時に、すべてのビルド製品が自動的に最新バージョンであることがわかります。
4

4 に答える 4

7

新しいソリューションを作成し、相互に関連するすべてのプロジェクトをそれに追加します。新しいソリューション内の異なるソリューション フォルダーにプロジェクトを配置することで、元の各ソリューションのプロジェクトをグループ化できます。このようにして、プロジェクトをビルドすると、そのプロジェクトが依存するすべてのプロジェクトもビルドされます。また、すべてのプロジェクトが同じ構成 (リリースまたはデバッグ) を使用してビルドされることも意味します。これは、依存関係ツリーの最上位のプロジェクトだけでなく、その下のすべてがリリース アセンブリであるすべてのプロジェクトをデバッグでビルドできることを意味します。デバッグがはるかに簡単になります。

于 2013-01-30T15:01:06.533 に答える
4

Visual C# Express 2010 を使用しており、新しいプロジェクトを作成すると、既定のソリューションが自動的に作成されます。表示されている場合は、ソリューションを右クリックして [追加] > [既存のプロジェクト] を選択できます。

解決策が表示されない場合 (C# Express 2005/8 でこの問題を覚えているようです)、[ファイル] > [追加] > [既存のプロジェクト] から既存のプロジェクトを追加できます。解決策が表示されるはずです。

スペレーションに関しては、私が通常行うことは次のとおりです。

一緒にビルドする必要があるものはすべて 1 つのソリューションにする必要があり、これらは DLL ではなくプロジェクトである必要があります。私はThe Joel List に従って生きようとしています。そこでは、プロジェクトを 1 つのステップで構築できるはずです。展開可能なユニットが 1 つの場合、ソリューションは 1 つになるはずです。私のプロジェクトはすべて、展開する前にビルド サーバー上でビルドされるため、ビルドする必要があるすべてのものがソリューションに含まれている必要があります。

デバッグを容易にするために、WCF サービス プロジェクトとクライアントを同じプロジェクトに入れることもありますが、クライアントとサーバーを個別に展開するかどうかによって異なります。通常、より大きなプロジェクトでは、それらを分離します。

最後に、例外が 1 つあります。さまざまなチームが使用する中央の共通ライブラリがあります。それが別のソリューションに含まれていて、1 つのチームが何かを変更すると、他のチームのビルドが壊れてしまいます。この場合、すべてのライブラリ プロジェクトを含む単一のソリューションを作成します。これらは、バージョンを保存する DLL にビルドされます。これらは、他のソリューションが使用できるフレームワークとして扱います。たとえば、チーム A は CommonLibrary 1.1 を使用し、チーム B は CommonLibrary 1.2 を使用しています。

于 2013-01-30T16:36:47.283 に答える
2

ソリューションは単なる「プロジェクトのグループ」と考える必要があります。プロジェクトは実際に「ビルド」されたものであり、「ソリューション」ではありません (完全にそうではありません。ソリューションは、含まれているプロジェクトを参照する「メタプロジェクト」に変換されます)。プロジェクトですが、真実に十分近いです)

ソリューション間に相互依存関係がある場合は、すべてのプロジェクトを大きなホワイトボードに描き、プロジェクトからプロジェクトへの依存関係を表す矢印を描くことをお勧めします。これが完了すると、適切な「プロジェクトのグループ化」が意味をなすものを一目で確認できるようになります。それらがソリューション ファイルになります。

たとえば、プロジェクト A、B、...、F があるとします。

  • A は B に依存する
  • B は C に依存する
  • D は C に依存する
  • E は F に依存する

ここで考えられる分割の 1 つは、プロジェクト A、B、C、D のソリューション 1 と、プロジェクト E、F のソリューション 2 です。

于 2013-01-30T15:29:09.850 に答える
-4

私はすべてのdllをプッシュするための共通の領域を思い付くでしょう。私の会社は「R」ドライブを使用しています。これは、誰もが持っているローカル（ネットワークではないため、他の人のフォルダに触れることができない）マップされたフォルダです。各ソリューションはこれに基づいて構築されます。プロジェクトを右クリックし、プロパティ->ビルドして出力を変更します。または、ビルド後のコマンドを追加して、そこにdllをプッシュすることもできます。その後、すべてのプロジェクトにこの場所を参照させます。

これが完了し、すべてが同じ場所を指している場合は、プロジェクトのさまざまな組み合わせをさまざまなソリューションに追加することもできます。開発者がUIプロジェクトのみを必要とする場合は、全体のサブセットである特別な「UI」ソリューションを開くことができます。

これは、プロジェクトのプロパティで使用するビルド後のイベントです->ビルドイベント

rem when building on local workstation copy dll to local R:\
if '$(BuildingInsideVisualStudio)' (
    xcopy $(TargetDir)$(TargetName).* R:\Extranet\$(TargetName)\1.0\  /Y
)
rem if "Enterprise" build then copy dll to Corp R:\ drive and to Build Machine R:\
if '$(Reason)' == 'Manual' (
    xcopy $(TargetDir)$(TargetName).* \\folder\$(TargetName)\1.0\ /Y
    xcopy $(TargetDir)$(TargetName).* R:\Extranet\$(TargetName)\1.0\ /Y
)
于 2013-01-30T15:03:36.593 に答える