MSBuild: Web Deployments (5 of 7)
November 30th, 2006
The new ASP.NET 2.0 Website model does not include a project file. This fact has made for a troubling deployment process. You can use Visual Studio to run a build and deploy a compiled copy of the website, but that means you must have Visual Studio to run the build. Fortunately Microsoft released an Add-On for Visual Studio to generate a Website Deployment Project which you can use without starting Visual Studio.
The Website Deployment Project did not make it into the Visual Studio 2005 release but was released shortly after the .NET 2.0 launch to satisfy the clear need for such a deployment solution. The features included in this new project type were the result of requests during the .NET 2.0 beta 1 and beta 2 cycles.
One feature is the ability to merge all of the code-behind assemblies into a single assembly. When a website is deployed just using Visual Studio you will see many assemblies in the deployed bin folder with randomly named files which are associated with page templates. Once you have spent enough time with these many assemblies in a Production environment you will see how the ASP.NET runtime occasionally has difficulty finding one of these assemblies which brings down the whole website.
Rant: Recycling the worker process may cause the assembly to be found properly, but there is no guarantee the problem will not return again at the worst moment. This has happened to me enough times, and usually on Saturday night after the site was untouched for days and suddenly the worker process decides to restart and it experiences this problem. A merged assembly dramatically reduces the potential for this problem to happen.
The next major feature of the Web Deployment Projects is the ability to replace sections of the Web.config with an alternative section. You can prepare a configuration file for each of your Configurations with a unique appSettings block in each and have the Web Deployment Project automatically pull out the original block and replace it with your pre-configured block in the output folder.
Initially you may assume that you would create Debug and Release configuration files named Debug.config and Release.config and place the full configurations to be referenced by the Web Deployment Project. But that is not how it works. Instead you must separate out each block.
In the example image to the right, the appSettings block will be replaced with the contents of the Configurations\appSettings.Release.config. The parent node in appSettings.Release.config is the appSettings node and not Configuration like in the source Web.config file. You must place the connectionStrings block into a separate file in order to change those values.
As for the alternate configuration files, those must be place within the Website project. I place them in a directory called Configurations to keep them out of the root folder and to isolate them in a place I can easily exclude with a Zip task. But even if these files are deployed to a live site it is alright. Any file ending with .config is protected from external access. Try to view the Web.config file on your public ASP.NET websites and see that your request is denied.
More Information:
Next in this series, unit tests.
