Inside the Microsoft® Build Engine: Using MSBuild and Team Foundation Build (Developer Reference)

If you are after Team Foundation Build for TFS 2010, then take a look at the following chapter that I wrote for the book Professional Application Lifecycle Management with Visual Studio 2010.

Chapter 21: Team Foundation Build.

Otherwise the blogs that Richard points to are an excellent resource. Also the following book is very good for Team Foundation Build prior to TFS 2010

Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build

Before I say what I intend to say I would like to state that I do not think this is a good idea. Any class (ASP.NET) or not that is 5k or 10k lines long needs to be refactored. There are a lot of comments here that keep stating that your download times will be too long. Just because you have an .aspx file that has 5k lines of code embedded or 5k in a code behind file (or both) this doesn't mean that your download times will be significant just because of this. Those lines of code are compiled and executed on the server, they are not passed to the client. So there is not a direct relationship between # of lines of code to download size.

Sayed Ibrahim Hashimi

My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build

I wasted a lot of time before buying the Hashimi MSBuild book, fantastic -- I concur with this review by Steven St Jean.

In addition to an excellent all-round introduction to MSBuild scripting, it has a cookbook section on doing typical build automation thigns like build numbers etc. Obviously the last TeamBuild section will not be directly relevant for you, but a lot of the topics are generic across all CI tools.

UPDATE: The 2nd ed keeps up the trend, adding a must-have section re WebDeploy

(Edit: Sayed Ibrahim Hashimi, who literally wrote the book on msbuild, suggests the AppDomainIsolatedTask class for a better approach)

I've managed to solve this one myself...

Found this forum post from Dan Moseley, one of the MSBuild developers from Microsoft:

Hi there,

Unfortunately this is because MSBuild loads task assemblies in the primary appdomain. The CLR does not allow assemblies to unload from an appdomain as this allows important optimizations on their part.

The only workarounds I suggest is to call out tomsbuild.exe to build the projects that use the task. To do this, create MSBuild.exe <> as an external tool in VS.

Dan
developer on msbuild
DanMoseley - MSFT

So, it seems that to stop the locks, you must spawn out a new MSBuild.exe process. It can't be the one that runs inside Visual Studio, because when MSBuild runs, it loads the tasks into Visual Studio's primary app domain, and that can never be unloaded.

• create a new MSBuild project (a .csproj or similar) which overrides the 'Build' Target and performs your custom actions, eg;

  <!-- fragment of Prebuild.csproj -->   
  <Target Name="Build">   
       <BuildOrmLayerTask Repository="$(Repository)" />   
  </Target>
  

• Add it to visual studio if you want, but use Configuration Manager to make sure it is notbuilt in any configuration. Just let VS take care of source control and suchlike, not building.

• Edit the .csproj file of the project that depends on Prebuild.csproj. Add a BeforeBuild target which invokes MSBuild using the Exec task. This will start a new process, and when that process ends, the file locks are released. Example;

  <PropertyGroup>   
       <PrebuildProject>$(SolutionDir)Prebuild\Prebuild.csproj</PrebuildProject>   
  </PropertyGroup>   
  <Target Name="BeforeBuild">   
       <Exec Command="msbuild.exe &quot;$(PrebuildProject)&quot;" />   
  </Target>
  

Now, when you build the dependent project, it executes MSBuild in a new process before running the compile.