IT:AD:ConnectionStrings:HowTo:Strategies To Share Among Developers

The question is not new, and several solutions have been tried:

• http://wakeupandcode.com/all-your-database-are-belong-to-us/

The solution* I preferred is:

Note:that I said preferred in the past tense. That was before I discovered NConfig.

• See: IT:AD:NConfig

#

### Use an External ConnectionString.config

Edit the config file to configSource in an external config file fragment:

<configuration>
  <connectionStrings configSource="DEV\connectionStrings.config"/>
</configuration>

Note that the config file in turn points has to be have a root node named `connectionStrings` (matching the name of the node the `configSource` attribute was attached to in the original config file)

The fragment file's contents would look like:

<connectionStrings>
  <add name="AppDbContext" 
    providerName="System.Data.ProviderName" 
    connectionString="Valid Connection String;" />
</connectionStrings>

Each Developer keeps his own connectionStrings.config file and ensures it is never checked in.

TODO: Explain how to lock it from Checking in.

Cleaning up the config file before releases to ST and PROD is handled by XDT Transforms (see: IT:AD:XDT:HowTo:Transform Connection Strings)

For example, the XDT for Web.ST.config could look like one of the following solutions:

   <configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
        <connectionStrings xdt:Transform="SetAttributes" configSource="ST\ConnectionStrings.config"/>
    </configuration>

Alternatively, replace the whole thing with an inline connection string:

   <configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
 
  <connectionStrings xdt:Transform="Replace">
    <add name="AppDbContext" connectionString="todo" providerName="todo" />
  </connectionStrings>

    </configuration>

ACiD/ of this approach:

• Advantages:
  • Many developers can use the above.
  • IT:AD:WebDeploy takes care of generating ST, QAT and PROD transformations.
• Considerations:
  • The Configs/Dev folder has to be within the solution for the configuration system to work – therefore the folders remain part of the solution on ST and PROD – even if empty.
  • In VS2012 XTD's are only done for Web.Configs. For WindowsServices, you'll have to investigate how it can be done.
  • Each Test.dll assembly will have to have the same setup as the AppHost.Web assembly?
• Disadvantage:
  • There's always some developer who checks it in – and since everybody else isn't change tracking their own file…

    • The files that configSource can point to have to be under the project.
      • By default can't share across projects in a solution, so has to be updated in both the AppHost.Web and AppHost.Test assemblies without getting “The configSource attribute is invalid.: The configSource '..\Config\Dev\connectionStrings.config' is invalid. It must refer to a file in the same directory or in a subdirectory as the configuration file.”
      • but see here for a solution to that: http://stackoverflow.com/a/693705/1052767
      • as well as consider: http://stackoverflow.com/a/634071/1052767

The above configSource element works for whole config file sections – such as connectionStrings – but does not work for single AppSettings, which is needed for handling unique values per machine (an example being a PostBack url that would have to registered in an primitive SSO/ solution (SAML based SSO's would expect the return address to be posted in the first request).

It at first appears there is no solution for settings such as those…that is incorrect.

Use the AppSettings File attribute for such scenarios.

  <appSettings file="Config\Dev\appSettings.config">
    <add key="KeyA" value="someBaseValueA"/>
    <add key="KeyB" value="someBaseValueB"/>
  </appSettings>

Which points to Configs\Dev\appSettings.config (again, a file that each dev does not check in):

<?xml version="1.0" encoding="utf-8" ?>
<appSettings>
  <add key="KeyB" value="I'm the replacement value per developer"/>
</appSettings>

Notice that KeyB will override any default value that is in the base config.

Notice also that if the file is missing, KeyB will fall back to the value that is in the base config file.

You can clean this up with the following XTD:

  <appSettings xdt:Transform="RemoveAttributes"/>

* http://msdn.microsoft.com/en-us/library/aa903313(v=vs.71).aspx * http://msdn.microsoft.com/en-us/library/dd465326.aspx * http://www.codeproject.com/Articles/399002/Project-Build-Web-config-transformation