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?

« Testing CRUD Operations With NHibernateWhich One Do You Prefer? »

This entry was posted on Monday, December 7th, 2009 at 15:01 and is filed under MSBuild. You can subscribe to any comments to this entry via RSS 2.0. You can leave a response, or trackback from your own site.

  • http://ramonsmits.com Ramon Smits

    What problem are you solving? You just removed the duplicate steps as in formalizing how each project should be build, tested, labeled and packaged?

  • http://davybrion.com Davy Brion

    if a build process is the same for multiple projects, then why wouldn’t i solve the problem of having large, elaborate build scripts which all have to be modified when we modify the build process?

Meta

Recent Posts

Categories