如何使C＃.net中的应用程序的连接字符串独立于计算机？

Question

As I transfer my application in C#.net from one computer to another, I have to change the connection string every time as the location of the Database file has changed.

How can I can I prevent this,so that I don't have to change the connection string again and again?

Answer 1

When location of the database changes, something has to change somewhere. Back in the ODBC days, you could define a system-wide connection and specify the just the name in the connection string. But if the server moves you would have to change the ODBC anyway.

I can think of a few solutions here. One is that if your database runs on the local machine, use the localhost instead of the machine name.

In case it is a file, create a network share and put it on that so that you use \\\\localhost\\shareName\\file.db .

If it is a server database and could be on other machines, use a DNS name by using a host file and assign a common name so that you could do that in different networks.

Answer 2

• If it is feasible, put your database on a network and specify the network location in the connection string;

  or

• Modify the variable part(s) of your connection string using a Connection String Builder .

Answer 3

Use a relative path. For most scenarios, you can just use the built-in |DataDirectory| , which translates to the base directory you're running from (or App_Data in ASP.NET scenarios).

If you are using a client-server database, like SQL Express, then you should also set the server name to something like .\\SQLEXPRESS - which will use the local instance.

Answer 4

This one is an old one that comes up from time to time.

Visual Studio has the ability to support multiple build environments and will allow you to specify environment specific values (ie databse connection strings) so that you may test wherever you want.

Pulled this from the Gu's blog and full post may be seen here :

It turns out you can easily automate this configuration process within the Visual Studio build environment (and do so in a way that works both within the IDE, as well as with command-line/automated builds). Below are the high-level steps you take to do this. They work with both VS 2005 and VS 2008.

1. Use ASP.NET Web Application Projects (which have MSBuild based project files)
2. Open the VS Configuration Manager and create new "Dev", "QA", "Staging" build configurations for your project and solution
3. Add new "web.config.dev", "web.config.qa", and "web.config.staging" files in your project and customize them to contain the app's mode specific configuration settings
4. Add a new "pre-build event" command to your project file that can automatically copy over the web.config file in your project with the appropriate mode specific version each time you build the project (for example: if your solution was in the "Dev" configuration, it would copy the web.config.dev settings to the main web.config file).

In VS 2010 I believe most of the setup for this is done for you when you make your new application, but the principles are still the same. You can skip the pre-build event in favor of pulling the connection string in via code if you're comfortable with that way of doing things. There is an example of this on StackOverflow here on this answered question

The start of the answer (or at least how I'm more likely to implement this) is to store each connection string value in a separate connections.config file with a name unique to the environment. This will only contain the values from connectionStrings portion of the web.config file. I like doing this because it means adding a new environment doesn't mean a developer touching the main web.config file and you can also do some server-side trickery to remove the database connection strings from the site's webroot making it a bit more secure.

Method for removing the connectionStrings to another fole may be seen here: http://www.bigresource.com/Tracker/Track-ms_sql-cberGbNT/

I would also look into having a network accessible version of the database instead of making each developer have one in their environment. If you have to have disconnected work being done that makes sense, but from a management standpoint there should really only be one database for each stage of the project (Development, Staging, and Production).

Hope that's helpful, and feel free to ask follow-up questions on anything that doesn't make sense.