Managing A Debug and Release Connection String

Question

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.

AxelEckenberger · Accepted Answer · 2010-03-04T22:00:37.223

17

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

edited Mar 04 '10 at 22:00

answered Mar 04 '10 at 21:30

AxelEckenberger

16,628
3
48
70

I think this is a good suggestion. Can you elaborate on how to add a precompile condition to a VS-2008 project? I am not using MSBuild or any other build process. I simply clean/rebuild and deploy from within Visual Studio. – Mar 04 '10 at 21:43
Thank you friend. Your method and sample code made short work of this task. – Mar 05 '10 at 13:59
The downside of this method is that the project with the Web.config will be determined as not 'up to date' every time the solution is built (since one of the files of the project - Web.config - was modified) causing that project to always be built when the solution is compiled, even if it wasn't really changed. – BornToCode Dec 25 '21 at 18:47
The solution was OK by 2010 standards. Nowadays, however, there is support for this built into VisualStudio. If you using a studio that does not support the feature, you can look into the Slow Cheetah extension. – AxelEckenberger Jan 27 '22 at 09:12

score 9 · Answer 2 · answered Mar 04 '10 at 21:28

9

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.

answered Mar 04 '10 at 21:28

H H

263,252
30
330
514

Sameh Deabes · Answer 3 · 2010-03-05T04:55:41.250

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.

score 2 · Answer 4 · answered Mar 04 '10 at 21:27

2

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.

answered Mar 04 '10 at 21:27

jjxtra

20,415
16
100
140

+1 I like the idea of changing something on the server itself. This seems less error-prone than the other approaches. – Jeffrey L Whitledge Mar 04 '10 at 21:43
Thank you for this suggestion. It is perhaps the most practical and convenient. – Mar 04 '10 at 21:44
The only downside is that if you have a lot of production servers in a big web farm, you have to make sure to set the Environment variable, although if you have an image you just slam on it's less of an issue. – jjxtra Mar 04 '10 at 23:14

score 1 · Answer 5 · answered Mar 04 '10 at 22:48

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.

score 1 · Answer 6 · answered Mar 23 '18 at 14:21

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

score 0 · Answer 7 · answered Jun 07 '12 at 15:02

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.

score 0 · Answer 8 · answered Mar 04 '10 at 21:28

0

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.

answered Mar 04 '10 at 21:28

Hassan Syed

20,075
11
87
171

While I don't think your answer deserves a downvote, I really don't want to go the DSN route. – Mar 04 '10 at 21:45

score 0 · Answer 9 · answered Jun 07 '19 at 09:32

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.

Managing A Debug and Release Connection String

9 Answers9

Linked