ASP.Net Web Config Transform Console Utility released on nuget


ASP.Net Web.config transformations are a great way to manage configuration differences between environments. You can easily change a database connection string or change the compilation model for  Here is a link to the syntax documentation on msdn. The problem with web.config transformations, is that it has been historically really hard to run the transforms. The tooling to do this was buried into Visual Studio.  The ASP.Net team just released a library to run the transformations as a nuget library. 



Using that library I created a very simple command line tool to transform config files WebConfigTransformRunner is the package containing this utility.


install-package WebConfigTransformRunner



WebConfigTransformationRunner.exe WebConfigFilename TransformFilename OutputFilename


I see this package being used in two ways.

First, using this in an automated build as part of a packaging process to pre transform configuration files for different environments.  This was the main reason I created this library. I am using it in a build in TeamCity to transform my web.config file for an mvc application as part of an automated CI build and deploy.

The second scenerio that seems very useful would be to access this package from the install script (install.ps1) from a nuget package. The current configuration transformations that nuget supports is very limited, It works best when you have static configuration nodes that will never change.  If you have a node that has an attribute that a user / developer may change then using a configuration transformation would be a more reliable.  Since this tool is delivered as a nuget package the command is available in the path of the nuget console, so a package that needs to run a transformation would just need to take a dependency on this package then it could run the exe command from the install script, on the files it wants to transform. I could see running the main web.config with a transformation that is located in the packages content folder, for example. 


Want to help?

The project is open source and available on github. Please submit issues, ideas or pull requests!

About Eric Hexter

I am the CTO for QuarterSpot. I (co)Founded MvcContrib, Should, Solution Factory, and Pstrami open source projects. I have co-authored MVC 2 in Action, MVC3 in Action, and MVC 4 in Action. I co-founded online events like mvcConf, aspConf, and Community for MVC. I am also a Microsoft MVP in ASP.Net.
This entry was posted in .Net, Asp.Net, Asp.Net MVC, CodeProject, Deployment, MSDeploy, nuget, Open Source Software, OSS, Tools. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • bill keenan

    Hm.. I’ve found it way easier just to keep the seperate configs, and copy the appropriate one in as part of the build script..

  • Sam Critchley

    I prefer to have all my different deployment settings stored in the build server config. Its a much more appropriate place for them imho. Also means your not sharing production server settings in your source code. I’ve used the msbuild task XmlPoke to set config values in .config files from parameter values passed to msbuild.exe.


    In my msbuild : 

    is working for me

  • DavidP

    Or you could’ve just used the one that is already out there:

    • ctt is actually superior to this because it supports tokenized parameter substitution.  :)

  • Noel McCrory

    Slow Cheetah does something similar -

  • santosh kumar patro

    Can you please help me to get sample usage. The one mentioned in the above article is not clear to me:


    WebConfigTransformationRunner.exe WebConfigFilename TransformFilename OutputFilename

    Need to know how here web.config and web.staging.config can be used in the above command.

  • test

    Is this something I could use to have a centralized parameter.xml file as well? So we only have one central point for common keys? connection strings? If we change one, it changes all. I currently see that the parameters.xml file needs to be in the root directory of each project…trying to bypass this.

    • erichexter

      I suppose you could, for a simple case. I am using octopus deploy to manage our keys which get swaped in by environment at deployment time.