473,326 Members | 2,124 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

Web.config and Connection String Management

I'm trying to fix a "sub optimal" situation with respect to connection
string management. Your thoughtful responses will be appreciated.

I just started with a new client who has a bunch of legacy ASP.NET
applications that all manage connection strings in Web.config the same way,
like this:

This client has one Web.config file per application, and that one Web.config
file is duplicated across all environments (i.e., dev machines, test, and
production all have the exact same Web.config file, connection strings and
all).

For connection strings they specify one connection string per computer the
application may run on, including all development machines, all test
servers, and production server. The name of each connection string includes
the name of each computer on which the application may run, plus the name of
the connection string. They have a computer naming convention where each dev
box name is an abbreviation of the developer's name. More formally, it's
like this:

[computer name] + [connection string name]

Here are examples:
<!-- Local DEV Workstations -->
<add name="BSmithConnectionStringToInventoryDB"
connectionString="server=DevServer1; InitialCatalog="Inventory" ..." />
<add name="RJohnsonConnectionStringToInventoryDB"
connectionString="server=DevServer1; InitialCatalog="Inventory" ..." />
<add name="GBrooksConnectionStringToInventoryDB"
connectionString="server=DevServer1; InitialCatalog="Inventory" ..." />
<!-- Test Server -->
<add name="InventoryTestServer1ConnectionStringToInvent oryDB"
connectionString="server=DevServer1; InitialCatalog="Inventory" ..." />
<!-- Production Server -->
<add name="InventoryAppServer1ConnectionStringToInvento ryDB"
connectionString="server=DevServer1; InitialCatalog="Inventory" ..." />

You can see that the connection strings are identical except for the
computer name (which equates to developer name or "environment"). So yes,
for each new developer, the connection string must be duplicated and tweaked
(changing only the name).

The application, upon startup, looks to Environment.MachineName to determine
which connection string it is to use. So, if the application is running on a
machine for which there is an associated entry in Web.config, then it will
use that connection string.

WHY would they do this? From talking with the existing staff, it appears
that they don't want to deal with versioning Web.config. When moving the
application to different environments or their source control system, they
want to be able to copy the entire application, Web.config and all.

But their strategy (1) creates brittle connection strings, as one must
modify Web.config when moving to a new computer (or hiring another
developer; or a developer leaves...); (2) they in fact have a versioning
problem in that whenever a new connection string is needed, all developer's
copy of Web.config must be updated, etc.

What I'd like to propose to the client - and I'm requesting your thoughtful
responses on this proposal - is to break out the connection strings into a
separate .config file that is referenced from Web.config. This separate
config file would have only one set of connection strings per envoronment
(e..g, 3 connection strings total - one each to the dev, test, and
production). They wouldn't have to modify Web.config whenever a new
developer shows up or they need to run the app on a new computer. These
connection strings would not incorporate the host computer name at all.

Thoughts?

Thanks.

Thoughts? Is there something better I could do - other than breaking out
connection strings into a separate config file that is then referenced from
Web.config?
Nov 10 '08 #1
2 5343
If its 2.0 or above......its already done for you.
Note: In winforms or console apps, you'll have to add a POST BUILD EVENT
for the ExternalConnectionStrings.config file:
App.Config <<<<<<< This is the filename, not the contents of the file

<?xml version="1.0" encoding="utf-8" ?>
<configuration>

<connectionStrings configSource="ExternalConnectionStrings.config" />

</configuration>

ExternalConnectionStrings.config<<<<<<< This is the filename, not the
contents of the file

<connectionStrings>
<add name="LocalDatabaseInstance"
connectionString="server=.;database=MYDB;User ID=user1;password=password1"
providerName="System.Data.SqlClient"/>

</connectionStrings>



"Johnson" <A@B.comwrote in message
news:eI*************@TK2MSFTNGP04.phx.gbl...
I'm trying to fix a "sub optimal" situation with respect to connection
string management. Your thoughtful responses will be appreciated.

