Tag: msbuild

Replicating Folder Structures in New Environments with MSBuild

Posted on by Scott

I recently received the task of modifying an existing MSBuild script to copy configuration files from one location to another while preserving all but the top levels of their original folder structure.  Completing this task required a refresher in MSBuild well-known metadata and task batching (among other things), so I’m recounting my process here for future reference.

The config files that needed copying were already collected into an item via a CreateItem task.  Since we’re using MSBuild 4.0 though, I replaced it with the simpler ItemGroup.  CreateItem has been deprecated for awhile, but can still be used.  There is a bit of debate over the precise differences between CreateItem and ItemGroup, but for me the bottom line is the same (or superior) functionality with less XML.

Creating a new folder on the fly is easy enough with the MakeDir task.  There’s no need to manually check whether or not the directory you’re trying to create already exists or not.  The task just works.

The trickiest part of  this task was figuring out what combination of well-known metadata needed to go in the DestinationFiles attribute of the Copy task to achieve the desired result.  The answer ended up looking like this:

<Copy SourceFiles="@(ConfigFiles)" DestinationFiles="$(OutDir)_Config\$(Environment)\%(ConfigFiles.RecursiveDir)%(ConfigFiles.Filename)%(ConfigFiles.Extension)" />

The key bit of metadata is the RecursiveDir part.  Since the ItemGroup that builds the file collection uses the ** wildcard, and it covered all the original folder structure I needed, putting after the new “root” destination and before the file names gave me the result I wanted.  Another reason that well-known metadata was vital to the task is that all the files have the same name (Web.config), so the easiest way to differentiate them for the purpose of copying was their location in the folder structure.

In addition to the links above, this book by Sayed Ibrahim Hashimi was very helpful.  In a previous job where configuration management was a much larger part of my role, I referred to it (and sedodream.com) on a daily basis.

New MSBuild 4.0 Features

Posted on by Scott

My current assignment has me working with the application build again.  MSBuild 4.0 got a number of new features which I’m only now getting to take advantage of.  The coolest one so far is the extensible task factory.  It lets you define custom MSBuild tasks right in the project file, instead of having to create a separate DLL for them.  Andrew Arnott wrote a custom factory that lets you define custom MSBuild tasks using PowerShell.  Because we’re using PowerShell for UI automation testing of our application, we’ll soon be able to integrate those tests into our build system.

Another feature I just learned about is conditional constructs.  They provide functionality equivalent to a case statement you might see in other languages. It’s much more flexible than the Condition attribute available on most MSBuild tasks.

Going beyond files with ItemGroup

Posted on by Scott

If you Google for information on the ItemGroup element of MSBuild, most of the top search results will discuss its use in dealing with files.  The ItemGroup element is far more flexible than this, as I figured out today when making changes to an MSBuild script for creating databases.

My goal was to simplify the targets I was using to create local groups and add users to them.  I started with an example on pages 51-52 of Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build, where the author uses an ItemGroup to create a list of 4 servers.  Each server has custom metadata associated with it.  In his PrintInfo target, he displays the data, overrides an element with new data, and even removes an element.  Because MSBuild supports batching, you can declare a task and attributes once and still execute it multiple times.  Here’s how I leveraged this capability:

  1. I created a target that stored the username of the logged-in user in a property.
  2. I created an ItemGroup.  The metadata for each group element was the name of the local group I wanted to create.
  3. I wrote the Exec commands to execute on each member of the ItemGroup

The ItemGroup looks something like this:

<ItemGroup>
<LocalGroup Include=”Group1″>
<Name>localgroup1</Name>
</LocalGroup>
<LocalGroup Include=”Group2″>
<Name>localgroup2</Name>
</LocalGroup>
<LocalGroup Include=”Group3″>
<Name>localgroup3</Name>
</LocalGroup>
</ItemGroup>

The Exec commands for deleting a local group if it exists, creating a local group, and adding the logged-in user to it, look like this:

<Exec Command=”net localgroup %(LocalGroup.Name) /delete” IgnoreExitCode=”true” />
<Exec Command=”net localgroup %(LocalGroup.Name) /add” IgnoreExitCode=”true” />
<Exec Command=”net localgroup %(LocalGroup.Name) $(LoggedInUser) /add” />

The result is that these commands are executed for each member of the ItemGroup.  This implementation makes a lot easier to add more local groups if necessary, or make other changes to the target.

When 3rd-party dependencies attack

Posted on by Scott

Lately, I’ve been making significant use of the ExecuteDDL task from the MSBuild Community Tasks project in one of my MSBuild scripts at work.  Today, someone on the development team got the following error when they ran the script:

“Could not load file or assembly ‘Microsoft.SqlServer.ConnectionInfo, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91’

It turned out that the ExecuteDDL task has a dependency on a specific version of Microsoft.SqlServer.ConnectionInfo deployed by the installation of SQL Server 2005 Management Tools.  Without those tools on your machine, and without an automatic redirect in .NET to the latest version of the assembly, the error above results.  The fix for it is to add the following XML to the “assemblyBinding” tag in MSBuild.exe.config (in whichever .NET Framework version you’re using):

<dependentAssembly>
<assemblyIdentity name=”Microsoft.SqlServer.ConnectionInfo” publicKeyToken=”89845dcd8080cc91″ culture=”neutral” />
<bindingRedirect oldVersion=”0.0.0.0-9.9.9.9″ newVersion=”10.0.0.0″ />
</dependentAssembly>

