Default or specify msbuild properties in an external file

Question

Ok, so I have a few dozen solutions all built using the exact same command line.

msbuild SolutionName.sln /p:property1=value1;property2=value2;etc etc etc.

Except the number of properties just grows and grows.

Is there a way to specify an external file some how so I don't end up with a 10 line msbuild command? (Think property 100, property 101, etc).

I'm aware of .wpp.target files. However, having to copy them into each project folder really... is my last resort.

And no, I'm not modifying any default MSBuild targets/files whatsoever.

Answer 1

To answer the original question, yes you can specify properties in an external file. They are called MSBuild response files.

msbuild somesolution.sln @PathToResponseFile.rsp

Inside the response file you can put your properties, one per line.

/verbosity:detailed
/target:build
/platform:AnyCPU
/configuration=Release

Some links to better understand: http://dailytechlearnings.wordpress.com/2011/08/24/msbuild-response-file/ http://msdn.microsoft.com/en-us/library/vstudio/ms404301.aspx

However, using an msbuild file to build your solutions and projects is a better solution. You can create global targets that will do exactly as you want. You can create your own custom Clean and Build targets that will then build/clean your solutions.

Answer 2

First of all - I would recommend you to use msbuild scripts to build your solutions, instead of direct building sln file using command line. E.g. use something like this:

msbuild SolutionName.Build.proj

and inside this Solution1.Build.proj you can put anything as simple as

<Project ToolsVersion="4.0" DefaultTargets="BuildMe" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <Target Name="BuildMe">
        <MSBuild Projects="SolutionName.sln" Properties="property1=value1;property2=value2;"/>
    </Target>
</Project>

After this step, which adds flexibility to your build process, you can start leverage AdditionalProperties metadata for MSBuild task.

Then you can use <Import construction to store your list of shared properties in a separate file and item metadata for passing property values:

<Project ToolsVersion="4.0" DefaultTargets="BuildMe" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <Import Project="MySharedProperies.props" />
    <ItemGroup>
      <ProjectToBuild Include="SolutionName.sln">
        <AdditionalProperties>SomeProjectSpecificProperty</AdditionalProperties>
      </ProjectToBuild>
    </ItemGroup>

    <Target Name="BuildMe">
        <MSBuild Projects="@(ProjectToBuild)" Properties="@(MySharedProperies)"/>
    </Target>
</Project>

You can check this post for more details about properties and additional properties metadata or this original MSDN reference (scroll to Properties Metadata section)

This is the base idea how to do it, if you have any questions - feel free to ask.

Answer 3

I use an Import file for things that are common across various projects.

  <Import Project="CommonBuildProperties.proj"/>

That file contains a PropertyGroup that has the things I want to have the same value across build projects. There's also a conditional statement there that sets certain folder names depending on the name of the computer it's running on. At runtime, if I need to override anything on the command line I do that.

I also have some project-specific Import files (one of our builds is a Powerbuilder application with its own toolset and pecadilloes); order of Import ensures if they require different values for the same element name I get what I want.

My command lines aren't horrible unless I'm doing something odd that needs most everything overridden. About the only things I have to pass in are version number and build type (release or debug).