1

ソリューションの一部を構築するために、大規模なMSBuildプロジェクトを開発しました。XMLの解析/置換、Windowsサービス、リモートコピーなど、さまざまなことが行われています。その結果、コメントに装飾を追加するために最善を尽くしたにもかかわらず、ファイルの管理が非常に困難になりました。

間抜けとして、機能の主要なチャンクを「XML.targets」、「Services.targets」などの個別のファイルに分割し、それらをメインの「Build.proj」にインポートしました。ビルドはまだ機能していて、すぐに管理しやすいことがわかりました。

ただし、MSBuildのインポート機能について読んだすべての情報は、再利用可能なターゲット、つまり、変更なしで任意のMSBuildプロジェクトで使用できるターゲットをインポートするために使用する必要があるということです。ここで作成している個別のプロジェクトは反対です。1つのプロジェクトに固有であり、変更しない限り、他のプロジェクトで使用するとデフォルトで機能しなくなります。

だから私が求めているのは、私ができるのに...私がすべきだと思いますか?大規模なプロジェクトを組織する目的で厳密にインポートを使用することには、固有の危険性がありますか?これを行うためのより良い方法はありますか?

ありがとう

4

1 に答える 1

1

いいえ、固有の危険はありません。全体的な複雑さを軽減するため、大きなプロジェクトを特定の操作に固有のいくつかの .targets ファイルに分割することは良い決断だと思います。再利用可能なターゲットを作成するという考えは、他の部分への依存をできるだけ少なくする必要があることを意味します。同様に、個別の .targets ファイルをクラスと考えることができます。結合が少ないほど良いです。1 つのターゲット ファイルを変更しても、プロセス全体が壊れる可能性は低いためです。一枚の紙を取り、メイン プロジェクトを中心にターゲット ファイルを点として描き、それらの間のすべての接続を描くことができます。あるターゲットファイルが別のターゲットファイルをオーバーライドするか、そこからいくつかのプロパティを期待するか、何らかの方法でそれに依存している場合、接続があるとします。完璧なシナリオでは、星のようなものを手に入れることができます。
要するに、複雑さを軽減する場合はすべきです。

于 2010-11-29T22:51:17.907 に答える