Building and Unit Testing .Net 4.0 with Team Build 2008, the correct order

I’ve been helping my customer setting up .Net 4.0 build servers lately as you may have read in my previous post. In the previous post, I listed my challenges getting .Net 4 assemblies to build and unit test with Team Build 2008 so I thought It would be time to share the correct order to get the stuff working!

  1. Install Visual Studio 2010 Premium
  2. Install Visual Studio Team System 2008 Development Edition
  3. Install Visual Studio Team System 2008 Service Pack 1
  4. Install Team Build 2008
  5. Install Team Build Service Pack 1
  6. Configured Team Build 2008 to use MSBuild 4.0 instead of MSBuild 3.5. To do this edit %ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\TFSBuildService.exe.config and set the MSBuildPath property to C:\Windows\Microsoft.NET\Framework\v4.0.21006\

That should do it! And if you install your build server in that order you won’t get the following error:

  • MSBUILD : warning : Visual Studio Team System for Software Testers or Visual Studio Team System for Software Developers is required to run tests as part of a Team Build
  • And you won’t replace the Microsoft.TeamFoundation.Build.targets with an incorrect workspace pattern:
    TFS Build 2008:
    $(COMPUTERNAME)_$(BuildDefinitionId)
    After VS 2010 installation:
    $(COMPUTERNAME)_$(BuildDefinitionId)_$(BuildAgentId)

Hope this summarizes how to install a build server that builds and unit tests .Net 4.0 applications with Team Build 2008.

Cheers!

Hugo

End to end TFSBuild pattern for BizTalk 2009, part 3 (Commitment)

So you thought that I would give away the secrets this time huh? I’m just kidding it will all be revealed soon in the last part of these series.

Anyway, how come I make this artistic pause? Anyone? Let’s begin with some basics:

  • Automated builds or continuous integration is useless if the team using it isn’t committed to solving problems with the builds and/or maintaining the builds.
  • Visualize the status of your builds on digital boards, flat screens or with emergency lights/sounds and make sure everyone in the project knows the status of the builds.
  • When all builds are green and all tests are green in your project you are in what I call a normal stage. In a normal stage you should make time for small improvements throughout your team i.e. refactoring, code reviews etc.
  • If any builds are red or any tests are red in your project you are in what I would call a deviate stage. In a deviate stage you should really work as a team to solve the deviations and most importantly learn from it and finally make improvements in how your team works.

Is your team committed to these basics? If not take a good look at the benefits of automated builds:

  • Always the same automated way of compiling, building and deploying your codebase.
  • No more manual releases.
  • One single location for the compiled binaries i.e. the drop folder. Make sure that all deployment flows from the drop folder i.e. establish one deployment method that uses the contents of the drop folder and use it on every environment starting with your own every morning.
  • Automated regression tests.
  • Intact source tree
  • <Enter a clever reason here>

Still not convinced? Well then you should really visit a dev shop where they’re committed to this and compare their speed, quality, agility and team spirit to your own; and I’m sure you will get inspired.

Au revoir

Hugo