Connection String Storage

[cfps.Christian]

My shop currently has all of its ASP.NET pages using a singular
web.config file which to my knowledge doesn't work when you start
doing additional tasks like AJAX or Futures.

I either need to know if there is a way to use a singular web.config
and have it account for AJAX and Futures even if all the pages don't
use it or find a way to store the connection strings in a centralized
location (rather than in every site's web.config)

I only had two ideas on the second portion and that was to create a
dll with a direct config reference and have that do the work, or to
create some kind of text file and reference it in the web.config.

 

[Scott Roberts]

My shop currently has all of its ASP.NET pages using a singular
web.config file which to my knowledge doesn't work when you start
doing additional tasks like AJAX or Futures.

Don't know about "Futures", but you can certainly use one web.config for a
site that contains both "plain" pages and AJAX-enabled pages. The AJAX
settings in web.config are *additional* settings, they don't break anything
on "plain" pages.

I either need to know if there is a way to use a singular web.config
and have it account for AJAX and Futures even if all the pages don't
use it or find a way to store the connection strings in a centralized
location (rather than in every site's web.config)

Well, there's always machine.config. That's what we use.

 

[cfps.Christian]

I know we're just looking for maximum portability. We just want the
ability to change the connection string in one place and have it
change everywhere. They normally do includes but ASP.NET doesn't
support the old style.

Honestly I'd love to have them in a database but that defeats the
purpose.

 

[Scott Roberts]

I know we're just looking for maximum portability. We just want the
ability to change the connection string in one place and have it
change everywhere. They normally do includes but ASP.NET doesn't
support the old style.

Well, machine.config is that place. It's also nice because you can move your
web site from the Dev server to the QA server to the Production server
without modifying web.config at all (the QA web server contains connection
strings to the QA database, the Prod web server contains connection strings
to the Prod database).

Honestly I'd love to have them in a database but that defeats the
purpose.

Interesting that you say that. We store one connection string to the
"Membership" database, then read the appropriate connection string from the
Membership database depending on the user login. So we actually do store
(some) connection strings in the database!