Centralized Configuration

mike_nz posted on Saturday, April 14, 2007

Hi there,

First of all, this CSLA framework looks really awesome.  I have just finished reading the book and found it to hit the nail on the head with many things!   You're a dude Rockford!! 

One area that I am still having trouble with is configuration.  I have spent a long time writing a product with Delphi COM+ business objects where configuration such as connection strings are stored in the Registry.  This worked out great...  From time to time we would write small tools etc which would interact with the COM+ business objects.  These tools needed to know nothing about configuration or connection strings or debug settings or logging etc...

It seems in the .NET world assemblies like to get their configuration from the host application (whether it be an exe.config or a web.config etc).  This seems like a pain to me because a large product could have, say a web site for the most part, but then a number of tools and utilities.  Lets say we wanted to change the debug settings or connection strings we would have to update potentially quite a few *.config files.  This would become a problem if one was missed etc.

A few ideas which come to mind are:

• Use the registry?
• Use Machine.Config?
• Store in a database table (possibly generate large traffic on DB)?
• Roll your own?
• Use EntLibs central config file idea?

Does anybody have any experiance with this, or able to offer some suggestions.

Cheers

Mike

Bayu replied on Sunday, April 15, 2007

Hey!

There is a voice in my head saying that config files could 'inherit' or 'include' each other. Never done this, but I believe I read it somewhere once though. In that case you could specify the connection strings in an independent config file which can be reused across your apps.

Personally, I prefer the DB way. It is really easy to write a small set of CSLA classes that enable you to store per-app and per-user settings in a DB. You could implement the readonly classes as singletons that use caching, so your configs are fetched only once per app and/or once per user. A great plus is also that the settings can be administered by us on-the-fly instead of having to deploy the config files ......

We have the settings time out after 20 mins which works fine 90% of the time. In those other cases users can press a Refresh Config button that is in the toolbar.

This is a much better solution than using a registry because the users configuration is independent of the machine he is working on. When people switch from desktop to laptop or from the office-pc to a pc at home: all settings are there. There is one tiny caveat: and that is when you store machine specific settings, like the size of the MainForm (think of a 21 inch flatpanel vs a 13 inch laptop) or a Recent Files list. However, who prevents you from extending your schema with per-clientmachine settings?

Regards,
Bayu

albruan replied on Sunday, April 15, 2007

Bayu:

There is a voice in my head saying that config files could 'inherit' or 'include' each other. Never done this, but I believe I read it somewhere once though. In that case you could specify the connection strings in an independent config file which can be reused across your apps.

You're absolutely right, Bayu.  I can't remember from whom, but I'd heard that once before, myself, so I thought I'd google it.  I turned up the following from beansoftware.com:

The appSettings element can contain a file attribute that points to an external file. I will change my web.config file to look like the following:

<?xml version="1.0"?>

<configuration>

    <appSettings/>

    <connectionStrings/>

    <system.web>

        <compilation debug="false" strict="false" explicit="true" />

    </system.web>

    <appSettings file="externalSettings.config"/>

</configuration>

Next, we can create the external file "externalSettings.config" and add an appSettings section with our connection information and any other settings that we want to use.

If the external file is present, ASP.Net combines the appSettings values from web.config with those in the external file. If a key/value exists in both files, then ASP.Net will use the setting from the external file.

This feature is useful when one keeps user-specific or environment-specific settings in the external file. It is better to design web.config to contain those settings that are global, while each user setting is contained in an external file. This approach makes it easier to move around global web.config changes.

One caution to this approach is that ASP.Net runtime does not detect when the external file changes. Thus to launch a new version of the application with all changes in effect, one will need to make changes to the web.config itself.

 

Bayu replied on Monday, April 16, 2007

albruan:

One caution to this approach is that ASP.Net runtime does not detect when the external file changes. Thus to launch a new version of the application with all changes in effect, one will need to make changes to the web.config itself.

Ah, this sounds like what that voice in my head was saying. ;-)

To find a trick that triggers IIS is trivial of course: simply add a setting to the web.config with the version number of your external configs. ;-)

Bayu

NinjaPenguin replied on Thursday, April 19, 2007

Hi Mike,

I have found the EntLib block to work well for config. It gives you the ability to deploy a static .exe.config or web config which contains the config info needed by the block to enable it load all other config information from an external data source. As it uses a provider pattern that external source can be a DB the registry another .config file or whatever other type of store you want to use if you role your own assembly to access a custom store, provided it has the required interface.

Whatever option you chose in the end I would say it is at least worth the time to take a look and see if it suits your situation.

Regards

Simon G