何时需要向 MSBuild 传递解决方案文件？答案

【问题标题】：When do I need to pass MSBuild a solution file?何时需要向 MSBuild 传递解决方案文件？
【发布时间】：2017-10-19 10:08:17
【问题描述】：

从命令行，我什么时候可以直接在项目上调用 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"

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

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

【问题讨论】：

标签： visual-studio visual-c++ msbuild sln-file

【解决方案1】：

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

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

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

例如，我创建了一个包含三个项目的解决方案，TestSample、TestSampleB、TestSampleC。使用解决方案将TestSampleB、TestSampleC 引用添加到TestSample（右键单击您的solution->Properties->Common Properties->Project Dependencies）：

当我们使用(b)命令行构建项目TestSample时，仅构建了项目TestSample，TestSampleB，TestSampleC是忽略。

MSBuild "TestSample\TestSample.vcxproj"

当我们调用 (a) 命令行时，所有的依赖项目都构建完成了：

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

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

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

如果解决方案很大，但 ProjB 与解决方案中的其他项目几乎没有相互依赖关系，一般来说一个选项会更快吗？

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

希望这会有所帮助。

【讨论】：

【解决方案2】：

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

很明显，如果您有其他基于sln 的依赖项，这些将被忽略。
- 在当今时代，您确实应该使用 project2project 依赖项，但我认为在某些情况下坚持使用解决方案部门有一些半正当的理由。
宏值。从 $(SolutionFileName) 开始，以及从解决方案开始的所有其他内容。如果您的项目或其依赖项使用以下任何一种：可能会产生微妙的不同结果。
平台。天哪。你看，它们是解决方案平台工作的方式，它们基本上只是一个命名容器，用于将项目平台选择组合在一起。

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

所以需要通过的平台可能必须不同。

【讨论】：