app.config

  • Thread starter Thread starter Tim Gallivan
  • Start date Start date
T

Tim Gallivan

Hi all,

I think read somewhere (but I can't find it ... note to self: must get new
filing system ...) that there is a workaround so that an app.config can have
multiple keys with the same name or something of the like. What I require is
the ability to point at a development or live database without changing any
existing code in my multiple DLL / single form project.
<add key="dtacollect.ConnectionString"
value="server=xxxxxx;trusted_connection=yes;database=DevDataCollection" />

<add key="dtacollect.ConnectionString"
value="server=xxxxxx;trusted_connection=yes;database=ProdDataCollection" />

Has anyone heard of this?
Thanks in advance,

Tim Gallivan


If a man is in the forest and there are no women around, is he still wrong?
 
Perhaps I've answered this myself: found this in
http://www.bistrotech.net/weblog/CategoryView.aspx?category=Tech

Redirecting ConfigurationSettings.AppSettings.Get()
I'm surprised this feature isn't more well-known. I've been taking
advantage of it for quite some time now. I believe I first came across it
in Team Development with Visual Studio .NET and Visual SourceSafe, which
describes its canonical implementation with database connection strings.

It's simple; if you store your connection string in a config file like I do,
your "app.config" file looks something like this...

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings>
<add key="ConnectionString" value="the connection string for my
production environment"/>
</appSettings>
</configuration>


Suppose, though, that you want to go against a different database during the
development cycle. One obvious option is to change the app.config file,
setting the value to the development connection string. An even easier
option, though, is to use the "file" attribute of the appSettings element to
redirect to a different, cleverly-named config file.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings file="development.config">
<add key="ConnectionString" value="the connection string for my
production environment"/>
</appSettings>
</configuration>

Now just create a "development.config" file in the bin directory of your app
and type in an appSettings section like this...

<appSettings>
<add key="ConnectionString" value="the connection string for my
development environment"/>
</appSettings>


Now when your application references "ConnectionString", the app.config file
redirects the request to, in this example, "development.config". If no
"development.config" file exists, the redirect silently fails and uses the
string in app.config. It's a thing of beauty. Just don't check the
secondary config file into source control, and never again will you have to
worry about changing app.config settings at the last minute before creating
a deployment package.
 
Tim,
What I normally do is within a single app.config have custom sections that
identify distinct 'environments' (home or work).

There is a predefined configSections section in the app.config that you use
to define new sections.

Something like:

<configuration>

<configSections>
<section name="myClass1Stuff"
type="System.Configuration.DictionarySectionHandler, System" />
<sectionGroup name="environments">
<section name="work"
type="System.Configuration.SingleTagSectionHandler, System" />
<section name="home"
type="System.Configuration.SingleTagSectionHandler, System" />
</sectionGroup>
</configSections>

<appSettings>
<add key="key1" value="value1" />
<add key="environment" value="work" />
</appSettings>

<myClass1Stuff>
<add key="key1" value="value1" />
</myClass1Stuff>

<environments>
<work value1="xyz" value2="abc" value3="edf" value4="ghi" />
<home value1="xyz" value2="abc" value3="edf" value4="ghi" />
</environments>

</configuration>

If you inherit from DictionarySectionHandler you can easily change the key
or value in your section. I've derived from DictionarySectionHandler to
change key/value to plugin/type in a few of my projects.

I use the above environments section to define each of my environments,
Production, QA, Test, Development. Where each environment points to the
correct database servers, web servers, message queues, printers any 'per
environment' settings. The appSettings/environment setting is used to
identify the current environment in use. Instead of value1, value2, value3,
value4. I would have connectionString, printer, messageQueue and such that
are distinct per environment.

You then need to use System.Configuration.ConfigurationSettings.GetConfig to
get your section, which returns an object based on the type of section
handler defined for that section (usually HashTable, but can be other object
types.

See the following on how to create new sections via the configSections
section.

http://msdn.microsoft.com/library/d...de/html/cpconconfigurationsectionhandlers.asp

and:
http://msdn.microsoft.com/library/d...ref/html/gngrfconfigurationsectionsschema.asp

Also read about the System.Configuration.ConfigurationSettings class and
other classes in the System.Configuration namespace.

If you define a distinct enough custom section you could put it in the
machine config, however I would put it under something other than
appSettings, as all applications can read appSettings (technically All .NET
applications can read all sections of machine config). If I were to put a
custom section in machine.config I would more than likely use the namespace
for my assembly as the custom section name. For the above I would define a
custom section to hold which environment I was using, then

Hope this helps
Jay
 
Thanks, Jay, I'll look into it as my self-reply doesn't work (perhaps its
for VS 2003 and I'm using 2002).

Tim
 
Back
Top