How to build both Debug and Release for a TeamCity project

Question

The first idea that comes to my mind is to use two Visual Studio (.sln) build steps - one for each configuration. (Multiple builds steps supports on TC v5+).

Is there a better way?

Solution 1

We have two separate MSBuild targets that build the solution using different properties:

<Target Name="Build-Debug">
    <MSBuild Projects="OurSolution.sln" Targets="Rebuild" Properties="Configuration=Debug" />
</Target>

<Target Name="Build-Release">
    <MSBuild Projects="OurSolution.sln" Targets="Rebuild" Properties="Configuration=Release" />
</Target>

From TeamCity, we have one "Configuration" (in TeamCity-speak) that calls the Build-Debug target, and another that calls the Build-Release.

Solution 2

We always wrap the sln build with an msbuild to add in running tests, building sql scripts, etc. At this point you could call out to the sln and set the appropriate property values; Configuration=Debug and Configuration=Release

Unless you are just trying to do release with pdb files (which is always a good idea) in which case just change the properties in the build section in Visual Studio

Comments

[Tomas Kubes]

possible duplicate of Starting running all build configuration in TeamCity

[Jack Ukleja]

Thanks for response. Can you explain more details about the pdb issue?

[Adam Straughan]

having pdb file available is useful to add detail in the event of an error in production. You can tell VS to build the pdb files even in the optimized build (aka Release). In Project properties, Build, Advanced, Debug Info, set to pdb-only (having just looked it seems to be the default, but that might just be me). This myay give you more info vanryswyckjan.blogspot.com/2005/09/…

[Luke Puplett]

If anyone knows where this XML should go, adding it would hugely improve this answer. Project file?

[C.B.]

Also, the point was to build both at the same time... Having separate configurations is no better than the default case.

[Jack Ukleja]

@luke I think the intention is this XML would go into a standalone msbuild file. All it is doing though is invoking msbuild again on your solution with the requisite parameters. To be honest I don't see much value in this ... It's basically creating two extra targets but you still have to invoke msbuild twice