Single App/ConnStrings Config File for Multiple Applications

[clamum]

I have been assigned to investigate how to implement a single point of storage for application & connection string configuration name/value pairs for multiple .NET applications. My first thought was a SQL Server database table, which could be used perhaps, but the problem is that connection strings could not be stored in it because they are first required to connect to the database itself.

At a previous job we did use external web.config files for a web application, for switching between Test/Prod I believe, by doing "<connectionStrings file="/ConnectionStrings.config" />" in the web.config and having external "ConnectionStrings.config" files.

Would this approach work for multiple .NET apps as it does for just a single web app? For example, a Windows app, Console app, and Windows Service app all sharing a single app.config file and a single connection strings config file? Any other recommendations?

Thanks for any insight!

 

[Savatar]

This sounds like it should work without a problem, or even just store a configuration file in a standard path (either hard-coded, passed via command-line, or in its local config file) and load with System.Configuration.ConfigurationManager:
http://stackoverflow.com/questions/...ger-to-load-config-from-an-arbitrary-location

The registry is always a possible too, though I hear that Microsoft is discouraging its use, in general. Those are two possibilities.

 

[Markbnj]

It definitely will work, if only because as Savatar said you can load and parse .configs manually without too much trouble.

Another option might be to use a redis instance as a centralized key/value store. You can secure the endpoint and keep a copy of the dump.rdf file as a backup of your configuration.

 

[clamum]

Thanks for the replies guys. Well I started by creating a solution and adding a Console Application and a Web Site to it. I put two files in C:\, named "SingleAppConfig.config":

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
    </startup>
  <appSettings file="/AppConfig.config"/>
</configuration>

and "AppConfig.config":

<appSettings>
	<add key="TestAppKey" value="this is a test value" />
</appSettings>

I originally tried to use the "AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", @"C:\SingleAppConfig");" route to implement this, but that did not work (worked fine in the Console app, Web App couldn't read it). So I instead tried Gavin's second solution from Savatar's link and this worked great:

ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap() { ExeConfigFilename = @"C:\SingleAppConfig.config" };
Configuration config = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);
AppSettingsSection appSettings = config.GetSection("appSettings") as AppSettingsSection;
var config = appSettings.Settings as KeyValueConfigurationCollection;
lblTestAppKey.Text = config["TestAppKey"].Value;

This allowed me to retrieve values from the SingleAppConfig.config file from both the Console and Web App, and additionally use the local Web.config in the Web App as well. AppSetting key/values that are in my Machine.config are also loaded into the AppSettingsSection in the above code. So now I just want to move this functionality into it's own class library and do some tidying up, but the basic functionality works.

Just thought I'd update with my solution in case someone else happens to find it helpful. Thanks again for the help guys.

 

[LokutusofBorg]

I've worked on systems that stored all environment-specific info in a database table, as you mentioned. You just have to configure the correct connection string for the environment (dev, test, prod, etc.), also as you mentioned. However, it's a bit of work keeping the tables updated with the correct values for the right environments when you have a complex deployment model (dev, test, prod, etc.) or even worse - customer site deployments. So I don't really favor using the database for this kind of stuff.

At another job, we did a centralized file-based config in our Core assembly, and I really liked how it worked. It was a bit of a bear figuring out how to get Visual Studio/MSBuild to copy the "sidecar" config files (that's what they're called) into the bin folder of any projects that referenced Core, but we got it working. I can share that code/config if you need.

For the centralized config files, we used ExeConfigurationFileMap as you have come up with. We used a custom XML schema for simplicity sake by sub-classing ConfigurationSection, ConfigurationElement, et al. We then wrapped it in a static class called EnvironmentSettings and exposed each setting as a strongly-typed property.

That let us have XML like this:

<configuration>
  <configSections>
    <section name="customSettings" type="Core.SystemConfig.CustomSettingsSection, Core.SystemConfig" />
  </configSections>
  <customSettings>
    <someCustomSettingName>Any basic value type value here...</someCustomSettingName>
    ...
  </customSettings>
</configuration>

The property mapping inside our ConfigurationElement derived class looks like this:

[ConfigurationProperty("someCustomSettingName", IsRequired = true)]
internal TextElement SomeCustomSettingName { get { return (TextElement)this["someCustomSettingName"]; } }

The wrappers to strongly-type the values in EnvironmentSettings then look like this:

// for a string value
public static string SomeCustomSettingName { get { return CurrentCustomSettings.SomeCustomSettingName.ToString(); } }

// for a bool value
public static bool SomeCustomSettingName { get { bool result = false; return Boolean.TryParse(CurrentCustomSettings.SomeCustomSettingName.ToString(), out result) && result; } }

(CurrentCustomSettings is a static field used to store the loaded config from the ExeConfigurationFileMap part of things.)

And code that called it simply looks like this:

var someSettingValue = EnvironmentSettings.SomeCustomSettingName;

I don't know if that will help you any, but there it is... Let me know if you have any questions.