What is the proper way of using /p per build step in a TeamCity build configuration?

Question

In TeamCity I created a Build Configuration with two msbuild Build Steps which should build a Solution .sln file.

I defined the target as "Build", when I run the build, both steps obviously execute the standard configuration and both build either Debug or Release configuration twice.

Now I went to the build step settings and found the CommandLine argument, for Debug I added /p:Configuration=Debug, for Release I added /p:Configuration=Release.

Building this results in a warning of TeamCity:

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

Although one debug and one release has been build.

I googled this message and created two System Parameters: /p:Configuration=Debug and /p:Configuration=Release. If I would now change my command line for debug to %system.DebugConfig% and for release to %system.ReleaseConfig% I get the same error. Only then I really understood that those system parameters will be passed to each build step never automatically, always.

Ok, but how do I properly define two different build steps building debug and release using system parameters or without team city complaining about /p found in command line?

Answer 1

There is no way to do this (that I know of, bear with me) but there are enough alternatives:

If you're willing to drop seperate build steps and instead use seperate builds instead - which normally shouldn't be any problem, use templates: create a build template in which you add all parameters which have to be configurable, like Configuration in your case and give them suitable defaults. Then create a build configuration for each combination of properties you want and in that configuration override the parameters.

Another option: do it yourself. I've switched between a couple of CIs in the past and it became pretty obvious that the more you rely on a CI system's features, the harder it becomes to test builds manually, the more cumbersome it gets crawling through the CI system's web interfaces or databases or config files to find the right configuration parameters, and the more crippled the transition to another CI becomes. So at one point I just gave up on it and wrote a couple of msbuild 'master' scripts which would build everything with one click of the button so to speak, remember the Joel Test, but on any machine I want, including my own, without the need for any CI at all. That was such a relief that I haven't looked back since, and the CI configuration now is kept to a minimum. Applied to your case: create an msbuild file as below and a build step in TC which invokes it's Build target and has a MyTargetProjectFile system parameter poiting to the actual project file:

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

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

Yet another option: just ignore TeamCity's warning. It was never clear to me why they insist in doing it this way, it seems counterintuitive and leads to questions like this one :] Having different build steps with different properties seems like a rather basic requirement, no? I don't think we have any msbuild step not using /p and it all works just fine.