views:

211

answers:

2

For most of my applications I use iBatis.Net for database access/modeling and log4Net for logging. In doing this, I need a number of *.config files for each project. For example, for a simple application I need to have the following *.config files:

  • app.config ([AssemblyName].[Extention].config)
  • [AssemblyName].SqlMap.config
  • [AssemblyName].log4Net.config
  • [AssemblyName].SqlMapProperties.config
  • providers.config

When these applications go from DEV to TEST to PRODUCTION environments, the settings contained in these files change depending on the environment.

When the number of files get compounded by having 5-10 (or more) supporting executables per project, the work load on the infrastructure team (the ones doing the roll-outs to the different environments) gets rather high. We also have a high risk of one of the config files being missed, or a mistype in the config file.

What is the best way to avoid these risks? Should I combine all of the config files into one file? (is that possible with iBatis?) I know that with VisualStudio 2010 they introduce transforms for these config files that allow the developer to setup all the settings for the different environments and then dynamically (depending on the build kicked off) the config files get updated to the correct versions. (VS 2010 - transforms)

Thank you for any help that you can provide.

+1  A: 

You could alter the main *.config file (e.g. web.config or app.config) by adding configuration sections

I am using log4net, Active Record and Ciphersafe in one of my web application and in my web.config I have

<configuration>
...
<configSections>
        <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net"/>
            <section name="activerecord" type="Castle.ActiveRecord.Framework.Config.ActiveRecordSectionHandler, Castle.ActiveRecord" />
            <section name="cipherSafeConfigSection" type="Obviex.CipherSafe.AppConfigSectionHandler,CipherSafe" />
    </configSections>
...
</configuration>

Then I have configuration section for each, e.g. for log4net I have

<configuration>
...
<log4net>
        <appender name="RollingLogFileAppender" type="log4net.Appender.RollingFileAppender">
            <file value="Logs\\TimeRegWeb.log"/>
            <appendToFile value="true"/>
            <datePattern value="yyyyMMdd"/>
            <rollingStyle value="Date"/>
            <filter type="log4net.Filter.LevelRangeFilter">
                <acceptOnMatch value="true"/>
                <levelMin value="DEBUG"/>
                <levelMax value="FATAL"/>
            </filter>
            <layout type="log4net.Layout.PatternLayout">
                <conversionPattern value="%-5p %d %5rms %-22.22c{1} %-18.18M - %m%n"/>
            </layout>
        </appender>
        <root>
            <level value="DEBUG"/>
            <appender-ref ref="RollingLogFileAppender"/>
        </root>
    </log4net>
...
</configuration>

That way I have only 1 web.config file. Then I created a seperate Project in my solution name ProjectFiles which contains all my external assemblies and config files. Then when I make a request of updating my solution to the operations side I copy the relevant config file (test or prod) with the web application files

armannvg
+1  A: 

Another way is to have the config files created at build or deploy time using something like an AWK script or XSLT in combination with a single file containing the specific settings for each environment.

ANT has plugins that allow for this, other build tools probably do too or allow them to be plugged in using a well published API.

For example you might have a template file reading something like

database.uri=@@dbUri
database.user=@@dbUser
database.credentials=@@dbCredentials

and for each environment a file those tags are taken from like

dbUri=jdbc:oracle:10.1.1.10:1224:ORCL
dbUser=Scott
dbCredentials=Tiger

The environment to be deployed would have to be supplied to the build script in some way of course, but you need to do that anyway.

jwenting
+1 for pushing the work off to the build server
Ralph Willgoss