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

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.

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

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 5

check out the configSource attribute of the connectionStrings element in the web.config

that should make it easy enough

Answer 6

Just so I'm clear, your current environment is two servers, i.e.

Dev App/DB Server
Production App/DB Server

and you're thinking of making it something like this

App Server (dev+production)
DB Server (dev+production)

If that's the case, I commend you for isolating the DB and the application into two separate servers - when moving from a single server environment that's the first step as it allows for easy upgrade later if you need to cluster multiple DB servers or (more commonly) load balance multiple webservers in front of a single DB server to help application performance.

Having said that, I don't suggest running the dev and production environments side by side like this on the same server. While it may make sense financially, the purpose of an isolated dev environment is to keep 'dev mistakes' from bleeding over into production, and doing it like this can lead to downtime if you have some bad code that gets pushed to the dev environment.

Answer 7

Can you put all the connections strings in the web.config and then at a main point in the application determine which one to use based on the app server?