I just started with a new client who has a bunch of legacy ASP.NET
applications that all manage connection strings in Web.config the same
way, like this:

This client has one Web.config file per application, and that one
Web.config file is duplicated across all environments (i.e., dev machines,
test, and production all have the exact same Web.config file, connection
strings and all).

For connection strings they specify one connection string per computer the
application may run on, including all development machines, all test
servers, and production server. The name of each connection string
includes the name of each computer on which the application may run, plus
the name of the connection string. They have a computer naming convention
where each dev box name is an abbreviation of the developer's name. More
formally, it's like this:

[computer name] + [connection string name]

Here are examples:
<!-- Local DEV Workstations -->
<add name="BSmithConnectionStringToInventoryDB"
connectionString="server=DevServer1; InitialCatalog="Inventory" ..." />
<add name="RJohnsonConnectionStringToInventoryDB"
connectionString="server=DevServer1; InitialCatalog="Inventory" ..." />
<add name="GBrooksConnectionStringToInventoryDB"
connectionString="server=DevServer1; InitialCatalog="Inventory" ..." />
<!-- Test Server -->
<add name="InventoryTestServer1ConnectionStringToInvent oryDB"
connectionString="server=DevServer1; InitialCatalog="Inventory" ..." />
<!-- Production Server -->
<add name="InventoryAppServer1ConnectionStringToInvento ryDB"
connectionString="server=DevServer1; InitialCatalog="Inventory" ..." />

You can see that the connection strings are identical except for the
computer name (which equates to developer name or "environment"). So yes,
for each new developer, the connection string must be duplicated and
tweaked (changing only the name).

The application, upon startup, looks to Environment.MachineName to
determine which connection string it is to use. So, if the application is
running on a machine for which there is an associated entry in Web.config,
then it will use that connection string.

WHY would they do this? From talking with the existing staff, it appears
that they don't want to deal with versioning Web.config. When moving the
application to different environments or their source control system, they
want to be able to copy the entire application, Web.config and all.

But their strategy (1) creates brittle connection strings, as one must
modify Web.config when moving to a new computer (or hiring another
developer; or a developer leaves...); (2) they in fact have a versioning
problem in that whenever a new connection string is needed, all
developer's copy of Web.config must be updated, etc.

What I'd like to propose to the client - and I'm requesting your
thoughtful responses on this proposal - is to break out the connection
strings into a separate .config file that is referenced from Web.config.
This separate config file would have only one set of connection strings
per envoronment (e..g, 3 connection strings total - one each to the dev,
test, and production). They wouldn't have to modify Web.config whenever a
new developer shows up or they need to run the app on a new computer.
These connection strings would not incorporate the host computer name at
all.

Thoughts?

Thanks.

Thoughts? Is there something better I could do - other than breaking out
connection strings into a separate config file that is then referenced
from Web.config?

Nov 10 '08 #2
the seperate file is ok, but you still need to version it and have to be
careful with xcopy deployments. when I've used this approach, I generally end
using an approch like your customer, where every machine setting is in the
file.

you can also look at web deployment projects, which edit the web.config when
building the staging server. the main issue is you need to build a staging
for each enviroment.

you can reduce the number of connect strings by having a default
(localhost), as usually all the developers have the same settings.
-- bruce (sqlwork.com)
"Johnson" wrote:
I'm trying to fix a "sub optimal" situation with respect to connection
string management. Your thoughtful responses will be appreciated.

I just started with a new client who has a bunch of legacy ASP.NET
applications that all manage connection strings in Web.config the same way,
like this:

This client has one Web.config file per application, and that one Web.config
file is duplicated across all environments (i.e., dev machines, test, and
production all have the exact same Web.config file, connection strings and
all).

For connection strings they specify one connection string per computer the
application may run on, including all development machines, all test
servers, and production server. The name of each connection string includes
the name of each computer on which the application may run, plus the name of
the connection string. They have a computer naming convention where each dev
box name is an abbreviation of the developer's name. More formally, it's
like this:

[computer name] + [connection string name]

