If you are doing anything with .Net 2.0 chances are you have a set of MSBuild files supporting your application.  That means you already know MSBuild just rocks.  What better than MSBuild? MSBuild with a sweet task library to support it of course!  That task library would be the Enterprise Solutions Build Framework or Microsoft.SDC.Tasks as I like to call it.

Well they just released a new version!  The biggest change was the introduction of BizTalk 2006 tasks.  If BizTalk isn't your fancy then you will be pleased to also know there are some new TFS tasks also.

To find out more information visit http://www.gotdotnet.com/codegallery/codegallery.aspx?id=b4d6499f-0020-4771-a305-c156498db75e

These guys do a stellar job!  I have been using this library for about a year now and it goes everywhere I go.

I have decided there are not enough people blogging about MSBuild, so here is the first post of many more to come. 

I ran across a free MSBuild editor the other day made by Attrice called Microsoft Build Sidekick.  I've loaded it up and I am impressed.  I especially love the feature where you can look at all of the items your build file imported. 

Add it to your toolbox @ http://attrice.info/msbuild/

I don't think anyone will argue but the majority of technical books are used for reference.  OK so every so often a new book comes out and you read it cover to cover.  Well that time has come. 

Vincent Maraia has just authored a book called The Build Master.  If you have anything to do with software development then you MUST read this book.  I don't care how good you are, how many products you shipped or if you are already a build master, you MUST read this book.

Every development shop must address most if not all of the topics found in this book.  If you're not, then you really need to invest some time and money in yourself and clean shop.  I guarantee things could be better.  Just ask yourself a few questions:

• Do you have a good concurrent development mailline strategy? Do you know what one is?
• Do you know how to branch and merge?
• Do you version?
• Do you have any automation?
• Do you have a build process?
• Do you have a build team?

If you have answered No to any of these questions then just go buy it now and start reading.  Again regardless no matter who you are, you still need to read this book.

Vincent Maraia, Great Read and Great Job!!! I can't wait for the next one.

Table of Contents

1. Defining a Build
2. Source Tree Configuration
3. Daily Not Nightly Builds
4. The Build Lab
5. Build Tools
6. SNAP Builds
7. The Build Environment
8. Visioning
9. Build Security
10. Managed Code Versus Unmanaged Code Builds
11. Building for International
12. Build Verification Tests
13. Building Setup and Deploying Every Day
14. Ship It
15. Product Support Services
16. Hotfixes or Patch Management
17. Suggested Steps to Change Your Religion or Philosophy (Corporate Culture)
18. Future Build Tools from Microsoft

Long and short, if you don't know anything about MSBuild, it's time to hit the links below.  Honestly it will do nothing but save you time and automate those dreaded processes.  The links below will get you pointed in the right direction.

General Links

• MSBuild Wiki
• MSBuild Documentation
• MSBuild Reference

• MSBuild Forum

Blogs

• MSBuild Blog

Packages

• Microsoft Services (UK) Enterprise Solutions Build Framework (SBF)

Team Build

• Managing Builds with Team Foundation Build
• Administering Team Foundation Build

Internet Links

How To Links

Books

Bloggers

Short answer.

It's as simple as adding one line to your csproj which in turn tells the IDE to treat that project like a test project.  Add the following line to your main PropertyGroup:

<ProjectGuid>{04082EBA-C85C-4336-B3FD-9891096BAA0F}</ProjectGuid>

Then just reference Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll and you are on your way.  Be sure to verify that Guid between releases. 

Long Answer.

When I start a project I create the base set of known assemblies that project will need.  I also add an additional test project which will contain any Scenario, Load and Stored Procedure tests.  Then I convert all assemblies to test projects.  I am a firm believer in Test Driven Development.  IMHO it is the only way to properly write code.  Having said that over the years I have developed my own set of TDD practices; one of which is the physical placement of your unit test classes in the assembly their testing.  Why? Well I will explain that in a future post call Unit Testing with Partial Classes.

With any decision there are of course trade-offs. In this case the trade-off is around the IDE interaction with hosting type projects, ie exe or web.  After you convert an exe to a test project, when you decide to run ( F5 ) it will actually fire off Test Manager rather than the launch app.  If you are a TDD bigot like me this is actually the correct action; if your not, I know your already complaining.  BUT all is not lost!  There is a little tool us TDD bigots keep in our back pocket at all times, TestDriven.Net.  This is an Visual Studio add-in and it allows you to execute your unit tests with just a right click.  If you choose to use this tool it isn't necessary to convert your project to a test project but rather just reference the Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll.  This will allow you to fire your app as intended and run your tests with the same project configuration.

Disclaimer: this is not a Microsoft recommend practice.  You can find more information about the Visual Studio Team System Testing Framework here.

The following are some different resources to either convert your Visual Studio 2002/2003 projects to Visual Studio 2005 or just target the 1.1 framework in Visual Studio 2005.

Step-By-Step Guide to Converting Web Projects from Visual Studio .NET 2002/2003 to Visual Studio 2005

Jomo Fisher on MSBuild

• MSBuild Sample Code Demonstrating How to Target 1.1 Framework with VS Whidbey Beta 2
• Hack the Build: Targeting .NET Runtime 1.1 Step-by-Step
• Samples

Robert McLaws MSBuild Compatibility Toolkit 1.0

Nagaraju Palla's Building binaries targeting .NET 1.1 and .NET 1.0 in TeamBuild

If you are using TeamBuild then this post is for you. 

In TeamExplorer when you create a new build type it will create a *.proj file.  During the creation of this build type, you will be asked which TestLists you would like executed in that build type.  Once completed if you open that proj file, you will see an item group that looks something like the following:

<ItemGroup>
  <MetaDataFile Include="$(SolutionRoot)\TestProject1\TestProject1.vsmdi">
    <TestList>TestList1;TestList2</TestList>
  </MetaDataFile>
</ItemGroup>

For this build type there are actually 2 different TestLists, TestList1 and TestList2.  These TestLists will get executed and reported on in the build.  With the out of box ItemGroup configuration both lists will actually roll up into one set of test results; but what if you wanted to to actually have multiple test runs for a given build.