connection string in web config

Question

I have a web application which i make on my local host and publish it on different servers.

in the web config of this application i have connectionstrings property like:

<connectionStrings>
<add name="MyConnectionString" connectionString="Data Source=XYZ-PC\SQLEXPRESS;Initial Catalog=SumooHServerDB;Integrated Security=True" providerName="System.Data.SqlClient"/>

Now connectionstring data source has the name of my server and when ever i publish it and run this application on different server i have to change XYZ-PC\SQLEXPRESS to the name of the server..

Is there a way i dont have to do this as it does not feel right..

any suggestions..

thanks

Answer 1

If database stands on the same server as IIS, you can use Data Source=localhost\sqlexpress

Answer 2

Like lots of people, I've wanted to store my ConnectionString in the web.config file. Again, like lots of people, I have different ConnectionStrings, one for the "live" server, one for the "development" server, and yet another for the "reporting" server. I'm sure many of you have the same thing. So then, you do development using the appropriate ConnectionString. Then when you deploy, how do you switch the ConnectionString to the new one? What I do, is in my web.config file I have quite a few parameters, not just ConnectionString. Like this:

LiveWebServerName, LiveServerConnectionString, DevServerConnectionString, ReportServerConnectionString, etc.

Then, in the application start code, I read those settings, and determine which ConnectionString to use. For example, if the LiveWebServerName is "SuperServer" and my application start code determines that it is indeed running on a box named "SuperServer" then it assigns the value from LiveServerConnectionString to be the "active connection string" for use throughout the site. Otherwise, it uses the DevServerConnectionString.

The strength of this, is that you don't have to remember to switch your web.config file, or have a second copy of the web.config, one for "live" and one for "dev." Or any tricks like that. This makes it foolproof. What is cool is that, no matter where you run your site from (your laptop, any team member's localhost, etc), it will only use the Development Server, never the Live Server. No chance for you to make a mistake and mess it up :) And of course once you deploy to your Live Web Server, it will automatically use the Live SQL Server.

http://weblogs.sqlteam.com/travisl/archive/2003/11/18/550.aspx

Answer 3

Try replacing XYX-PC with localhost provided the instance name is the same.

Answer 4

I like to use configSource to pull the connection string out into a separate file, as explained here*: http://stevenharman.net/blog/archive/2007/06/07/tip-put-connection-strings-in-their-own-configuration-file.aspx

That way, you can configure each server's connectionStrings.config once, but continue updating their web.config files with a single version that works for all of them.

* Except, I usually name it connectionStrings.config, so it's more obvious for maintenance by others.

Answer 5

Hello,

The following article could be a solution to your question : Handling Multiple Environment Configurations with .NET 2.0

Basically, the idea is to use the fact that in your config file you can indicate that some sections have to be read from an external file. Than during the build of your project you copy the right external file according to your environment. I think the link will explain this better.

Answer 6

use this connection string :

name="MyConnectionString" connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=SumooHServerDB;Integrated Security=True" providerName="System.Data.SqlClient"

it will work.

Answer 7

Take a look at Web Deployment projects.

In addition to letting you merge everything into a single assembly, it give you the option of doing section-based web.config replacements. We use this on our build server to alter the standard web.config for running in the test environment. As a bonus, you're not limited to just changing connection strings. Anything in the web.config is fair game.