2

現在、いくつかのプロジェクトを共有する 2 つのソリューションと、それぞれに固有のプロジェクトがいくつかあります。現在、これらのソリューションごとに Gated Checkin に設定されたビルド定義があります。

残念ながら、ゲート付きチェックインが設定された複数の定義があるということは、共有プロジェクトの 1 つに変更を加えると、1 つの定義しか実行されないことを意味しているようです。完璧な世界では、この状況で両方のソリューションを構築したいと考えています.

両方のソリューションをビルドする単一のビルド定義を作成するだけでよいことはわかっています。これは問題のシナリオではうまく機能しますが、ソリューションに固有のプロジェクトを変更すると、両方のソリューションがビルドされます。 .

両方の長所を活かすようにビルドを構成する方法はありますか? 共有コードが両方のソリューションで正しく動作することを保証する一貫性を保ちたいと思いますが、どちらか一方のソリューションにのみ影響する変更にビルドに 2 倍の時間がかからないようにしたいと考えています (これまでで最も一般的なユース ケースです)。

それとも、どちらか一方のトレードオフに固執しているだけですか?

4

1 に答える 1

0

あなたの現状の基本的な問題は、「変化をどのように特定するか」ですか?変更されたのが共通プロジェクトか固有プロジェクトか。コードのビルド時にこれを特定する簡単な方法はないと思います。

あなたが最善の解決策ではないオプションの1つは、共通のプロジェクトを別のソリューションに分離し、DLLをコンパイルして、独自のソリューションが使用する共通の場所に配置することです。このようにして、3 つの独立した gated-checkin を持つことができます。共通のソリューションに変更がある場合は、同じビルド定義内で両方の固有のソリューションをコンパイルします。そうでない場合は、共通のソリューションと独自のソリューションを独自のビルド定義でコンパイルします。

于 2013-07-10T17:40:17.163 に答える