![]() |
![]() | ![]() | ![]() | ![]() | ![]() | ![]() | ![]() |
| Welcome to Windows Vista Forums. Our forum is dedicated to helping you find solutions with any problems, errors or issues you are experiencing with Windows Vista. The Vista forum also covers news and updates and has an extensive Windows Vista tutorial section that covers a wide range of tips and tricks. |
| |||||||
![]() |
| |
| | #1 (permalink) |
| | 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="InventoryTestServer1ConnectionStringToInventoryDB" connectionString="server=DevServer1; InitialCatalog="Inventory" ..." /> <!-- Production Server --> <add name="InventoryAppServer1ConnectionStringToInventoryDB" 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? |
My System Specs![]() |
| | #2 (permalink) |
| | Re: Web.config and Connection String Management 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@xxxxxx> wrote in message news:eIBIHN2QJHA.576@xxxxxx Quote: > 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="InventoryTestServer1ConnectionStringToInventoryDB" > connectionString="server=DevServer1; InitialCatalog="Inventory" ..." /> > <!-- Production Server --> > <add name="InventoryAppServer1ConnectionStringToInventoryDB" > 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? > |
My System Specs![]() |
| | #3 (permalink) |
| | RE: Web.config and Connection String Management 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: Quote: > 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="InventoryTestServer1ConnectionStringToInventoryDB" > connectionString="server=DevServer1; InitialCatalog="Inventory" ..." /> > <!-- Production Server --> > <add name="InventoryAppServer1ConnectionStringToInventoryDB" > 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? > > > |
My System Specs![]() |
![]() |
| Thread Tools | |
| |
Similar Threads | ||||
| Thread | Forum | |||
| TROUBLE with: Computer Management & System Config, Not running | Vista performance & maintenance | |||
| config internet connection used while VPN'd in | Vista networking & sharing | |||
| Help with connection string | .NET General | |||
| ASP connection string to SQL2005 | VB Script | |||
| How to config my wired NIC as primary connection? | Vista General | |||