[ACCEPTED]-Using MSBuild to Build Multiple Configurations-buildconfiguration
It is important to realize that when you 25 use a "MSBuild" task, a new child MSBuild 24 process will be started. The implication 23 of this is that any items and properties 22 you define in the parent MSBuild process 21 will not be automatically passed to/visible 20 from the child MSBuild process unless you explicitely 19 pass them via Properties
attribute on MSBuild
element (as 18 in <MSbuild Properties="..." />
).
To answer your question, I wrote the 17 following self-contained example that runs 16 a child MSBuild project for all the specified 15 configurations:
First, create a directory 14 for your MSBuild experiment (for example 13 I used
C:\temp\msbuildtest
)In this directory, create the first 12 file,
main.proj
:<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build" ToolsVersion="4.0"> <ItemGroup> <ConfigList Condition=" '@(ConfigList)' == '' and $(Config) != '' " Include="$(Config.Split('+'))" /><!-- parse all requested configurations into a list --> <ConfigList Condition=" '@(ConfigList)' == '' " Include="Debug" /><!-- if no configurations were specified, default to Debug --> </ItemGroup> <!-- Build the child project for each requested configuration. --> <Target Name="Build"> <MSBuild Projects="$(MSBuildProjectDirectory)\child.proj" Properties="Configuration=%(ConfigList.Identity);OutputPath=$(MSBuildProjectDirectory)\bin\%(ConfigList.Identity)" Targets="Build" /> </Target> </Project>
In the same directory, create the 11 second file,
child.proj
(in your case this would be 10 the actual C# project you're trying to build, but 9 because I'm trying to illustrate my point, I 8 am using a simple child project that instead 7 of running C# compiler just prints values 6 of properties :-) )<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build" ToolsVersion="4.0"> <Target Name="Build"> <Message Text="Building configuration $(Configuration) with output path $(OutputPath)" Importance="High" /> </Target> </Project>
Now you can run the example. First 5 the default, if you don't explicitly specify 4 configurations to build:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\msbuild main.proj > (cut the noise) > Build: > Building configuration Debug with output path C:\temp_c\d\bin\Debug
And then explicitly 3 specified multiple configurations:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\msbuild main.proj /property:Config=Debug+Release+Staging+Production > (cut the noise) > Build: > Building configuration Debug with output path C:\temp_c\d\bin\Debug > Build: > Building configuration Release with output path C:\temp_c\d\bin\Release > Build: > Building configuration Staging with output path C:\temp_c\d\bin\Staging > Build: > Building configuration Production with output path C:\temp_c\d\bin\Production
You should 2 be able to adapt this technique to your 1 situation.
Somthing is amiss in your project file. Consider 23 this XML:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == '' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>C:\Folder\Etc\Output\$(Configuration)\</OutputPath>
...
</PropertyGroup>
Those properties can never be set, since 22 even if $(Configuration) and $(Platform) are 21 empty, they can never match the empty string 20 when concatinated with the bar character; the 19 minimal value for that condition is '|' and 18 not ''. Even if corrected by making the 17 condition compare with '|', you then go 16 on to try to use $(Configuration) in the 15 OutputPath in that PropertyGroup, but $(Configuration) will 14 never have a value at the point it is used. Likewise, where 13 you try to set $(Platform) to 'AnyCPU' it 12 must already have that value. You probably 11 meant to omit the condition on the first 10 PropertyGroup altogether, and you may need 9 to supply default values for $(Configuration) and 8 $(Platform) in an early PropertyGroup with 7 no conditions as well. Diff your whole 6 project against a new project and see if 5 there are any other oddities like this present.
Also 4 notice that on your override of the "Build" target, you 3 have a redundant Condition on the MSBuild 2 task; with the same condition is on the 1 you don't need it on any of the tasks.
I am not quite sure if I'd wanna go through 7 such a convoluted configuration of the project's 6 csproj file itself. I'd rather setup a separate 5 MSBuild "BuildBoth.proj" file that has a 4 specific target called "Both" that builds 3 the solution in both configurations.
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Both">
<!-- Calls twice for both configs -->
<Target Name="Both">
<MSBuild Projects="buildboth.sln" Targets="Rebuild" Properties="Configuration=Debug"
StopOnFirstFailure="true">
</MSBuild>
<MSBuild Projects="buildboth.sln" Targets="Rebuild" Properties="Configuration=Release"
StopOnFirstFailure="true">
</MSBuild>
</Target>
<!-- single config targets
<Target Name="Debug">
<MSBuild Projects="buildboth.sln" Targets="Rebuild" Properties="Configuration=Debug"
StopOnFirstFailure="true">
</MSBuild>
</Target>
<Target Name="Release">
<MSBuild Projects="buildboth.sln" Targets="Rebuild" Properties="Configuration=Release"
StopOnFirstFailure="true">
</MSBuild>
</Target>
-->
</Project>
Then 2 I'd run the command (verbosity set Minimal) to 1 target Both
C:\Projects\experiments\BuildBoth>msbuild /v:m /target:Both BuildBoth.proj
Microsoft (R) Build Engine Version 4.0.30319.1
[Microsoft .NET Framework, Version 4.0.30319.225]
Copyright (C) Microsoft Corporation 2007. All rights reserved.
BothWpf -> C:\Projects\experiments\BuildBoth\BothWpf\bin\Debug\BothWpf.exe
BothWpf -> C:\Projects\experiments\BuildBoth\BothWpf\bin\Release\BothWpf.exe
More Related questions
We use cookies to improve the performance of the site. By staying on our site, you agree to the terms of use of cookies.