XmlPreprocess is a hack...maybe but "Get and Go" sure is nice
Just wanted to respond to some comments Charles left in response to this post about XmlPreprocess on Jon Galloway's blog... Charles wrote:
Looks like a hack...definitely not the way most natural way of dealing with XML. Using _code_ (okay, "conditional logic") in _comments_ ?!?!
To me, the most natural way of dealing with this situation is to have one config file with all of the data and then have a stylesheet to use to transform the data.
For example, .Net could support Web.config and then Web.Transform.config. The transform would be automatically applied to the Web.config file and the result of the transform would be the file that's actually used by the .Net runtime.
Obviously, the transform would not be necessary for the newbies who just can't handle/don't want to deal with transformations. But for those that need the advanced functionality, learning something as trivial as XSL and XPath would certainly be worth the trouble (and I'm sure most people who need the advanced functionality are probably already well versed in said technologies).
I agree, it certainly could be considered a hack. But I wanted to expand on the reasons I chose to use comments (here's an example:)
<configuration>
<appSettings>
<!-- ifdef ${_xml_preprocess} -->
<!-- <add key="server" value="${remoteserver}"/> -->
<!-- else -->
<add key="server" value="developmentserver1"/>
<!-- endif -->
</appSettings>
</configuration>
Embedding the conditional logic in comments met my goal of keeping the config file 100% operational as-is right out of source control. (Get and Go), and a second goal of having only one definitive source of truth for the structure of the config file (No Dual Maintenance).
I have done configuration using XSL as Charles described, and it worked fine too. But it turns out that we needed one XSL for each config file, at least the way I did it...and in our large applications we have literally dozens of config files scattered all over. So we had double the files to maintain. Plus we have many versions of our application, each targeting it's own set of environments (Dev, Test, Integration, and Production), and the matrix of settings got unmanageable in a hurry.
The stylesheets also turned out to be fragile because they became fairly dependent on the structure of the config file...when the developers adds sections and settings to the config file, you have to go "somewhere else" to update the XSL, it is this out-of-band work that would often get forgotten. There were the developer config files that they kept working, and the XSL's that they didn't really worry about because it didn't affect the way they ran on their machine.
I found the comment ifdef/else/endif syntax very approachable for our developers who didn't know XSL, but were familiar with how simple #ifdef's work.
Consolidating all changeable properties in external settings files also enabled tool support. The XmlPreprocess download includes a sample Excel spreadsheet tool that lets operation personnel edit the properties that change for all environments and in all config files in one single place without having to open a single config file or XSL file. It lists properties down the left, environments across the top. Press a key, and it generates environment specific settings files that get fed into the preprocessor on deployment. Scott Colestock has a screen shot of this tool in this post.
Anyway, I felt my first post, and the project documentation don't explain this very well, hopefully it makes a little more sense now why I chose such a "hack"y looking syntax.