MSBuild

Refactor Your Build Scripts

2 commentsWritten on December 7th, 2009 by
Categories: MSBuild

Just refactored our build scripts because i was getting annoyed at the amount of duplicate XML in each project’s build file.  It now looks like this:

<?xml version="1.0" encoding="utf-8" ?>

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

 

  <Import Project="$(MSBuildExtensionsPath)\ItemSolutions\build_g3_db_creation_sl_tests.proj" />

 

  <PropertyGroup>

    <ProjectName>MY_PROJECT_NAME</ProjectName>

    <GenesisProjectCode>MY_PROJECT_NAME</GenesisProjectCode>   

    <GenesisAnalysisId>1337</GenesisAnalysisId>

    <GenesisDocumentDescription>MY_GENESIS_DOCUMENT_DESCRIPTION</GenesisDocumentDescription>

    <LavalampDirectory>\\LAVALAMP\MY_PROJECT_FOLDER</LavalampDirectory>

    <DatabaseSchema>MY_DATABASE_SCHEMA</DatabaseSchema>

    <DatabaseServer>MY_DATABASE_SERVER</DatabaseServer>

    <DatabaseUser>MY_DATABASE_USER</DatabaseUser>

    <DatabasePassword>MY_DATABASE_PASSWORD</DatabasePassword>

    <DatabaseScriptsSubversionLocation>MY_DATABASESCRIPT_SUBVERSION_LOCATION</DatabaseScriptsSubversionLocation>

    <NormalTestConfigPath>MY_PROJECT\bin\$(Configuration)\hibernate.cfg.xml</NormalTestConfigPath>

    <TestConfigPathForBuildServer>MY_PROJECT\hibernate.cfg.xml.onbuildserver</TestConfigPathForBuildServer>

    <SilverlightTestAssemblyName>MY_PROJECT.Silverlight.Tests.dll</SilverlightTestAssemblyName>

    <SilverlightTestsXapLocation>MY_PROJECT.Silverlight.Tests\Bin\$(Configuration)\MY_PROJECT.Silverlight.Tests.xap</SilverlightTestsXapLocation>

    <SilverlightTestsDllLocation>MY_PROJECT.Silverlight.Tests\Bin\$(Configuration)\MY_PROJECT.Silverlight.Tests.dll</SilverlightTestsDllLocation>

  </PropertyGroup>

 

</Project>

 

This build script compiles all of the code, creates a new database from scratch, runs the unit tests (including the silverlight tests), publishes the testresults into Genesis, and updates our lavalamp.  In case a particular build needs to divert from the standard operation procedure, you can override whatever target you want in the build process to customize it (or disable it).

Now ask yourself: is there any reason why you should tolerate duplication in your build scripts?

Using TeamCity’s NUnit support, while keeping the output around

16 commentsWritten on July 19th, 2008 by
Categories: Continuous Integration, MSBuild
Tags:

I've been playing around with TeamCity a lot lately. It's really amazing how easy to use and powerful it is. Definitely my favorite CI server for the time being... i'm even running it at home now for my personal projects.

There was one issue at work that was somewhat hard to fix though. TeamCity has fantastic integrated support for NUnit, but unfortunately it doesn't write NUnit's output to XML files like nunit-console.exe does. After a bit of browsing, i found a post on the TeamCity forums that discussed a workaround on how to get the output. Unfortunately the workaround is a bit cumbersome as it requires you to you create an XML file which contains the arguments that TeamCity would pass to its NUnitLauncher task.

I believe in 'script reuse' as much as i believe in 'code reuse', so every project's build script merely imports a generic build script and then it just overwrites some variables that the generic script uses and then it kicks off the usual build process. Since all of our projects will now be built by TeamCity Build Agents, and we definitely need to have NUnit's results xml file i wanted to automate this whole thing as much as possible.

So instead of having to create (and thus, maintain) a cumbersome xml file for each project, i wrote an MSBuild task that would generate the xml file containing the arguments on the fly during the build, and would then pass those xml arguments to TeamCity's NUnitLauncher. This way we get to keep all of TeamCity's NUnit integration goodness, while still keeping the NUnit result files around as well.

