n the author has set it all up correctly, the developer using the library can add something like this to the app.config file:
<configuration> <configSections> <sectionGroup name="pageAppearanceGroup"> <section name="pageAppearance" type="Samples.AspNet.PageAppearanceSection" allowLocation="true" allowDefinition="Everywhere" /> </sectionGroup> </configSections> ... <pageAppearanceGroup> <pageAppearance remoteOnly="true"> <font name="TimesNewRoman" size="18"/> <color background="000000" foreground="FFFFFF"/> </pageAppearance> </pageAppearanceGroup> </configuration>
This is taken from the .NET docs, and even though it concerns ASP.NET, the same mechanism is used in classic desktop apps.
As you can see in the above example, the developer using the library
- first defines a new sectionGroup under the configSections tag
- then defines a section under that, pointing to the correct type that will handle the config section
- and finally provides the configuration details.
You can see that the pageAppearance is more complex than the simple AppSettings or Settings sections can handle.
As I said, this is beyond the purpose of this article, but I encourage you to check out the documentation I linked to above.
So far, we’ve only covered application settings. But we can consider connection strings as a sort of application setting too.
But the app.config file can contain more than that. Remember how a default app.config contained this:
This is where we define which .NET runtime(s) the application supports. You could change this if your application needs to run on other (higher or lower) runtimes.
The assemblyBinding tag is another tag you will encounter easily. In short, it allows you to point to a certain version of an assembly, even when a different version is required. Again, this is out of the scope of this article, but the documentation should help you further.
Another example is the system.serviceModel tag, which is the place to configure any connections to WCF services.
What Happens When We Compile This?
Good, by now you know what the app.config is for and how to use it. Now you might be wondering what happens behind the scenes. Well, when you compile your application, the compiler actually copies the app.config file to the output folder, but gives it another name:
When you start your application (ConsoleApp1.exe in our example), the matching config file will be loaded too.
It is possible to change this file while the application is running, but you will need to restart the application for the changes to take effect. Luckily, there are ways around this:
- A call to ConfigurationManager.RefreshSection(“…”) will reload the given section
- For applicationSettings, you will need to call Properties.Settings.Default.Reload();
Keep in mind that a new compilation or deployment can overwrite the changed values. So it’s better to make the changes in your source code (which is under source control, right?) and redeploy.
You should consider not putting confidential information in your config files. Things like passwords and API keys should be kept out of the app.config file. In an age where more and more code is made open source, you could risk exposing your secrets to the outside world. Even if your repository is private, it’s a best practice to put the secrets elsewhere. First, if you find it normal to do so, you won’t do it when you’re working on a public and open source project. But second, you never know when your private repository may become public, on purpose or by accident.
You can easily solve this by putting your secrets in separate files:
See how both the appSettings and the connectionStrings point to another file? Also note that we can combine an external file with appSettings, but for connectionStrings we need to choose.
If we make sure we don’t put these files under source control, they can remain absolutely private. Another thing to remember is to tell the compiler to copy these files to the output directory:
After that, you can use the appSettings and connectionStrings in your code like you did before.
A Final Tip
I want to 