Using Web.config Transformations When Debugging Web Applications in Visual Studio
SlowCheetah is a very useful Visual Studio extension which builds upon Visual Studio's built-in support for
Web.config transformations. It adds similar XDT transformation file support to non-web projects. There is an important distinction between both implementations, though. Thanks to SlowCheetah transformations in non-web projects can be used during debugging, while built-in solution for web projects only works for web deployment. During debugging the unchanged default
Web.config file is used with all configurations.
There is already a feature request for SlowCheetah to add support for web projects as well, and you can vote for it, but until it's implemented, you'll need to find a different solution, if you want such functionality in your projects. I've recently implemented it in one of my solutions based on a great blog post by Ralph Jansen. Although I'm posting my solution with minor modifications here, I encourage you to read the original article as well for some additional background.
These are steps, I've taken to make this work in a standard web project:
- Have the solution open in Visual Studio.
- Outside Visual Studio rename the configuration (
Web.config) and transformation (
Web.*.config) files to
Web.template.*.config, respectively, using the commands of your source control tool to keep the file history.
Web.configfile in your source control tool, because it will get regenerated every build and you won't want to have it in source control any more.
- Delete the old transformation files (
Web.*.config) from solution explorer in Visual Studio.
- Show all files in Visual Studio solution explorer and include the renamed files in solution.
- To nest the transformation files below
Web.template.config, you can use File Nesting extension for Visual Studio.
- Save all files in Visual Studio and close it.
Create a new file in the project directory, named
<MyProjectName>.wpp.targetswith the following contents (my modification in comparison to the original file from the before mentioned blog post include changed transformation file naming policy and the same casing of
Web.configas used by Visual Studio):
<?xml version="1.0" encoding="utf-8"?> <Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <PropertyGroup> <PrepareForBuildDependsOn> $(PrepareForBuildDependsOn); UpdateWebConfigBeforeBuild; </PrepareForBuildDependsOn> </PropertyGroup> <!-- This target will run right before you run your app in Visual Studio --> <Target Name="UpdateWebConfigBeforeBuild"> <Message Text="Configuration: $(Configuration): Web.template.$(Configuration).config"/> <TransformXml Source="Web.template.config" Transform="Web.template.$(Configuration).config" Destination="Web.config" /> </Target> <!-- Exclude the config template files from the created package --> <Target Name="ExcludeCustomConfigTransformFiles" BeforeTargets="ExcludeFilesFromPackage"> <ItemGroup> <ExcludeFromPackageFiles Include="Web.template.config;Web.template.*.config"/> </ItemGroup> <Message Text="ExcludeFromPackageFiles: @(ExcludeFromPackageFiles)" Importance="high"/> </Target> </Project>
After opening the solution in Visual Studio and rebuilding it, the
Web.config file will be generated based on the transformation for the current configuration. Since now
Web.config will be the file that changes, it will of course be used when debugging the application just like SlowCheetah works for non-web projects.