So now in my MSBuild file, i can just do this:

    <CreateItem Include="**\Bin\Debug\*Tests*.dll" >

      <Output TaskParameter="Include" ItemName="TestAssemblies" />

    </CreateItem>

 

    <BuildTeamCityNUnitArguments HaltOnError="true" HaltOnFirstTestFailure="true"

                                HaltOnFailureAtEnd="true" TestAssemblies="@(TestAssemblies)"

                                NUnitResultsOutputFolder="TestResults"

                                PathOfNUnitArgumentsXmlFile="nunitarguments.xml" />

 

 

    <Exec Command="$(teamcity_dotnet_nunitlauncher) @@ nunitarguments.xml" />

As you can see, there is nothing project-specific in there so this just integrates nicely into each build that we need. The only limitation to this approach is that TeamCity's NUnitLauncher will write one NUnit result file for each assembly containing tests. Apparently there is no way in the current version of TeamCity to get it to combine those results. We use an extra tool to analyze the NUnit output after the tests have run, and unfortunately it requires all of the results to be in one file. I looked around for a way to merge the output of several NUnit result files, but i didn't find something that was already available. So i wrote another MSBuild task that would merge the output into one xml file:

    <CreateItem Include="TestResults\*.xml" >

      <Output TaskParameter="Include" ItemName="NUnitOutputXmlFiles"/>

    </CreateItem>

 

    <NUnitMergeOutput NUnitOutputXmlFiles="@(NUnitOutputXmlFiles)"

                      PathOfMergedXmlFile="TestResults.xml" />

Now we finally have all of TeamCity's goodness while we still get to run our post-test analysis on the NUnit result file that contains the testresults of all the test assemblies :)

You can find the code of the MSBuild tasks here. They are BSD-licensed so feel free to use them if you need them.

Basic MSBuild script

7 commentsWritten on July 4th, 2008 by
Categories: MSBuild

I spent some time with MSBuild this week... I actually like it (yea that's right, i said it!), but it did take me some time to figure out how to write a basic build script from scratch that can be used to build a solution and run the tests. Obviously, i wanted the script to assume as little as possible, so i could pretty much drop it any solution folder and use it as is. The only thing that is hardcoded is the path the nunit console runner but other than that, this should provide a good start for pretty much any project.

<?xml version="1.0" encoding="utf-8" ?>

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

 

  <Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />

 

  <PropertyGroup>

    <Configuration>Debug</Configuration>

    <NUnitRunner>C:\Program Files\NUnit 2.4.7\bin\nunit-console.exe</NUnitRunner>

  </PropertyGroup>

 

  <ItemGroup>

    <ProjectsToBuild Include="**\*.csproj" />

  </ItemGroup>

 

  <Target Name="BuildAll" DependsOnTargets="Clean;CoreBuild;RunTests"/>

 

  <Target Name="CoreBuild">

    <MSBuild Projects="@(ProjectsToBuild)" ContinueOnError="false" Properties="Configuration=$(Configuration)">

      <Output ItemName="BuildOutput" TaskParameter="TargetOutputs"/>

    </MSBuild>

  </Target>

 

  <Target Name="Clean">

    <MSBuild Projects="@(ProjectsToBuild)" ContinueOnError="false" Targets="Clean"

            Properties="Configuration=$(Configuration)" />

  </Target>

 

  <Target Name="RunTests" DependsOnTargets="CoreBuild">

    <CreateItem Include="**\Bin\Debug\*Tests*.dll" >

      <Output TaskParameter="Include" ItemName="TestAssemblies" />

    </CreateItem>

 

    <NUnit ToolPath="$(NUnitPath)" Assemblies="@(TestAssemblies)" DisableShadowCopy="true" />

  </Target>

 

</Project>

it uses the MSBuild Community tasks btw... Like i said, this is a very basic script. It only builds your solution and it runs all of your tests. That's it. No packaging of the output, no code coverage (if you're really doing TDD, code coverage is useless anyway), no whatever else you can think of. But you can easily add all of that stuff of course :)

Now watch me get flamed for not using nant :P

Meta

Recent Posts

Categories