«

I thought of using Settings.settings feature that is new to .NET for
storing connection strings info for TEST, INT and PROD regions.
Currently we prefix the appSettings keys with TEST, INT and PROD in
web.config (or app.config). For instance in my web.config I have
following keys:

<appSettings>
<add key="TEST.Connection" value = "......" />
<add key="INT.Connection" value = "......" />
<add key="PROD.Connection" value = "......" />
</appSettings>

When we deploy application to each region we set the value of server
variable ENVIRONMENT to "TEST", "INT" and "PROD".

We then use following to get conn string :

string connstring = [AppSettingsReader obj].GetValue( ENVIRONMENT +
".Connection")

This gives us TEST connection string in TEST region, INT conn string
in INT region etc.

I would like to do something similar with Settings.settings file. Any
ideas.

donet programmer <> wrote in news:e1d08968-9837-44b1-
a00d-:

> I thought of using Settings.settings feature that is new to .NET for
> storing connection strings info for TEST, INT and PROD regions.
> Currently we prefix the appSettings keys with TEST, INT and PROD in
> web.config (or app.config). For instance in my web.config I have
> following keys:
>
> <appSettings>
> <add key="TEST.Connection" value = "......" />
> <add key="INT.Connection" value = "......" />
> <add key="PROD.Connection" value = "......" />
> </appSettings>
>
> When we deploy application to each region we set the value of server
> variable ENVIRONMENT to "TEST", "INT" and "PROD".
>
> We then use following to get conn string :
>
> string connstring = [AppSettingsReader obj].GetValue( ENVIRONMENT +
> ".Connection")
>
> This gives us TEST connection string in TEST region, INT conn string
> in INT region etc.

You don't want to do this going forward, or at least it is not likely
you want to continue this direction. In .NET 4.0 (release 1Q 2010),
there are provisions for altering a config file on deploy, so there is
no reason to consider this form of change for common config settings.

As .NET 4.0 is Go Live now, you might consider looking at the impact up
"upgrading" on your project and switching. No, I would not normally
suggest going into a beta cycle, but your needs match what they are
doing now. And the release is not that far away. And the Go Live means
Microsoft has guaranteed an upgrade path for beta 2.

Peace and Grace,
Greg



--
Vote for Miranda's Christmas Story
http://tinyurl.com/mirandabelieve

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************

Thanks greg for the info. We currently use .NET 3.0 which we only
recently switched to so no idea how long till we use .NET 4.0.

I was able to resolve the issue and able to store multiple sets of
values in my app.config file and still use intellisense to get its
value. For those interested I am attaching the link below :

http://blogs.msdn.com/johan_stenberg...11/491998.aspx

Thanks

donet programmer <> wrote in news:e65c8ba0-77bb-463f-
99e3-:

> Thanks greg for the info. We currently use .NET 3.0 which we only
> recently switched to so no idea how long till we use .NET 4.0.
>
> I was able to resolve the issue and able to store multiple sets of
> values in my app.config file and still use intellisense to get its
> value. For those interested I am attaching the link below :
>
> http://blogs.msdn.com/johan_stenberg...11/491998.aspx

That is good info. If you get a chance, look at what .NET 4.0 is doing,
however, and abstract in a similar manner. It will make it easy to switch.

Peace and Grace,
Greg

--
Vote for Miranda's Christmas Story
http://tinyurl.com/mirandabelieve

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************