Development vs Production: Connection Strings

Question

I'm in the process of moving SQL server to a separate machine. Currently we are running our web server and sql server on the same box. So we have a production server with IIS and SQLServer and then a separate development server that mirrors this setup.

When it comes to our asp.net control's app.config and web site's web.config, this has worked good because we could use "Initial Catalog=MyDB;..." and it worked because the DB name was the same on both machines.

Now I'm looking at running both DB's on the same box (MyDB, MyDB-Dev). Is there an easy way to do this without needing to edit the web.config and app.config each time we deploy or compile? Is this something Visual Source Safe could handle?

Answer 1

Here's the solution I use. In the Web.Config, place the following "include" line:

<connectionStrings configSource="WebCS.config"/>

Then, create the WebCS.config file and enter the following:

<connectionStrings>
<add name="ConnString" 
     connectionString="Data Source=YourServer;Initial Catalog=YourDB;etc..
     providerName="System.Data.SqlClient"/>
</connectionStrings>

Then, after publishing your site in VS, remove the WebCS.config file (I have a batch file to do this) before bundling everything else up for the transfer to the new machine. You'll then be assured that all of the Web.Config file settings go with you without messing with your connection string.

Answer 2

Deploying web.config is almost never a case of copying the file from dev to prod. It's normal to have differing entries, e.g. your dev website points to a local database or a dev database box and your prod website usually has to point to your prod database box.

When deploying, your production web.config usually only needs to be changed if you've made architectural changes in your app that require new config elements or you want to remove redundant ones.

With source control, usual practice is to exclude web.config and have a template file which can be used as a basis for creating a config file, e.g. web.config.template. When making structural changes to the web.config, you should make the changes to web.config.template, then make copies of it for dev and prod, and apply the dev and prod settings accordingly.

Answer 3

I use NAnt to build and deploy. I make my .config files into templates using the .config.template naming convention. I have a NAnt property named "environment" that I set from the command-line call to NAnt. At the top of my build.xml, I set a "db.connectionstring" property based on the "environment" property (like a switch statement). In the build task, I use grep to push the "db.connectionstring" string into the spot in the template for the build directory output. That way, I only need to call:

nant -D:environment=dev

This gets a dev-specific set of .config files.

If you don't like grep, follow this:

http://www.haidongji.com/2008/11/11/use-nant-to-replace-values-in-other-xml-config-files/

This only works for XML files. Grep is more generic. I actually have different database names based on the deployment environment, and grep lets me insert different database names into SQL scripts based on the environment.

Answer 4

I may not completely understand your question here, but it seems to me that when you deploy the application, you can simply not re-deploy the web.config unless there are changes in the web.config that need to be made. In other words, copy all the files to the directory except the web.config file.

If you do have to change the web.config file between deployments, you will need to edit the web.config for each server.

Alternatively, you could find another place on each machine to store the connection strings other than the web.config.