Thanks to Justin Burtch for finding and fixing this bug.  I hope the MSBuild task gets updated to handle this somehow.

MSBuild Transforms, Batching, Well-Known Metadata and MSTest

Posted on by Scott

Thanks to a comment from Daniel Richardson on my previous MSTest post (and a lot more research, testing, & debugging), I’ve found a more flexible way of calling MSTest from MSBuild.  The main drawback of the solution I blogged about earlier was that new test assemblies added to the solution would not be run in MSBuild unless the Exec call to MSTest.exe was updated to include them.  But thanks to a combination of MSBuild transforms and batching, this is no longer necessary.

First, I needed to create a list of test assemblies.   The solution is structured in a way that makes this relatively simple.  All of our test assemblies live in a “Tests” folder, so there’s a root to start from.  The assemblies all have the suffix “.Test.dll” too.  The following CreateItem task does the rest:

<CreateItem Include=”$(TestDir)**bin$(Configuration)*.Test.dll” AdditionalMetadata=”TestContainerPrefix=/testcontainer:”>
<Output TaskParameter=”Include” ItemName=”TestAssemblies” />
</CreateItem>

The task above creates a TestAssemblies element, which contains a semicolon-delimited list of paths to every test assembly for the application.  Since the MSTest command line needs a space between each test assembly passed to it, the TestAssemblies element can’t be used as-is.  Each assembly also requires a “/testcontainer:” prefix.  Both of these issues are addressed by the combined use of transforms, batching, and well-known metadata as shown below:

<Exec Command=””$(VS90COMNTOOLS)..IDEmstest.exe” @(TestAssemblies->’%(TestContainerPrefix)%(FullPath)’,’ ‘) /runconfig:localtestrun.testrunconfig” />

Note the use of %(TestContainerPrefix) above.  I defined that metadata element in the CreateItem task.  Because it’s part of each item in TestAssemblies, I can refer to it in the transform.  The %(FullPath) is well-known item metadata.  For each assembly in TestAssemblies, it returns the full path to the file.  As for the semi-colon delimiter that appears by default, the last parameter of the transform (the single-quoted space) replaces it.

The end result is a MSTest call that works no matter how many test assemblies are added, with no further editing of the build script.

Here’s a list of the links that I looked at that helped me find this solution:

Calling MSTest from MSBuild or The Price of Not Buying TFS

Posted on by Scott

When one of my colleagues left for a new opportunity, I inherited the continuous build setup he built for our project.  This has meant spending the past few weeks scrambling to get up to speed on CruiseControl.NET, MSTest and Subversion (among other things).  Because we don’t use TFS, creating a build server required us to install Visual Studio 2008 in order to run unit tests as part of the build, along with a number of other third-party tasks to make MSBuild work more like NAnt.  So the first time a build failed because of tests that had passed locally, I wasn’t looking forward to figuring out precisely which of these pieces triggered the problem.

After reimplementing unit tests a couple of different ways and still getting the same results (tests passing locally and failing on the build server), we eventually discovered that the problem was a bug in Visual Studio 2008 SP1.  Once we installed the hotfix, our unit tests passed on the build server without us having to change them.  This hasn’t been the last issue we’ve had with our “TFS-lite” build server.

Build timeouts have proven to be the latest hassle.  Instead of the tests passing locally and failing on the build server, they actually passed in both places.  But for whatever reason, the test task didn’t really complete and build timed out.  Increasing the build timeout didn’t address the issue either.  Yesterday, thanks to the Microsoft Build Sidekick editor, we narrowed the problem down to the MSTest task in our build file.  The task is the creation of Nati Dobkin, and it made writing the test build target easier (at least until we couldn’t get it to work consistently).  So far, I haven’t found (or written) an alternative task, but I did find a blog post that pointed the way to our current solution.

The solution:

<!– MSTest won’t work if the tests weren’t built in the Debug configuration –>
<Target Name=”Test:MSTest” Condition=” ‘$(Configuration)’ == ‘Debug'”>
<MakeDir Directories=”$(TestResultsDir)” />
<MSBuild.ExtensionPack.FileSystem.Folder TaskAction=”RemoveContent” Path=”$(TestResultsDir)” />

<Exec Command=””$(VS90COMNTOOLS)..IDEmstest.exe” /testcontainer:$(TestDir)<test assembly directory>bin$(Configuration)<test assembly>.dll /testcontainer:$(TestDir)<test assembly directory>bin$(Configuration)<test assembly>.dll /testcontainer:$(TestDir)<test assembly directory>bin$(Configuration)<test assembly>.dll /runconfig:localtestrun.testrunconfig” />

</Target>

TestDir and TestResultsDir are defined in a property group at the beginning of the MSBuild file.  VS90COMNTOOLS is an environment variable created during the install of Visual Studio 2008.  Configuration comes from the solution file.  Actual test assembly directories and names have been replaced  with <test assembly> and <test assembly directory>.  The only drawback to the solution so far is that we’ll have to update our MSBuild file if we add a new test assembly.

CruiseControl.NET, MSBuild and Multicore CPUs

Posted on by Scott

When I was trying to debug a continuous build timeout at work recently, I came across this Scott Hanselman post about parallel builds and builds with multicore CPUs using MSBuild.  While adding /m to the buildArgs tag in my ccnet.config didn’t solve my timeout problem (putting the same unit tests into a different class did), pooling multiple MSBuild processes will certainly help as our builds get bigger.