Talking about the use of config file

First, the Origin

Recently, the project started using C #, because the previous use of C + +, so the object-oriented thinking of knowledge is relatively comprehensive, but because it has not been complete, systematic. NET knowledge of the systematic learning, often by some in C # veteran eyes almost common sense of small knowledge points to trip.

Why do you say that, because I find information on the network, often most of the problems, are able to find more or less reference materials, but these small knowledge points are rarely able to find the right solution, there is only a question, not back, then this situation arises, there are only 2 kinds of explanations:
1, this aspect of the problem is difficult, difficult to no one can solve;
2, the problem is too simple, simple to slightly familiar with the people are not bothered to answer, the questioner also after some thinking, easy to find the answer. (I prefer this, hehe, so I also put these small knowledge, called: easy to ignore the details)

However, no matter whether the problem is simple, since I will be tripped, delay time, certainly someone will be the same delay, so I would like to put these details out, or have some meaning.

So, this series of articles began ...

Ii. Description of the problem

In addition to the normal config file, using ConfigurationManager loading, we may also encounter a situation like this:
1. Load the Xxx.exe.config file of the default Config file that is not the current application Yyy.exe, (for example: Yyy.exe.config not in the same directory or different file name)
2. Loading non-application xxx.config files;
3. When a function inside the class library Xxx.dll reads the default config file, it reads the Xxx.dll.config file in the Xxx.dll sibling directory instead of the default application configuration file for the Xxx.dll application Yyy.exe: yyy.exe.config;
None of the above three cases can be loaded directly using ConfigurationManager.

Third, the solution process

Let's start with the most basic, simplest, and most common config file loading to solve the above three questions:

Step1: Study the basics of config file loading

Config file is for the client application to save configuration information, in general, an application will only have one such file, before compiling, called App. config, each time using Visual Studio compilation, will copy to the application's build directory, And rename is: application name. config.
To read the information in the config file, you only need to use the relevant functions and properties of ConfigurationManager, so let's look at the next ConfigurationManager to see if we can find the information to solve the problem.
Open MSDN and find a way to:

Openexeconfiguration is overloaded. Opens the specified client configuration file as a configuration object.

OK, this is what you're looking for, because this method has an overloaded method:

Openexeconfiguration (String) opens the specified client configuration file as a configuration object.

Step2: Load non-current Application default Config file

So, the solution to the first question seems, should, might have been found, as described on MSDN, if we pass the path of the xxx.exe.config you want to open as a parameter, the code is as follows:

Configuration config = configurationmanager.openexeconfiguration ("C:\\xxx.exe.config");
Dllinfo dllinfo = config. GetSection ("Dllinfo") as Dllinfo;
Console.WriteLine (Dllinfo);

However, things are not so smooth, so it is impossible to open the Xxx.exe.config file, after debugging, found that: Config property filepath value is: "C:\\xxx.exe.config.config", the program itself after the parameters of the input added " . config "as the path to the config file to open, which is obviously not the same as what we saw earlier on MSDN, needless to say, we were fooled by Microsoft. The parameter to pass in here should not be the path to the config to be opened, but the path to the application that the config file corresponds to, that is, the code above should read:

Configuration config = configurationmanager.openexeconfiguration ("C:\\xxx.exe"); The path to the application is written
Dllinfo dllinfo = config. GetSection ("Dllinfo") as Dllinfo;
Console.WriteLine (Dllinfo);

Run again, hehe, or not, prompt error: "Error loading configuration file: Parameter" ExePath "is invalid. Parameter name: ExePath ". Apparently, we've been fooled. To pass in the application path (ExePath) Yes, But because we did not add the Xxx.exe file in the same directory as the Xxx.exe.config file, our incoming ExePath is actually invalid, so we can get a Xxx.exe file together in order to be able to load the xxx.exe.config.

OK, run, success.

Summary 1: The solution to the first problem is found:

with Configurationmanager.openexeconfiguration (string exepath), note 2 small details:
A: The change method needs to be passed in ExePath, not configpath;
B:exepath must be valid, so xxx.exe and xxx.exe.config should appear in pairs, indispensable.

Step3: Expand Step2 's victories and find a way to load xxx.config

Step2 has found a way to load xxx.exe.config, observing the name of Xxx.exe.config, found that if Xxx.exe as yyy, obviously xxx.exe.config = Yyy.config, that is to say: Xxx.exe.config is a special kind of xxx.config, he asked the config file filename The last 4 letters must be ". exe".

At this point, it is bold to speculate that using configurationmanager.openexeconfiguration (string exepath) should solve the problem.

Configuration config = configurationmanager.openexeconfiguration ("c:\\xxx"); Remember to have xxx file, otherwise this path is invalid.
Dllinfo dllinfo = config. GetSection ("Dllinfo") as Dllinfo;
Console.WriteLine (Dllinfo);

Run, HOHO, succeeded.

Summary 2: The second problem is the same as the solution to the first one.

Step4: Extending xxx.config to solve the problem 3

Continue to expand the outcome, or from the file name to find ideas, we want to load the xxx.dll.config, in fact, is a slightly special xxx.config, it is also possible to deal with STEP3 as well.

Use Openexeconfiguration (string exepath) to solve the problem three, in the DLL, when you encounter the need to read the config file information, discard the function or property using ConfigurationManager directly obtained, Instead, use Openexeconfiguration (string exepath) to load the config file as a corresponding function or property of a configuration object.

Summary 3: The third question can also be done according to the first question.

Iv. Additional Thinking

The information in the Yyy.exe.config file can be easily read through ConfigurationManager in the application Yyy.exe, but the Xxx.dll.cofig file generated is not automatically compiled in the class library using Configruationmanager read. Instead, the Yyy.exe.config file that references the class library's application Yyy.exe.

Is there any way to let the ConfigurationManager in the class library read his default Xxx.dll.config file?

In fact, it is possible, but this involves the concept of an application domain (AppDomain). NET applications are running within an application domain (AppDomain), and at the beginning of the program, an AppDomain is started by default, and viewing MSDN can see that the AppDomain has a property: Setupinformation, This property holds the config file path of the current domain; Unfortunately, this property is read-only, so we default the config file path of the AppDomain.

Therefore, if you want the class library to be able to use ConfigurationManager directly to read its own default Config file, you can only put the class library in a new AppDomain to execute, And when creating the AppDomain, specify his setupinformation as the default Config file path for the class library; The AppDomain has a method to create a new AppDomain: CreateDomain (String, Evidence, AppDomainSetup); Just take the property of the third parameter configurationfile just want the default Config file path of the class library.

Talking about the use of config file