Managing A Debug and Release Connection String

问题:

What is a good approach to managing a debug and release connection string in a .NET / SQLServer application?

I have two SQL Servers, a production and a build/debug and I need a method of switching between the two when my ASP.NET application is deployed.

Currently I simply store them in the web.config and comment one or the other out, however that is error prone when deploying.

回答1:

Create a Debug and Release version of the Web.config file, e.g. Web.debug.config and Web.release.config. Then add a pre-compile condition that copies the relevant version into the web.config based upon the current Target.

Edit: To add the pre compile condition right click on you project and select "Properties" then goto the "Build Events" tab and add the code below to the precompile condition. Obviously, you will have to ammend the code to your needs, see image below.

@echo off

echo Configuring web.config pre-build event ...

if exist "$(ProjectDir)web.config" del /F / Q "$(ProjectDir)web.config"

if "$(ConfigurationName)" == "Debug Test" goto test
if "$(ConfigurationName)" == "Debug M" goto M
if "$(ConfigurationName)" == "Debug BA" goto BA
if "$(ConfigurationName)" == "Release Test" goto test
if "$(ConfigurationName)" == "Release M" goto M
if "$(ConfigurationName)" == "Release BA" goto BA

echo No web.config found for configuration $(ConfigurationName). Abort batch.
exit -1
goto :end

:test
copy /Y "$(ProjectDir)web.config.test" "$(ProjectDir)web.config"
GOTO end

:BA
copy /Y "$(ProjectDir)web.config.BA" "$(ProjectDir)web.config"
GOTO end

:M
copy /Y "$(ProjectDir)web.config.M" "$(ProjectDir)web.config"
GOTO end

:end
echo Pre-build event finished

Project Properties http://img442.imageshack.us/img442/1843/propsa.jpg

回答2:

The good news is that .NET4 has a provision for just that, you can have separate configs for each Configuration (web.Release.config, web.Debug.config).

The bad news is ... you're probably not using that yet.

回答3:

Use preprocessor directives: when your project is configured to run in the debug mode, the debug connection string will be chosen, otherwise the release connection string will be chosen automatically.

In Visual studio you will notice that statements are dimmed exclusively according to the project configuration (debug or release).

Just add something like the following in your code:

string myConnectionString;
#if DEBUG
     myConnectionString = "your debug connection string";//may be read from your debug connection string from the config file
#else
     myConnectionString = "your release connection string"; //may be read from your relase connection string from the config file
#endif

for more detail,check this.

回答4:

I usually set an Environment variable on my production servers that denotes the server is a production server. I then read the correct connection string from my web.config based on whether this Environment variable exists and is set to the production value.

回答5:

I use a combination of Sameh's and Obalix's method in .net 3.5.

    public static class DataConnection
{
#if LOCALDEV
    public const string Env = "Debug";
#endif
#if STAGING
    public const string Env="Staging";
#endif
#if RELEASE
    public const string Env="Release";
#endif
    private static ConnectionStringSettingsCollection _connections;
    static DataConnection()
    {
        _connections = ConfigurationManager.ConnectionStrings;

    }

    public static string BoloConnectionString
    {
        get
        {
            return _connections["DB1."+Env].ConnectionString;
        }
    }
    public static string AOAConnectionString
    {
        get
        {
            return _connections["DB2."+Env].ConnectionString;
        }
    }
    public static string DocVueConnectionString
    {
        get
        {
            return _connections["DB3."+Env].ConnectionString;
        }
    }
}

Then in my project properties, I define the right conditional compilation symbols. This way I don't have to keep my connection strings hard coded like Sameh's, but the code only looks for the string based on how it was built. This lets me have (if I need to) one config file for all the builds, but in reality I don't deploy the config files in my build process. Although the conditional app.Relase.config stuff for .net 4 looks like the right way to go in the future.

回答6:

Well perhaps this is a bit outdated, but the ODBC DSN solves this problem quite well -- I still use -- with rigour -- DNS settings to differentiate between production and debug environments.

p.s., I am expecting loads of down-votes, perhaps this will be a gauge of what people think of a level of indirection for database identifiers.

回答7:

I can say other solution for this issue. In csproj file file create folow:

<Content Include="DB.config">
  <SubType>Designer</SubType>
</Content>
    <Content Include="DB.Debug.config">
  <DependentUpon>DB.config</DependentUpon>
  <SubType>Designer</SubType>
</Content>
    <Content Include="DB.Release.config">
  <DependentUpon>DB.config</DependentUpon>
  <SubType>Designer</SubType>
</Content>

In xml written set the two version for release and debug.

回答8:

As of 2018 for newer versions of Visual Studio, Microsoft has taken over the SlowCheetah extension. Installing this will give you an option to split the app.config file into three separate files. One is a base file that has code that always applies, and then you get an app.debug.config file and an app.release.config file.

Note that pulling this as a NuGet package in the project is not enough. If you want the Visual Studio UI menu option, you need to actually download the installer from the site below and run it. Then, install SlowCheetah specifically on any projects you want to use this on using NuGet.

Also note that the original SlowCheetah program by the original developer still exists, but use the one published by Microsoft for newer versions of Visual Studio.

https://marketplace.visualstudio.com/items?itemName=VisualStudioProductTeam.SlowCheetah-XMLTransforms

回答9:

When you open a web project you'll get 2 extra files of the Web.Config out of the box - Web.Debug.config & Web.Release.config.

1.Add your desired connection string to those files with XSLT attributes xdt:Transform="SetAttributes" xdt:Locator="Match(name)"

<connectionStrings>
  <add name="myConnectionString" connectionString="myConnectionString" xdt:Transform="SetAttributes" xdt:Locator="Match(name)" />
</connectionStrings>"

2.Edit your csproj and add a TransformXml target:

<Target Name="TransformActiveConfiguration" Condition="Exists('$(ProjectDir)/Web.$(Configuration).config')" BeforeTargets="Compile" >
    <TransformXml Source="$(ProjectDir)/Web.Config" Transform="$(ProjectDir)/Web.$(Configuration).config" Destination="$(TargetDir)/Web.config" />
</Target>

The second step will make the transform on each build (according to your active configuration) and not only on publish, giving you a better debug experience. I learnt it from this post.