When MSBuild was first released, it was seen as a stopgap measure. Prior to its introduction, building a non-trivial .NET project from the command line was a daunting challenge. Either command line options have to be carefully laid out or third-party libraries like NAnt have to be brought in.

Recently MSBuild Extension Pack was released on CodePlex. Run by Mike Fourie and a team of 5 developers, this successor to FreeToDev MSBuild Extensions has over 170 different tasks for MSBuild. Many of these tasks support a MachineName argument allowing the actions to be performed on a remote machine.

The team summarizes the tasks into these categories:

• System Items: Certificates, COM+, Console, Date and Time, Drives, Environment Variables, Event Logs, Files and Folders, GAC, Network, Performance Counters, Registry, Services, Sound
• Code: Assemblies, CAB Files, Code Signing, File Detokenisation, GUID’s, Mathematics, Strings, Threads, Zip
• Applications: BizTalk 2006, Email, IIS7, MSBuild, SourceSafe, StyleCop, Team Foundation Server, Visual Basic 6, WMI

The other day I got a question: How can I deploy an app via ClickOnce using Team Build?

There is not out of box way to do that, but we can do it with a simple workaround:

we should overload the target AfterCompile in TFSBuild.Proj to call MSBuild Task Publish and can pass the PublishDir property:

<Target Name="AfterCompile">
  <MSBuild
  Condition=" '@(SolutionToBuild)'!='' "
  Projects="@(SolutionToBuild)"
  Properties="Configuration=%(ConfigurationToBuild.FlavorToBuild);
    Platform=%(ConfigurationToBuild.PlatformToBuild);
    SkipInvalidConfigurations=true;
    VCBuildOverride=$(MSBuildProjectDirectory)\TFSBuild.vsprops;
    FxCopDir=$(FxCopDir);OutDir=$(OutDir);
    PublishDir=$(OutDir);
    ReferencePath=$(ReferencePath);
    TeamBuildConstants=$(TeamBuildConstants);
    $(CodeAnalysisOption);PublishDir=\\qa1Srv\drops\publishedVers\ "
  Targets="Publish" />
</Target>

When you want to build and deploy database projects with team build you need to edit the database project file and the Team Build file. That’s because database projects store any non-default values for the TargetDatabase, TargetConnectionString, and DefaultDataPath properties in a <ProjectName>.dbproj.user file.  *.user files are not checked into version control in order to let every user use different values.

Step 1 - Modify build project file (team build .proj file)

Open the BuildDefinition.proj file, and at the bottom of the file, between the </ItemGroup> element and the </Project> element, add the following:

<Target Name="AfterDropBuild">  <MSBuild Projects="$(SolutionRoot)\SolutionName\ProjectName\ProjectName.dbproj"       Properties="Configuration=Default;OutDir=$(SolutionRoot)\..\binaries\Default\" Targets="Deploy" /></Target>

Step 2 - modify the database project file

The target connection and database are stored in the ProjectName.dbproj.user file, which is user specific and not typically checked in to version control. You require those settings to deploy your database. Therefore, you must modify the ProjectName.dbproj file manually to specify the target connection and database.

Copy the lines that contain the definitions for the TargetDatabase and TargetConnectionString properties from the section in the ProjectName.dbproj.user file for the configuration that you want to build. These lines will resemble the following:

<TargetDatabase>MyTargetDatabaseName</TargetDatabase><TargetConnectionString>Data Source=ServerName\InstanceName;Integrated Security=True;Pooling=False</TargetConnectionString>

If TargetDatabase and TargetConnectionString already contain empty elements, you should overwrite those entries.

More into at the msdn page.

The ability to remove entries from ItemGroups is one of the new features of MSBuild 3.5.

To remove an Item from an ItemGroup in MSBuild 2.0 you would have to create a new ItemGroup from the old one and skip the Item that you needed removed.

In MSBuild 3.5 we can achieve it by using the Remove parameter.

Example:

