我什么时候需要传递MSBuild解决方案文件？

Question

从命令行，我何时直接在项目上调用MSBuild，何时在projec的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"

（b）MSBuild "ProjB.vcxproj" "/t:Build" "/p:Configuration=Release" "/p:Platform=Any CPU"

• 结果会有什么不同吗？
• 可能 sln文件中是否有任何其他设置错过了这种方式？ （我当然在VS2015 sln文件中看不到任何其他信息。）
• 如果解决方案很大，但ProjB与解决方案中的其他项目几乎没有相互依赖关系，那么一个选项会更快吗？

Answer 1

  

我该怎么称呼？结果会有什么不同吗？ sln文件中是否有任何其他设置可以通过这种方式错过？

深入研究如何表达项目之间的依赖关系，使用解决方案来表达项目之间的依赖关系或添加对项目的引用？

如果使用解决方案来表达项目之间的依赖关系，则应调用命令行（a）。如果调用命令行（b），将忽略依赖项目。因为解决方案文件用于在内部将其解析为MSBuild中的临时项目文件，所以如果您通过ProjB.vcxproj构建项目，那么将忽略这些依赖项信息。

例如，我创建了一个包含三个项目的解决方案TestSample，TestSampleB，TestSampleC。使用该解决方案将TestSampleB，TestSampleC引用添加到TestSample（右键单击解决方案 - ＆gt;属性 - ＆gt;公共属性 - ＆gt;项目依赖项）：

当我们使用（b）命令行构建项目TestSample时，仅项目TestSample已构建，TestSampleB ，TestSampleC被忽略。

MSBuild "TestSample\TestSample.vcxproj"

当我们调用（a）命令行时，所有依赖项目都已构建：

MSBuild "TestSample.sln" /t:"TestSample"

如果添加对项目的引用（右键单击项目 - ＆gt;添加引用），则可以同时调用两个命令行。将构建所有依赖项目。

所以，如果你使用sln文件表达项目之间的依赖关系，我建议将这些依赖项直接用于proj文件并从sln中删除它们。这将允许您直接从MSBuild调用任何proj文件，并且项目将独立构建而无需任何额外的工作。

  

如果解决方案很大，但ProjB与解决方案中的其他项目几乎没有相互依赖性，那么一个选项通常会更快吗？

如果构建项目与解决方案中的其他项目没有相互依赖性，那么构建此项目将比整个解决方案更快。

希望这有帮助。

Answer 2

到目前为止，我可以确定这些问题：

• 很明显，如果您有其他基于dense_shape=[batch_size, max_vector_length]的依赖项，那么这些依赖项将被忽略。
  • 在这个时代，你真的应该使用project2project依赖项，但我认为在某些情况下坚持使用解决方案deps有一些半正当理由。
• 宏值。从sln开始，以及从解决方案开始的所有其他内容。如果您的项目或其依赖项使用以下任何一项：可能会产生微妙的结果。

• 平台。 哦，我的。你看，他们的解决方案平台工作方式，它们基本上只是一个命名容器，可以将项目平台选择组合在一起。

  这意味着什么，尤其是对于C ++，在调用$(SolutionFileName)文件时，很可能需要指定不同的平台。例如，使用该解决方案，您可以构建“混合平台”或“任何CPU”，但对于项目，您实际上需要指定sln或x64。

  因此，需要传递的平台可能必须有所不同。