Here are examples:
<!-- Local DEV Workstations -->
<add name="BSmithConnectionStringToInventoryDB"
connectionString="server=DevServer1; InitialCatalog="Inventory" ..." />
<add name="RJohnsonConnectionStringToInventoryDB"
connectionString="server=DevServer1; InitialCatalog="Inventory" ..." />
<add name="GBrooksConnectionStringToInventoryDB"
connectionString="server=DevServer1; InitialCatalog="Inventory" ..." />
<!-- Test Server -->
<add name="InventoryTestServer1ConnectionStringToInvent oryDB"
connectionString="server=DevServer1; InitialCatalog="Inventory" ..." />
<!-- Production Server -->
<add name="InventoryAppServer1ConnectionStringToInvento ryDB"
connectionString="server=DevServer1; InitialCatalog="Inventory" ..." />

You can see that the connection strings are identical except for the
computer name (which equates to developer name or "environment"). So yes,
for each new developer, the connection string must be duplicated and tweaked
(changing only the name).

The application, upon startup, looks to Environment.MachineName to determine
which connection string it is to use. So, if the application is running on a
machine for which there is an associated entry in Web.config, then it will
use that connection string.

WHY would they do this? From talking with the existing staff, it appears
that they don't want to deal with versioning Web.config. When moving the
application to different environments or their source control system, they
want to be able to copy the entire application, Web.config and all.

But their strategy (1) creates brittle connection strings, as one must
modify Web.config when moving to a new computer (or hiring another
developer; or a developer leaves...); (2) they in fact have a versioning
problem in that whenever a new connection string is needed, all developer's
copy of Web.config must be updated, etc.

What I'd like to propose to the client - and I'm requesting your thoughtful
responses on this proposal - is to break out the connection strings into a
separate .config file that is referenced from Web.config. This separate
config file would have only one set of connection strings per envoronment
(e..g, 3 connection strings total - one each to the dev, test, and
production). They wouldn't have to modify Web.config whenever a new
developer shows up or they need to run the app on a new computer. These
connection strings would not incorporate the host computer name at all.

Thoughts?

Thanks.

Thoughts? Is there something better I could do - other than breaking out
connection strings into a separate config file that is then referenced from
Web.config?
Nov 10 '08 #3

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Shaun Ram | last post by:
Hi I have this constraint. A help would be greatly apprecitated. I have this Config file. <?xml version="1.0" encoding="utf-8" ?> <configuration> <configSections> <sectionGroup name="ITASCA">...
0
by: Shaun Ram | last post by:
Hi, I have this constraint. A help would be greatly appreciated. I have this Config file. <?xml version="1.0" encoding="utf-8" ?> <configuration> <configsections> <sectionGroup...
7
by: John A Grandy | last post by:
If a SQLDataSource add the following to my web.config file, how to I programmatically extract the connection string: <configuration> <appSettings/> <connectionStrings> <add...
8
by: theWizard1 | last post by:
Using Asp.NET 1.1, and C#. I have a directory for the website, and a directory under it named Secure. I have a web.config in each of the above directories. The web.config in the Secure...
10
by: eagle | last post by:
I have a web.config in my application that contains the connection strings to all my datasources. I want to move these connection strings to another web config up the folder hierarchy so that all...
3
by: rlueneberg | last post by:
Can someone explain the difference of using these functions below? And what is the advantage/disadvantage of each? static public SqlConnection GetConnectionString(string ConnectionStringName) {...
3
by: =?Utf-8?B?Sm9obkJhdGVz?= | last post by:
I'm trying to (programatically) backup and clear the security event log on the local machine. I can do this manually through the event viewer and I am logged on as an administrator. I can...
0
by: TG | last post by:
Hi! Once again I have hit a brick wall here. I have a combobox in which the user types the server name and then clicks on button 'CONNECT' to populate the next combobox which contains all the...
2
by: Johnson | last post by:
I'm trying to fix a "sub optimal" situation with respect to connection string management. Your thoughtful responses will be appreciated. I just started with a new client who has a bunch of legacy...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.