<ItemGroup>    <Files Include="a.cs" />    <Files Include="b.cs" />    <Files Include="c.cs" />    <Files Include="d.cs" />    <Files Include="e.cs" />    <Files Include="f.cs" />    <Files Include="g.cs" /></ItemGroup>

Some times we want to restrict some data from this group in a target. In order to do it,  we should use the Remove parameter:

<ItemGroup>    <Files Remove="a.cs" />    <Files Remove="e.cs" />    <Files Remove="f.cs" /></ItemGroup>

Read more at msdn.

Aaron Hallberg has posted a great reference to the Team Build 2008 built-in properties.

You can find it at: http://blogs.msdn.com/aaronhallberg/archive/2008/02/12/team-build-2008-property-reference.aspx

Many users want to modify the default build number of Team System Team Build which looks like: <Build-Type-Name>_<Date>.XXX.

You can change it by writing a custom task and call it in the BuildNumberOverrideTarget target of the MSBuild file. In this example the task will generate a unique build number based on current time:

using System;using Microsoft.Build.Utilities;using Microsoft.Build.Framework;

namespace MaorDavidBlog.Samples.MSBuild{    public class BuildNameGenerator:Task    {

        private string _buildName;

        public override bool Execute()

        {                        _buildName = DateTime.UtcNow.ToString();            return true;        }

        [Output]        public string BuildName

        {            get { return _buildName; }        }

    }}

The attribute “Output” indicates that BuildName property is output of the custom task.

Then, register the task in TFSBuild.proj file.

<!-- Add using task line just after import statement - - ><UsingTask  TaskName="MaorDavidBlog.Samples.MSBuild.BuildNameGenerator"   AssemblyFile="$(MyCustomTasks)\MaorDavidBlog.Samples.MSBuild.dll"/>

<! -- Override the target towards the end of proj file - - ><Target Name = "BuildNumberOverrideTarget" >    <BuildNameGenerator>             <Output TaskParameter="BuildName"            PropertyName="BuildName"/>     </BuildNameGenerator> </Target>

Next time you’ll execute your build, you’ll see your custom build name.

I got today hysterical message from a good friend that implementing in his company automatic build with Team System. The message was: “Maor, How can I copy wildcards With MSBuild? Please help!!!”.

Okay. What you should do my dear friend is:

1. Create an item list if you have more than one file to copy. You can do it with the CreateItem task:

<CreateItem Include="$(MyDir)\*.*">    <Output TaskParameter="Include" ItemName="MyFilesToCopy" /></CreateItem>

2. Copy!

<Copy SourceFiles="@(MyFilesToCopy)" DesginationFolder="$(MyPutputDir)" />

3. Execute your build script.

Ah, by the way, if you want to recursively copy files using the <Copy> task, read this post from MSBuild Team Blog.

Enjoy!

VSTS for DB Professionals (aka “Data Dude” or “VSDBPro”) provides great tools for schema and data compare.

Like most Visual Studio-based project systems, the core tasks inside the VSDBPro project implemented as MSBuild tasks. The two core activities for Database Projects (.dbproj), “Build” and “Deploy” are implemented by two MSBuild tasks named “SqlBuildTask” and “SqlDeployTask.”

Sometimes, we also need to automate the schema and data compare processes. We can do it with new MSBuild dedicated tasks that shipped with Power Tools for Data Dude Currently available for VSTS 2005)

• SqlDataCompareTask: allows you to compare the content of tables within two databases from the command line using MSBuild
• SqlSchemaCompareTask: allows you to compare schemas between two database from the command line using MSBuild

How should you use it?

First, install the Power Tools. Download from here. (notice that the power tools requires Data Dude Service Release 1 installed).

After you installed the power tools you can use the tasks in your MSBuild script.

Example:

  <!--Import the settings-->  <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v8.0 \TeamData\Microsoft.VisualStudio.TeamSystem.Data.PowerTools.Tasks.targets"/>

  <Target Name ="DataCompare">    <SqlDataCompareTask       SourceConnectionString="Data Source=(.);Integrated Security=True;Pooling=False"        SourceDatabaseName="SourceDB"        TargetConnectionString="Data Source=(.);Integrated Security=True;Pooling=False"        TargetDatabaseName="TargetDB"        OutputPath = "$(temp)"        OutputFileName = "DataCompare.sql"/>  </Target>

