Azure connection string best practices

Solution 1:

In cases where it doesn't matter if the developer can see production credentials, you can use the built-in Visual Studio 10 config transformations. If this is what you're looking for, follow these steps:

1.Navigate to your Azure project folder in file explorer
2. Make a copy of ServiceConfiguration.cscfg
3. Rename copy to ServiceConfiguration.Base.cscfg
4. For each build configuration (e.g. Dev, Staging, Production), create a ServiceConfiguration.<build config name>.cscfg file. In these files, you can use the normal config transformation syntax
5. Open your .ccproj file in a text editor
6. Find the following node,

<ItemGroup>
    <ServiceDefinition Include="ServiceDefinition.csdef" />
    <ServiceConfiguration Include="ServiceConfiguration.cscfg" />
</ItemGroup>

and replace it with this (you will have to edit this block to match your build configs):

<ItemGroup>
    <ServiceDefinition Include="ServiceDefinition.csdef" />
    <ServiceConfiguration Include="ServiceConfiguration.cscfg" />
    <None Include="ServiceConfiguration.Base.cscfg">
        <DependentUpon>ServiceConfiguration.cscfg</DependentUpon>
    </None>
    <None Include="ServiceConfiguration.Dev.cscfg">
        <DependentUpon>ServiceConfiguration.cscfg</DependentUpon>
    </None>
    <None Include="ServiceConfiguration.Staging.cscfg">
        <DependentUpon>ServiceConfiguration.cscfg</DependentUpon>
    </None>
    <None Include="ServiceConfiguration.Production.cscfg">
        <DependentUpon>ServiceConfiguration.cscfg</DependentUpon>
    </None>
</ItemGroup>

7.Add the following at the end of the .ccproj file, just above </Project>:

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets" />
<Target Name="BeforeBuild">
    <TransformXml Source="ServiceConfiguration.Base.cscfg" Transform="ServiceConfiguration.$(Configuration).cscfg" Destination="ServiceConfiguration.cscfg" />
</Target>

8.If you're using a CI server that doesn't have Visual Studio 10 installed, you'll probably have to copy the C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\Web folder and its contents from a development machine to the server.

Update: As @SolarSteve noted, you might have to add a namespace to your ServiceConfiguration.*.cscfg files. Here's an example of ServiceConfiguration.Base.cscfg:

<sc:ServiceConfiguration serviceName="MyServiceName" osFamily="1" osVersion="*" xmlns:sc="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <sc:Role name="MyRoleName">
    <sc:Instances count="1" />
    <sc:ConfigurationSettings>
      <sc:Setting name="DataConnectionString" value="xxx" />
    </sc:ConfigurationSettings>
  </sc:Role>
</sc:ServiceConfiguration>

Solution 2:

Personally we:

1. Dropped web config transformations completely.
2. Setting is retrieved from cscfg.
3. Development version of cscfg points to local development environment (that's stored in version control).
4. While deploying to production, we supply secure credentials for production SQL Azure and storage.

For sample of the settings management class that scans application settings and cloud environment for configuration values, you can check out open source Lokad.CQRS for Windows Azure project (see CloudSettingsProvider)

Solution 3:

You can use CloudConfigurationManager in Azure SDK 1.7 http://msdn.microsoft.com/en-us/LIBRARY/microsoft.windowsazure.cloudconfigurationmanager

This starts by looking in the ServiceConfiguration.cscfg e.g. ServiceConfiguration.Cloud.cscfg for config setting. If it isn't there it falls back to web.config and app.config

For example

CloudConfigurationManager.GetSetting("StorageConnectionString")

Will look in the appropriate cscfgfile for StorageConnectionString setting, then it will search the web.config and then app.config.

Solution 4:

We have a number of environments (local dev inside dev fabric, local dev outside dev fabric, testing, release which has 2 versions: release/prod and release/staging and 20 projects some of which need some variability in configure settings. We solved this problem by creating a tiny "config" project, included subfolders there that match the environments. We copy files from the subfolder depending on which build we're doing into root folder of the config project, during every compile.

All other projects link to the config project for .config files. We also use partial config files to keep the insanity of repeating the same info all the time across various environments.

Hope this helps