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



<callout type="Navigation" class="small">

* [[../|(UP)]]
{{indexmenu>.#2|nsort tsort}}


</callout>


<panel title="Summary">

Whereas a lot of settings can be moved from AppSettings to the Database, the ConnectionString to the Database cannot (as it is needed to connect to the database).


</panel>


## Strategies ##

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:

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

>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:

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

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

TODO: Explain how to lock it from Checking in.

#### Use Transforms to Cleanup before Releasing to ST, QAT, PROD

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:

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

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

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

    </configuration>
</sxh>


[[IT/#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



### Using the File Attribute for Individual AppSettings

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 [[IT/#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.

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


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

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


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:


<sxh xml>
  <appSettings xdt:Transform="RemoveAttributes"/>
</sxh>


## Resources ##
* 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