Use XML includes or config references in app.config to include other config files’ settings

by

Yes, you can use the configSource attribute of the configuration block. All configuration blocks have this attribute – although it isn’t documented.

See this article, all the way at the bottom, appendix B. I’ve also pasted the relevant section below:

Appendix B: including external configuration files

Despite all the greatness to be found in .NET 2.0’s configuration features, there is one drawback. When working on a single project across multiple environments, managing configuration can become a nightmare. The process of managing multiple versions of a configuration file for multiple environments — i.e. development, testing, staging and production — at my current job involves manual comparisons of .config files whenever changes are deployed to one environment or another, with a manual merging process. I spent months trying to find a better way and eventually found one. Enter one of those oh-so beloved “undocumented” — or in this case, just poorly documented — features that Microsoft is so famous for: configSource. I only came across this little gem when I was digging through the .NET 2.0 configuration source code with Reflector, wonderful little tool.

Each configuration section, when parsed and loaded by the .NET configuration classes, is assigned a SectionInformation object. The SectionInformation object contains meta information about a configuration section and allows some management of how sections override each other when defined in a child config file (ASP.NET). For now, we will ignore the majority of what SectionInformation has to offer, save the ConfigSource property. By adding a configSource attribute to the root element of any ConfigurationSection, you can specify an alternate, external source from which the configuration settings will be loaded.

<!-- SomeProgram.exe.config -->
<configuration>
  <connectionStrings configSource="externalConfig/connectionStrings.config"/>
</configuration>

<!-- externalConfig/connectionStrings.config -->
<connectionStrings>
  <add name="conn" connectionString="blahblah" />
</connectionStrings>

In the configuration file above, the <connectionStrings> section has been sourced from a file called externalConfig/connectionStrings.config. All of the application’s connection strings will be loaded from the specified file. Now that the connection strings are loaded from an external resource, it is a relatively simple matter to create a connectionStrings.config file in each environment at the same relative location. Hence, the externalConfig/ part of the connectionStrings.config path. The beauty here is that we can define connection strings properly for each environment once. We do not have to worry about accidentally overriding those settings during a deployment where a config file was either merged improperly or not merged at all. This can be a huge boon when deploying changes in an application to a production environment, where it is critical that the correct database connection strings exist. The downfall of using the configSource attribute is that it requires all configuration settings to be placed in the external file. No inheritance or overriding is possible, which in some cases makes it useless. All external configuration files used with the configSource attribute must also reside in a relative child path to the main .config file. I believe this is in regards to security concerns with storing the file in a relative parent path in a web environment.

Something else to note is that the <appSettings> section has a better alternative to using configSource, called file. If you use the file attribute rather than configSource with the <appSettings> section, you can define settings in both the root .config file and in the referenced file. Settings from the root .config file may also be overridden in the referenced file, simply by adding something with the same key. Sadly, the file attribute is only available on the <appSettings> section and is not built into the configuration framework. It is possible to implement a similar attribute in your own configuration sections. This will be discussed in a future installment of advanced configuration topics, after several prerequisite installments ;).

More Related Contents:

  1. How to enable configSource attribute for Custom Configuration Section in .NET?
  2. Different text editor in .net development environment [closed]
  3. What is App.config in C#.NET? How to use it?
  4. How to read AppSettings values from a .json file in ASP.NET Core
  5. How can you change Network settings (IP Address, DNS, WINS, Host Name) with code in C#
  6. Performance differences between debug and release builds
  7. Change default app.config at runtime
  8. Reading settings from app.config or web.config in .NET
  9. Equivalent to ‘app.config’ for a library (DLL)
  10. How to implement a ConfigurationSection with a ConfigurationElementCollection
  11. Relocating app.config file to a custom path
  12. Can a unit test project load the target application’s app.config file?
  13. Programmatically encrypting a config-file in .NET
  14. .NET Configuration (app.config/web.config/settings.settings)
  15. Update app.config system.net setting at runtime
  16. Consume a SOAP web service without relying on the app.config
  17. Read from App.config in a Class Library project
  18. VS2005 C# Programmatically change connection string contained in app.config
  19. How to write to the main exe’s .config userSettings section?
  20. How to find path of active app.config file?
  21. How to modify my App.exe.config keys at runtime?
  22. Difference between ObservableCollection and BindingList
  23. String Concatenation using ‘+’ operator
  24. how to use XPath with XDocument?
  25. Travel through pixels in BMP
  26. memcpy function in c# [duplicate]
  27. .NET Core vs Mono
  28. Validating file types by regular expression
  29. ASP.NET Web API and [Serializable] class
  30. trying to convert rgb from a .net Color to a string such as “red” or “blue”

Leave a Comment