4

私の前の質問の論理的なフォローアップ: 「ソリューション内のすべてのプロジェクトをいくつかの基準でチェックする方法は?」
CustomAfterMicrosoftCommonTargets、CustomBeforeMicrosoftCommonTargets を使用するという非常に良い答えが得られました。それらは機能するので、途中でやめないことにしました。

問題は、マシン全体のタスクが必要ないことです。私にとっても（他のビルドに影響します。確かに、これは処理できますが、それでも）、チームメイトにとっても（システムフォルダーに何かを入れさせたくありません...）、どちらにとっても良い考えではありません。ビルドサーバー用。必要なもの: Visual Studio または MSBuild のいずれかを使用して、クリーン マシン上でソース管理からゼロから構築するソリューション。

Custom*MicrosoftCommonTargets は通常のプロパティのようです。

では、このプロパティを指定するにはどうすればよいでしょうか。コマンドラインから設定すると、かなりうまく機能します。これは奇妙ですが、ここにちょっとした魔法が存在するようです:コマンド ライン パラメーターとして 1 つのビルドに渡されたプロパティは、ネストされたすべてのビルドに推移的に渡されます!

ビルドサーバーには問題ありません。ただし、これは Visual Studio ビルドでは機能しません。また、ソリューション レベルのプロパティを宣言しても役に立ちません。静的プロパティも動的プロパティもネストされたビルドに転送されません。

...ソリューションのビルド前に環境変数を設定し、後で消去するというハックなアイデアがあります。しかし、私はそれが好きではありません。より良いアイデアはありますか？

4

2 に答える 2

0

@Spider M9とは少し異なるテクニックを使用しています。ソリューション ツリー内のすべてのプロジェクト/現在のディレクトリのすべてのサブディレクトリで、拡張ビルド スロー Custom*MicrosoftCommonTargets を使用する必要があります。カスタム ターゲット/小道具をインポートするためにすべての新しいプロジェクトを変更することを余儀なくされるのは好きではありません。

特別なファイル、たとえばmsbuild.includeをルート ディレクトリに配置し、すべてのプロジェクトのカスタム ターゲット ローダーがそれを で見つけようとします。、..\、..\..\など。msbuild.include には、カスタム アクションの実行をトリガーするフラグが含まれています。ローダーがこのファイルを見つけられない場合、すべてのカスタム ターゲットの読み込みが無効になり、停止します。これにより、自分のビルド拡張機能を作業リポジトリのプロジェクトで使用でき、オープンソース プロジェクトでは使用できなくなります。

興味があれば、ローダーを公開できます。これは非常にシンプルでエレガントなソリューションです。

たとえば、すべてのサブフォルダー内のすべてのプロジェクトの任意のアセンブリに自分のキーで署名できます。

于 2011-04-21T06:05:25.510 に答える
-1

私は常に、すべてのプロジェクトで標準の .props ファイルをインポートするように設定しています。GetDirectoryNameOfFileAbove プロパティ関数 (MSDN を参照) を使用して検索します。これをすべてのプロジェクト ファイルの最初の行として行います。確立したら、そのファイルから他のインポートにリダイレクトできます。別のトリックは、その標準インポート (明らかにバージョン管理下にあります) に、別の .props ファイルが存在する場合にのみ条件付きでインポートさせることです。このオプションのファイルはバージョン管理されませんが、開発者は独自のプライベート/一時プロパティまたはその他の動作で作成および変更できます。

于 2011-04-21T01:08:25.593 に答える