How the CLR handles Config-Settings
I am very confused about how Config-Files are handled: there is basically one Config for the app that is loaded somewhere and can be accessed quite easily. But we have DLLs that dynamically call reflection, and even they can get data from Config. How is this possible?
Or even more: if the DLLs are on a different server / location, how can they get the data they need?
I know how to use Config-Files with Transform, etc., but I don't find good articles where information is stored in memory and how the data propagation magic happens.
source to share
Start by Configuring Applications Using Configuration Files . Important concepts:
- The .NET runtime is configured globally for each machine using the Machine.config file located in the [runtime path] \ Config \ directory.
- Machine configuration can be overwritten for each application.
- Application configuration files also contain application-specific settings.
The configuration details depend on how you host your application. ASP.NET applications and their relatives (MVC, Web API, etc.) have a complex configuration hierarchy. After Machine.config, there is IIS ApplicationHost.config, a possible config file in the root of the website, a config for your website, and then additional configuration for each subdirectory in your application. For more information, see ASP.NET Configuration File Hierarchy and Inheritance .
Standalone applications such as form applications, console applications, and Windows services have a single configuration file with the naming convention [application name] .exe.config.
In addition, the runtime makes all configuration available to loaded assemblies with the static ConfigurationManager class . There is no real magic. The ConfigurationManager is just an abstract abstraction over the final merged configuration state (most local customization wins).
If your configuration data is more complex than keys and values, consider creating a custom configuration section in .NET .
There is no out of the box support for reading configuration files on external servers / locations. However, you can implement ProtectedConfigurationProvider . Typically, this provider is used to encrypt a configuration other than the default. With a little creativity, it can be hacked so that we can store configuration data anywhere. See Simple Trick to Centralize Your .NET Configuration for details .
source to share