3

コマンド ラインから、いつプロジェクトで直接 MSBuild を呼び出し、いつプロジェクトのslnファイルでMSBuild を呼び出して、 /t:Build /t:ProjectName?

例: 複数のプロジェクト (A、B、C、...) を含む単純なソリューションがあります。開発は、ソリューションを開いて操作することにより、VS GUI を介して行われます。

ここで、特定の自動化されたケースで、コマンド ラインからプロジェクト B だけをビルドしたいと考えています。

何と呼べばいいですか？:

(a)MSBuild "my.sln" "/t:Build" "/t:ProjB" "/p:Configuration=Release" "/p:Platform=Any CPU"

(ロ)MSBuild "ProjB.vcxproj" "/t:Build" "/p:Configuration=Release" "/p:Platform=Any CPU"

  • 結果に違いはありますか？
  • この方法で見落とされる追加の設定がslnファイルにある可能性はありますか? (確かに、VS2015 ファイルに追加情報はありませんsln。)
  • ソリューションが大規模であるが、ProjB がソリューション内の他のプロジェクトとの相互依存性がほとんどない場合、1 つのオプションが一般的に高速になりますか?
4

2 に答える 2

0

これまでのところ、これらの問題を特定できます。

  • 明らかに、追加slnの依存関係がある場合、これらは単純に無視されます。
    • この時代では、実際には project2project の依存関係を処理する必要がありますが、場合によってはソリューション deps に固執する正当な理由がいくつかあると思います。
  • マクロ値。$(SolutionFileName)ソリューションから始まるすべてのことから始まります。プロジェクトまたはその依存関係でこれらのいずれかを使用すると、微妙に異なる結果が生じる可能性があります。

  • プラットホーム。オーマイ。ご覧のとおり、これらはソリューションプラットフォームの仕組みであり、基本的には、プロジェクト プラットフォームの選択をグループ化するための名前付きコンテナーにすぎません。

    これが意味することは、特にです。C++ の場合、slnファイルを呼び出すときに、別のプラットフォームを指定する必要がある可能性が非常に高くなります。たとえば、このソリューションでは、「Mixed Platforms」またはおそらく「Any CPU」をビルドしますが、プロジェクトでは実際にx64orを指定する必要がありますWin32。

    したがって、渡す必要があるプラットフォームは異なる必要がある場合があります。

于 2017-10-20T22:20:29.793 に答える