Menu
Right now our test and production databases are on the same server, but with different names. Deploying has meant editing Web.config to change all the connection strings for the correct database. A step which I forget all too frequently...
We've finally created a new database server for testing, and I'm moving the databases over... but now the server will be different and we'll still need to deal with connection string issues.
I was thinking of managing it via a hosts file, but the thought of switching that on my desktop machine whenever I need to test against production data seems cumbersome at best.
So I'm just wondering if there's a better way out there. Something that would build with a "production" web config for deployment would be ideal...
805
You need to use the connectionStrings tag to specify the connection string in the web.config file as in the following image. Write this XML markup in the web config file for declaration of the connection. You can add many tags for each database connection. Now I will describe how to read a web.config connection string in an ASP.NET web application.
Open the application root Web.config file shown below. (Not the Web.config file in the Views folder.) Add the following connection string to the <connectionStrings> element in the Web.config file. The following example shows a portion of the Web.config file with the new connection string added: The two connection strings are very similar.
The benefit of writing a connection string in a web config file is there is no need to write code every time to connect to the database. It reduces the redundancy of code over a single application. One more benefit of this is whenever we need to change the database name or credentials we need to change only the web config file.
Go to the Web.config file as in the following: You need to use the connectionStrings tag to specify the connection string in the web.config file as in the following image. Write this XML markup in the web config file for declaration of the connection. You can add many tags for each database connection.
Use a Web Deployment Project and update the wdproj file (it's just an MSBuild file) with some post build tasks to output the correct .config file. I keep a web.config and web.release.config then use this in the wdproj file:
<Target Name="AfterBuild">
<Copy Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' " SourceFiles="$(SourceWebPhysicalPath)\web.release.config" DestinationFiles="$(OutputPath)\web.config" />
<Delete Files="$(OutputPath)\web.release.config" />
</Target>
More information
A simpler solution some like is using configSource property of appSettings and connectionStrings and then never overwriting that file on the production server.
77
I usually have three separate web configs: one for my development machine, one for QA, and one for production. The development one connects to my local SQL database (which is firewalled from outside) and it is the default web.config. The others are named web-prod.config and web-qa.config. After publishing I delete the two that I don't need and rename the correct one to web.config. If I forget, the app breaks the first time it attempts to access the database, since the default config references one it can't get to.
Since IIS refuses to serve up a file named .config, I make sure they all end in .config instead of say web.config-prod or web.config-qa.
5
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
