peschuster

Technology, .NET and Web

  • Info

Configuration

How to configure ConnectionStrings in web.config per developer/user

December 9, 2012 by peter

One thing Martin Fowler states in his article about Evolutionary Database Design is that every developer needs to have its own database instance.

For .NET Windows client projects you can simply change the ConnectionStrings configuration in the App.config file inside the bin directory. But for web/ASP.NET projects this is not possible, because the root directory for debugging the project is the project directory itself (being under source control). I.e. you would have to checkout the web.config file from source control and edit it. This itself is not such a problem, but you always have to watch out to not check the changed web.config file into source control.

The Solution

A solution to make this work is to split the web.config configuration into multiple files and extend the build process by editing the project file of the web project to create a configuration file which is not in source control and therefore can be customized per developer.

1. Split the configuration

Replace the connectionStrings configuration in your web.config file with the following line:

  <connectionStrings configSource="connectionStrings.config" />

2. Create a default configuration

Create a new configuration file “connectionStrings.default.config” with your configured ConnectionStrings (example):

<?xml version="1.0" encoding="utf-8"?>
<connectionStrings>
    <add 
      name="MyDbConnection" 
      connectionString="Data Source=(local)\SQLEXPRESS;Initial Catalog=MyAppDb;User ID=myapp;Password=123pw" />
</connectionStrings>

3. Extend the build process

Edit the project file and include a new target “BeforeBuild” (at the bottom of the file, but inside the “project” node):

<Target Name="BeforeBuild">
  <Copy 
      Condition="!Exists('connectionStrings.config')" 
      SourceFiles="connectionStrings.default.config" 
      DestinationFiles="connectionStrings.config" />
</Target>

This extends the build process with a new step which checks whether the file “connectionStrings.config” exists and (if not) copies the file “connectionStrings.default.config” to “connectionStrings.config“. When you want to change a ConnectionString in your local development environment you can simply edit the file “connectionStrings.config” and adjust it to your environment.

4. Add a transformation for publishing

For publishing/deploying your project you can create a web.config transformation which “inlines” the ConnectionStrings again:

<?xml version="1.0" encoding="utf-8"?>

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <connectionStrings xdt:Transform="Replace">
    <add 
      name="MyDbConnection" 
      connectionString="Data Source=(local)\SQLEXPRESS;Initial Catalog=MyAppDb;User ID=myapp;Password=123pw" />
  </connectionStrings>
</configuration>

Summary

Summing it up, the solution consists of the following parts

  • An outsourced ConnectionString configuration not under source control.
  • A default ConnectionString configuration under source control.
  • A build step ensuring a ConnectionString configuration exists at the expected path.
  • (Optional) A web.config transformation for cleaning everything up on publishing/deploying the project.
Posted in: .NET, ASP.NET Tagged: .NET, ASP.NET, Build, Configuration

Upgrading user settings

July 12, 2011 by peter

Or: Why your saved settings are always overridden by the previous ones

In an application of mine I persist user settings (like username, form position, window state, etc.) in a user configuration file (for more information on this topic in general have a look at this MSDN article).

In code you can access this settings like this:

var user = Properties.Settings.Default.User;

Properties.Settings.Default provides also methods for saving changed settings and upgrading persisted settings from a previous application version.

What upgrade does is to copy the settings file from a path like “path-to-settings/Company/MyApplication/1.0.0.1/user.config” to the path reflecting the current application version: “path-to-settings/Company/MyApplication/1.0.0.2/user.config”.

The crux of the matter is that copying the file is always performed, never the less whether there is already a user configuration file for the current version or not.

In conclusion this means you as the programmer have to make sure that Upgrade is only called once after you upgraded to a new version. Otherwise all changed values are always replaced by the last state from the old application version.

An easy solution to circumvent the described behavior of the upgrade method is to check whether a property in the user settings has still its default value, although it should have been set already:

if (String.IsNullOrEmpty(Properties.Settings.Default.User))
    Properties.Settings.Default.Upgrade();
Posted in: .NET Tagged: .NET, Configuration, UserSettings

Syndication

  • RSS 2.0

Recent Posts

  • Ubiquiti EdgeRouter™ X SFP – Teardown
  • Force HttpWebRequest to IPv4
  • Blackmagic Design ATEM GPI and Tally Interface Teardown
  • WinForms ListView DoubleClick Event for Empty Lists
  • Planning Center Online – Custom Plan Reports in Landscape Orientation

Tags

.NET AntiXssEncoder ASP.NET Build c# Configuration crawler Debugging EF ELMAH Expression tree Graphite Interop IssuerNameRegistry iTunes Linq ListView MVC pco pdf Security SecurityKey SecurityToken simulatebe sql server StatsD STS teardown TYPO3 UAC UI UserSettings Visual Studio WIF WIF in depth WinForms WndProc
profile for Peter at Stack Overflow, Q&A for professional and enthusiast programmers Peter Schuster

Copyright © 2025 peschuster.

Alpha WordPress Theme by themehall.com