在TeamCity构建配置中，如何正确使用/p每个构建步骤？

Question

在TeamCity中，我创建了一个构建配置(Build Configuration)，其中包含两个msbuild构建步骤(Build Steps)，应该构建一个解决方案(.sln)文件。

我将目标定义为“Build”，当我运行构建时，两个步骤显然执行标准配置，并且都会将Debug或Release配置构建两次。

现在我进入构建步骤设置，找到了CommandLine参数，对于Debug，我添加了/p:Configuration=Debug，对于Release，我添加了/p:Configuration=Release。

构建后，TeamCity会产生一个警告：

MSBuild command line parameters contain "/property:" or "/p:". It is recommended to define System Property on Build Parameters instead.

虽然已经构建了一个调试版本和一个发布版本。

我搜索了这个信息并创建了两个 系统参数：/p:Configuration=Debug 和 /p:Configuration=Release。 如果我现在将我的调试命令行更改为 %system.DebugConfig%，将发布命令行更改为 %system.ReleaseConfig%，那么我会得到相同的错误。 只有在这时，我真正理解了这些系统参数将被传递给每个构建步骤而不是自动完成。

好的，但是如何使用系统参数或不让Team City抱怨在命令行中发现/p来正确定义构建调试和发布的两个不同的构建步骤？

- Samuel

Answer 1

目前我所知没有办法可以做到这一点，但有足够的替代方案：

如果你愿意放弃单独的构建步骤，而是使用单独的构建，这通常不应该有任何问题，那么可以使用模板：创建一个构建模板，在其中添加所有必须可配置的参数，例如你的情况下的Configuration，并给它们适当的默认值。然后为你想要的每个属性组合创建一个构建配置，并在该配置中覆盖参数。

另一个选择：自己动手。我过去曾经在几个CI系统之间切换，很明显，你越依赖CI系统的功能，就越难以手动测试构建，越麻烦，需要在CI系统的Web界面、数据库或配置文件中查找正确的配置参数，转换到另一个CI系统也更加困难。所以在某个时候，我放弃了它，写了几个msbuild“主”脚本，只需点击按钮即可构建所有内容，记住Joel Test，但可以在任何我想要的机器上，包括我的机器，而无需任何CI。这是如此令人宽慰，以至于我从那时起就没有回头看过去了，现在CI配置被保持到最少。应用于你的情况：创建一个如下的msbuild文件和一个在TC中调用其Build目标并具有指向实际项目文件的MyTargetProjectFile系统参数的构建步骤：

<ItemGroup>
  <Configurations Include="Debug;Release"/>
</ItemGroup>

<Target Name="Build">
  <MsBuild Projects="$(MyTargetProjectFile)" Targets="Build"
           Properties="Configuration=%(Configurations.Identity)"/>
</Target>

还有另一种选择：忽略TeamCity的警告。我从来没有明白为什么他们坚持这样做，这似乎是违反直觉的，并且会引发类似这样的问题：]具有不同属性的不同构建步骤似乎是一个相当基本的要求，不是吗？我认为我们没有任何不使用/p的msbuild步骤，而且一切都很顺利。

- stijn

---

谢谢您的见解。在工作中，我实际上编写了主msbuild文件，以防止构建代理死机（因为它们没有备份）。将它们配置回有效状态总是很麻烦，所以我确实创建了自己的目标。我想我会先忽略TeamCity的警告，并在看到需要更多/p参数时再创建主文件。 - Samuel