msbuild - 在 TeamCity 构建配置中，每个构建步骤使用/p 的正确方法是什么？

Question

在 TeamCity 中，我创建了一个包含两个 msbuild 构建步骤的构建配置，它们应该构建一个解决方案 .sln 文件。

我将目标定义为“构建”，当我运行构建时，这两个步骤显然都执行标准配置，并且都构建了两次调试或发布配置。

现在我去了构建步骤设置，找到了 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.

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

我在谷歌上搜索了这条消息并创建了两个 System Parameters : /p:Configuration=Debug和 /p:Configuration=Release .
如果我现在将调试命令行更改为 %system.DebugConfig%并发布到 %system.ReleaseConfig%我犯了同样的错误。
直到那时我才真正明白，这些系统参数将永远不会自动传递给每个构建步骤。

好的，但是我如何使用系统参数正确定义两个不同的构建步骤来构建调试和发布，或者没有团队城市提示 /p在命令行中找到？

Answer 1

没有办法做到这一点(我知道，请耐心等待)，但有足够的选择:

如果您愿意放弃单独的构建步骤，而是使用单独的构建——这通常不会有任何问题，请使用模板:创建 build template在其中添加必须可配置的所有参数，例如 Configuration在您的情况下，并为他们提供合适的默认值。然后为您想要的每个属性组合创建一个构建配置，并在该配置中覆盖参数。

另一种选择:自己做。过去我在几个 CI 之间切换过，很明显，你越依赖 CI 系统的特性，手动测试构建就越困难，它在 CI 系统的 Web 界面中爬行就越麻烦，或者数据库或配置文件以找到正确的配置参数，并且向另一个 CI 的过渡变得更加瘫痪。因此，有一次我放弃了它并编写了几个 msbuild 'master' 脚本，这些脚本可以通过单击按钮来构建所有内容，可以这么说，记住 Joel Test ，但在我想要的任何机器上，包括我自己的机器，根本不需要任何 CI。这让我松了一口气，从那以后我就再也没有回头，现在 CI 配置保持在最低限度。适用于您的案例:创建一个 msbuild 文件，如下所示，并在 TC 中创建一个构建步骤，该步骤调用它的构建目标，并具有指向实际项目文件的 MyTargetProjectFile 系统参数:

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

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

另一种选择:忽略 TeamCity 的警告。我一直不清楚他们为什么坚持这样做，这似乎违反直觉并导致了这样的问题:] 具有不同属性的不同构建步骤似乎是一个相当基本的要求，不是吗？我认为我们没有任何不使用/p 的 msbuild 步骤，并且一切正常。