Home > Deployment > Commandline msbuild in action

Commandline msbuild in action

January 15th, 2010 Leave a comment Go to comments

Commandline msbuild

So you’ve checked out the code. Now commandline it to the root folder of the project. Run msbuild.exe. Did it work? Probably not. That is because you don’t have msbuild on your path environment variable. There’s a couple of ways. When you installed Visual Studio, on the Start Menu it provides you with starting a console with msbuild on path.

Starting console from Start Menu

Alternative one, go and update your path environment variable for all time.

[pict - Changing environment variable]

Alternative two, you can double click on build.bat. (But you are only delaying the inevitable getting msbuild on path)

Double click on bat file in folder

Here’s the resulting console. Msbuild automatically uses build.proj because (a) it is a proj file and (b) it is the only one in the folder.

msbuild with Help (1 of 2)

msbuild with Help (2 of 2)

Help as default target

What you see in the screen above is that our build file by default makes no action other than to tell you what you can do. In other words, by default it won’t do bad. I therefore always have a Help target in every proj and task file and that that is the Default target. Here is an example from build.tasks that demonstrates how the default target is Help and what the structure of the help information.

<Project DefaultTargets="HelpBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <Target Name="HelpBuild">
    <Message Text="

    msbuild /t:Package

      msbuild /t:Install
      msbuild /t:Install /p:ReleaseEnvironment=Beta
      msbuild @build.properties /t:Package /v:d 

    Variables that can be overridden:

     - Compile
     - Clean
     - CleanReleases
     - Publish
     - Zip
     - Extract
     - Deploy
     - TODO

     - Package (Compile;Clean;Publish;Zip)
     - Install (Compile;Clean;Publish;Zip;Extract;Deploy) - will require IIS
                                                            setup because it 
                                                            runs the 
                                                            set of tasks

    Log output: msbuild.log

    Dependencies: Zip/Extract must have J# Redist installed


             " />


The general structure for help is as follows:

  • what your likely (default) call is going be
  • examples of likely calls including variables
  • variables that can be overridden
  • targets
  • additional information

Tip: Don’t make the text in the help wider than 64 characters so that it looks pretty in the console

Build.proj as manifest and linking helps

When you ran msbuild, it also showed a number of Help targets. This is because the primary job of the build.proj is to link all the targets together. It looks like this and the points to note are:

  • Import includes each tasks
  • Help is the default target that calls the help targets in of the child tasks

Note: we need to suffix each Help (eg Build = HelpBuild, Package = HelpPackage) to avoid warnings in msbuild.

<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Help"  ToolsVersion="3.5" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildProjectDirectory)\scripts\build.tasks" />
  <Import Project="$(MSBuildProjectDirectory)\scripts\package.tasks" />
  <Import Project="$(MSBuildProjectDirectory)\scripts\install.tasks" />
  <Import Project="$(MSBuildProjectDirectory)\scripts\db-setup.tasks" />
  <Import Project="$(MSBuildProjectDirectory)\scripts\migrations.tasks" />

  <Target Name="Help" DependsOnTargets="HelpBuild;HelpPackage;HelpInstall;HelpDbSetup;HelpMigrations"/>


  • Setup msbuild on path
  • Always have Help as a default target
  • Tasks files need the Help target to have the task suffix to avoid warnings [bla microsoft]
Categories: Deployment Tags:
  1. No comments yet.
  1. No trackbacks yet.