views:

315

answers:

5

In a .NET project, say you have a configuration setting - like a connection string - stored in a app.config file, which is different for each developer on your team (they may be using a local SQL Server, or a specific server instance, or using a remote server, etc).

How can you structure your solution so that each developer can have their own development "preferences" (i.e. not checked into source control), but provide a default connection string that is checked into source control (thereby supplying the correct defaults for a build process or new developers).


Edit: Can the "file" method suggested by @Jonathon be somehow used with the connectionStrings section?

A: 

I always make templates for my config files.

As an example I use NAnt for the building of my projects. I have a file checked in called local.properties.xml.template. My NAnt build will warn the developer if local.properties.xml does not exist. Inside that file will be workstation specific settings. The template will be checked into source control, but the actual config won't be.

Scott Muc
A: 

I use quite archaic design that just works.

  • /Test_app.config
  • /Prod_app.config
  • /app.config

Then in my nant script, I have a task that copies, the current build environment plus _ app.config and copy it to app.config.

Its nasty, but you can't get in between providers and ConfigurationManager to spoof it, by saying providers look at "dev" or "prod" connection string and just have 3 named connection strings.

nant task:

<target name="copyconfigs" depends="clean">
  <foreach item="File" property="filename" unless="${string::get-length(ConfigPrefix) == 0}">
   <in>
     <items>
       <include name="**/${ConfigPrefix}App.config" />
       <include name="**/${ConfigPrefix}connectionstrings.config" />
       <include name="**/${ConfigPrefix}web.config" />
     </items>
   </in>
   <do>
    <copy overwrite="true" file="${filename}" tofile="${string::replace(filename, ConfigPrefix,'')}" />
   </do>
  </foreach></target>
DevelopingChris
+4  A: 

AppSettings can be overridden with a local file:

<appSettings file="localoveride.config"/>

This allows for each developer to keep their own local settings.

As far as the connection string, in a perfect world all developers should connect to a test DB, not run SQL Server each.

However, I've found it best to keep a file named Web.Config.Prd in source control, and use that for build deployments. If someone modifies web.config, they must also add the change to the .PRD file...There is no good automation there :(

FlySwat
A: 

Can the "file" method suggested by @Jonathon be somehow used with the connectionStrings section?

No, but there is nothing stopping you from storing the ConnectionString as an AppSettings key.

FlySwat
+3  A: 

Edit: Can the "file" method suggested by @Jonathon be somehow used with the connectionStrings section?

Or you can have multiple connection strings in the checked in config file, and use an AppSettings key to determine which ConnectionString is to be used. I have the following in my codebase for this purpose:

public class ConnectionString
{
    public static string Default
    {
        get 
        { 
         if (string.IsNullOrEmpty(ConfigurationManager.AppSettings["DefaultConnectionStringName"]))
          throw new ApplicationException("DefaultConnectionStringName must be set in the appSettings");

         return GetByName(ConfigurationManager.AppSettings["DefaultConnectionStringName"]);
        }
    }

    public static string GetByName(string dsn)
    {
        return ConfigurationManager.ConnectionStrings[dsn].ConnectionString;
    }
}
Scott Muc