VS 2005 Web Application Projects, MSBuild, and Continuous Integrations
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 checkin 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