We have recently been working on a build and deployment refactoring of a SaaS product that contained a large number of config files. Changing settings was a nightmare and wrapping your head around which config files were relevant was difficult and error prone. What contributed to the config bloat was the approach the previous developers used to manage configuration based on the build/deployment target environment. Each config was duplicated and modified to suit the target then Post Build Events would be used to copy the files to the active location, naturally this resulted in a lot of redundant config files and a great deal of confusion. In fact, there were over 200 connection strings in the solution that when rationalized resulted in 12 unique connections. Obviously we had to clean this up.
Config Transforms to the Rescue
To address “config hell” I wanted to use Config Transforms, a really useful technology MS first introduced in VS2010 that applies a delta to a base config file. However, there are two limitations to Config Transforms that bothered me:
- Config Transforms only apply to the Web.config – This was a big issue for us as we have windows services and console jobs that have App.config files.
- Config Transforms apply the delta based on Build Configuration (e.g. Debug, Release). Although we could work with that what we really want is a delta applied based on deployment target.
The Chili Peppers Save Our A$$
Turns out there is a guy at MS, named Sayed Hashimi (among others), who recognizes the first limitation and has written a Visual Studio extension called SlowCheetah (apparently he’s a Chili Peppers fan). SlowCheetah extends VS to support transforming any config file, not just the Web.config. Sweet! You can find more details here:
Okay, so what about limitation 2?
It turns out MS recognized the second limitation as well and implemented a new feature in Visual Studio 2012 that supports transforming a Web.Config based on Publish Profiles. This means we can apply a delta to the config files based on our deployment target. Scott Hanselman blogs about it here:
We had a plan to upgrade to VS2012 on the road map so we just pushed that forward a little. So now we have SlowCheetah (which supports VS2012) and our solution converted to VS2012 so all is right with the world, right? Almost…
SlowCheetah, Visual Studio 2012 and Config Transforms
We started experimenting with using this combination and ran into a few hiccups, one of which is documented here:
After a little tweaking and some polite suggestions from Sayed, the author of SlowCheetah we had Config Transforms operating on a VS2012 test project where we could transform any config file based on Build Config but unfortunately only the Web.Config was transforming based on Publish Profiles. I had wondered whether this was supported by SlowCheetah but couldn’t find a definitive answer on any of the blogs. Thankfully, Sayed appears to be a workaholic and responded to an email saying that SlowCheetah didn’t support Publish Profiles but that he’d implement the functionality over the weekend if we’d help out by testing it. The issue is documented here:
After a little back and forth we installed the updated VS extension and found the transforms were now executed based on Publish Profile for any config file including chaining Build Configuration based transforms as well.
So there you have it, vastly simplified config settings that are transformed based on deployment target thanks to Sayed being so willing to help out and extend SlowCheetah very quickly. I’ll write another post on how we centralized the config transforms in the near future.
Oh, a link to the Chili Pepper’s song if anyone is interested: