Republished with Permission - Original Article
One thing that I thought would be worth spending a few
minutes writing about is the built-in MSBuild support provided with the VS
2005 Web Application Project Model option.
The project file used with VS 2005 Web Application Projects
is a standard XML-based MSBuild file (just like a class library or any other
project type within VS 2005), and allows you to add any custom MSBuild action
with it. Here is a pointer
to an old blog post I wrote that listed a number of free MSBuild actions
you can download and incorporate (including ones to create IIS application
pools, FTP content, and provision databases). When you do a build within the
Visual Studio IDE, it will use the MSBuild Project file and launch the
appropriate actions as part of the build.
The .NET Framework Redist actually includes and installs the
core MSBuild utility system, as well as the VB and C# command-line compilers.
This means that you can copy a MSBuild based solution or project file to any
machine that has the .NET Framework installed and build it from the command-line
(you can just type: "msbuild mysolution.sln" to build every project
within the solution from the command-line). This does
not require that Visual Studio is installed on the machine. Two common
scenarios where this is very useful are for centralized build servers, and for
continuous integration scenarios.
If you aren't familiar with the concept of continuous
integrations, I'd definitely recommend spending time reading up on it
(especially if you are in a team development environment where I think it is
critical). In a continuous integration environment you setup a machine that
monitors your source code repository and automatically syncs and builds the
full code-base, and runs all unit tests against the produced build, whenever a
checkin is made. It then sends an email report to the developer (or entire
team) on the results. The benefit with this is that it helps ensure the source
tree is kept in an always clean/buildable state, and avoids issues where
developers forget to checkin some files, or have other changes on their
machines that impact the stability or success of the build. We use this model
heavily within Microsoft. No checking is allowed to reach the ASP.NET feature
team branch until it has been synched, built and tested on a centralized
machine (which we affectionately call our "buddy machine") first.
The new Team Foundation Server that ships as part of the
Visual Studio Team System family can
be configured to enable continuous integration support. Alternatively,
you can also use the very popular CruiseControl.NET to achieve
this, which is a free open-source product that is hosted here. You can use both in
conjunction with MSBuild files to launch and automate the build process from
the command-line without needing Visual Studio installed on the machine.
One thing to be aware of with VS 2005 Web Application
Projects is that the MSBuild project files created have an import reference to
a VS 2005 Web Application Project .targets file.
You'll want to make sure you copy this .targets file to any build servers that
don' t have VS 2005 and the Web Application Project option installed to ensure
that command-line builds of these project types work fine.
Scott Allen talks about the specifics of copying this VS 2005
Web Application Project .targets file (including the disk location where it is
stored) in more detail on his excellent blog here.
Hope this helps,
Scott
