Partilhar via

Fancy New Command-Line Options For MSBuild

  • Artigo

A while back I had a post on the modified command-line options for file logging in MSBuild in the 3.5 .NET Framework.  The MSBuild team has since added some cool new command-line options here that will be available in the RTM version of VS 2008 (which will include the 3.5 .NET Framework).  In particular, you can now:

  • Generate logs that contain just the errors or warnings for the build. 
  • Attach multiple file loggers (up to 10, in fact).

For the former, you can do something like:

/flp:errorsonly

-or-

/flp:warningsonly

For the latter, you can do something like:

/flp1:logfile=normal.txt;verbosity=normal /flp2:logfile=diagnostic.txt;verbosity=diagnostic

Putting the two together, if you wanted to generate three logfiles for each of your Team Build builds - the standard one (BuildLog.txt) containing the normal verbosity output, one containing just errors, and one containing just warnings, you could add the following to your TfsBuild.rsp file:

/flp:verbosity=normal /flp1:errorsonly;logfile=BuildLog.err /flp2:warningsonly;logfile=BuildLog.wrn

One other fancy new feature the MSBuild team has added is the ability to specify  /maxcpucount (or just /m) on its own, rather than with an explicit maximum number of concurrent nodes to be used for the build.  Under the covers, MSBuild will determine the number of CPUs available on the build machine and use this number of nodes.  Unfortunately, this feature was added a bit too late in the game for support to be explicitly added to Team Build.  That is, the normal mechanism for enabling multi-process support in Team Build is to set the MaxProcesses key in the TfsBuildService.exe.config file on your build machine to the value that should be passed into MSBuild via the /m option - this value must be explicitly set to some integer value, however.  To take advantage of this feature, just skip this normal approach and add /m to your TfsBuild.rsp file - the "empty" option will override the standard option and your build will use a number of concurrent nodes corresponding to the number of CPUs available on the build machine.

Comments

  • Anonymous
    October 02, 2007
    PingBack from http://www.artofbam.com/wordpress/?p=4580
  • Anonymous
    October 04, 2007
    The comment has been removed
  • Anonymous
    October 21, 2007
    As you know, MSBuild in .NET 3.5 adds support for building projects concurrently. MSBuild.exe exposes