3

从命令行，我什么时候会直接在项目上调用 MSBuild，什么时候会在项目sln文件上调用 MSBuild，传递/t:Build /t:ProjectName？

示例：我有一个包含多个项目（A、B、C、...）的简单解决方案。开发是通过 VS GUI 通过打开和使用解决方案来完成的。

现在，在一个特定的自动化案例中，我只想从命令行构建项目 B：

我应该怎么称呼？：

（一种）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会以这种方式丢失？（我当然没有在我们的 VS2015sln文件中看到任何其他信息。）
  • 如果解决方案很大，但 ProjB 与解决方案中的其他项目几乎没有相互依赖关系，那么一种选择通常会更快吗？
4

2 回答 2

3

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

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

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

例如，我创建了一个包含三个项目的解决方案，TestSample, TestSampleB, TestSampleC。使用解决方案添加TestSampleB，TestSampleC引用TestSample（右键单击您的解决方案->属性->通用属性->项目依赖项）：

在此处输入图像描述

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

MSBuild "TestSample\TestSample.vcxproj"

在此处输入图像描述

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

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

在此处输入图像描述

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

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

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

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

希望这可以帮助。

于 2017-10-20T08:14:04.790 回答
0

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

  • 很明显，如果您有其他sln基础依赖项，这些将被忽略。
    • 在当今时代，您确实应该使用 project2project 依赖项，但我认为在某些情况下坚持使用解决方案部门有一些半正当的理由。
  • 宏值。从$(SolutionFileName)解决方案开始以及其他一切开始。如果您的项目或其依赖项使用以下任何一种：可能会产生微妙的不同结果。

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

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

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

于 2017-10-20T22:20:29.793 回答