Notice that the task does not allow you to compare against the project right now. Same way you can use the SqlSchemaCompareTask.

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v8.0\TeamData\Microsoft.VisualStudio.TeamSystem.Data.PowerTools.Tasks.targets"/><Target Name ="SchemaCompare">    <SqlSchemaCompareTask    SourceConnectionString="$(SourceConnectionString)"    SourceDatabaseName="$(TargetDatabase)"    TargetConnectionString="$(TargetConnectionString)"    TargetDatabaseName="$(TargetDatabase)"    OutputPath = "$(IntermediateOutputPath)"    OutputFileName = "$(TargetDatabase)SchemaCompare.sql"    IgnoreChecks ="true"/></Target>

The properties exposed by the MSBuild tasks are documented via an accompanying XSD file located in:

%ProgramFiles%\Microsoft Visual Studio
8\Xml\Schemas\1033\MSBuild\Microsoft.VisualStudio.TeamSystem.Data.PowerTools.Tasks.xsd

Building non-MSBuild projects is possible. For example you have to build VS2003, Installer, C++, Delphi projects etc. How can you do it? It’s simple.

The MSBuild has a built-in task: Exec task. This task calls cmd.exe instead of directly invoking a process and runs the specified program or command with the specified arguments. You can use it in order to build non-MSBuild projects.

For example, in order to build a Visual Studio 2003 Project you should modify the MSBuild file as:

   1:  <PropertyGroup>

   2:  <VS2003_Devenv>$(ProgramFiles)\Microsoft Visual Studio .NET 2003\Common7\IDE\devenv.com</VS2003_Devenv>

   3:  <VS2003_SolutionName>$(SolutionRoot)\vs2003\VS2003Application\VS2003SLN.sln</VS2003_SolutionName>

   4:  <VS2003_Configuration>Debug</VS2003_Configuration>

   5:  </PropertyGroup>

   6:  

   7:  

   8:  <Target Name="AfterCompile">

   9:  <Exec Command="&quot;$(VS2003_Devenv)&quot; &quot;$(VS2003_SolutionName)&quot; /build $(VS2003_Configuration)"/>

  10:  

  11:  <MakeDir

  12:  Directories="$(BinariesRoot)\$(VS2003_Configuration)"

  13:  Condition="!Exists('$(BinariesRoot)\$(VS2003_Configuration)')" />

  14:  

  15:  <Copy

  16:  SourceFiles="$(SolutionRoot)\vs2003\VS2003Application\bin\$(VS2003_Configuration)\**\*.*"

  17:  DestinationFiles="$(SolutionRoot)\vs2003\VS2003Application\bin\$(VS2003_Configuration)\**\*.* ->'$(BinariesRoot)\$(VS2003_Configuration)\%(RecursiveDir)%(Filename)%(Extension)')"

  18:  />

  19:  </Target>

Read here for more information about the target names and the MSBuild configuration file.

First declare some variables to use them during the build. (Lines 1 - 5) . Next in the AfterCompile target, use the MSBuild Exec task to build the VS2003 project by invoking the devenv.com program (Lines 9 -10). After that make a directory (using MakeDir task) for the output (if not exists) (Lines 11 - 13). Finally copy (using the Copy task)the output files to the build binaries root (Lines 15 - 18).

Notice that this assumes VS 2003 is installed on the build machine.

Good Luck!

Dan Moseley, a developer on the MSBuild team, wants to know how you would prioritize features for the next version of MSBuild by asking, How would you spend $100 on MSBuild?

This is a great opportunity to influence the future of MSBuild, so be sure to post your opinion.

My choice:

Visualization - $30

Msbuild debugger - $25

Vc support - $20

Extensible functions - $5

Inline tasks  - $20