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

Question

在命令行中，我会打电话的MSBuild直接上一个项目，我什么时候会叫的MSBuild对工程中的的sln文件，传递/t:Build /t:ProjectName？

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

现在，在一个特定的自动化的情况下，我想在命令行只构建项目B：

我应该怎么称呼？：

（一）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基于相关性，这些都会简单地被忽略。
  • 在这个时代，你确实应该处理project2project的依赖关系，但是我认为在某些情况下坚持使用solution deps有一些半正确的理由。
• 宏值。与$(SolutionFileName)和相当一切与解决方案开始启动。如果您的项目或其依赖项使用以下任何一种：可能会出现细微差别的结果。

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

  这意思是，ESP。对于C++来说，当调用sln文件时，很可能需要指定一个不同的平台。例如，与解决方案，你会建立“混合平台”也许“任何CPU”，但对于项目你真正需要指定x64或Win32。

  所以这需要传递的平台可能有不同。

Answer 2

我该打什么电话？结果会有什么不同吗？莫不是在可能会错过这样的SLN文件中的任何额外的设置？

它`上加深你怎么表达项目之间的依赖关系，使用该解决方案来表达项目间的依赖或添加到项目的引用？

如果您使用该解决方案的项目之间表达的依赖，你应该调用命令行（一）。如果您调用命令行（b），则依赖项目将被忽略。由于该解决方案文件用于解析它进入的MSBuild一个临时项目文件在内部，所以如果你通过ProjB.vcxproj建设项目，这些依赖信息将被忽略。

例如，我创建了三个项目的解决方案，TestSample,TestSampleB,TestSampleC。使用该解决方案添加TestSampleB，TestSampleC参考TestSample（右键点击你的解决方案 - >属性 - >通用属性 - >项目依赖）：

当我们构建项目TestSample与（ b）命令行中，仅的项目TestSample建，TestSampleB，TestSampleC是忽略。

MSBuild "TestSample\TestSample.vcxproj" 

当我们调用（一）命令行，所有依赖项目建成：

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

如果添加引用到项目（右键点击项目 - >添加引用），你可以同时调用两条命令行。所有的依赖关系项目都将建成。

所以，如果你表达使用SLN文件中的项目之间的依赖关系，我建议您直接工作的这些依赖到该凸出文件，并从SLN删除它们。这将允许您从MSBuild的直接调用任何凸出文件和项目都将独立建立一个没有任何额外的工作。

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

如果构建项目没有与溶液中的其他项目的相互依赖关系，建立这个项目会比整体解决方案更快。

希望这会有所帮助。