XmlPreprocess and conditional web.config wishes

Loren Halvorson wrote about XmlPreprocess. It allows you to add some basic logic and token replacement to XML config files, like ASP.NET web.config files, like this:

<configuration>
<system.web>
<!-- ifdef ${production} -->
<!-- <compilation defaultLanguage="c#" debug="false"/> -->
<!-- else -->
<compilation defaultLanguage="c#" debug="true"/>
<!-- endif -->
</system.web>
</configuration>
It's command line driven, so it can be called from an MSI or other deployment script.

Pretty cool. I sure wish there was some sort of native support for this:

<environmentVariables>
<variable name="connectionString">
<condition type="hostname" match="PRODWEB1,PRODWEB2,PRODWEB3" value="prodsql.domain.com,1433" />
<condition type="hostname" match="QAWEB1,QAWEB2" value="qasql.domain.com,1433" />
<condition type="default" value="(local)" />
</variable>
<variable name="debug">
<condition type="ip" match="127.0.0.1" value="true" />
<condition type="default" value="false" />
</variable>
</environmentVariables>
<configuration>
<appSettings>
<add key="sqlConnection" variable="connectionString" />
</appSettings>
<system.web>
<compilation defaultLanguage="c#" debug="$$default"/>
</system.web>
</configuration>

We use prod.config, qa.config, and dev.config at my work. The web.config points to the correct localized settings:

<appSettings file="relative file name" />

It works, but it's a pain because (1) some settings need to vary between environments that don't go in the appSettings node, and (2) it's a pain to manage all these files.

5 Comments

  • Looks like a hack...definitely not the way most natural way of dealing with XML. Using _code_ (okay, &quot;conditional logic&quot;) 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).

  • Looks like a hack...definitely not the way most natural way of dealing with XML. Using _code_ (okay, &quot;conditional logic&quot;) 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).

  • Blah! Sorry for double post!

  • Having read this I thought it was rather informative. I appreciate you taking
    the time and effort to put this article together. I once again find myself
    personally spending a significant amount of time both
    reading and posting comments. But so what, it was
    still worthwhile!

  • Hi to every one, it's truly a pleasant for me to go to see this site, it consists of useful Information.

Comments have been disabled for this content.