When you create a (non-web) .NET Framework application in Visual Studio, an app.config file is added to your project. When you create a class library or a .NET Core project, such a file is not included, although it can be done afterward.
What Is It?
The app.config file is an XML file whose goal it is to contain any variable configuration of your application. It is a central place to put:
- Connection strings to databases
- Connection details to external services
- Application settings
- Other details on how the application should be run and/or hosted
What Does It Look Like?
You can start typing under the <configuration> section and Visual Studio’s Intellisense will provide you with the possible options:
The most well-known sections are “appSettings” and the “connectionStrings”.
AppSettings provide an easy way to access string values, based on a certain key. Take these appSettings for example:
We can access this value by using this piece of code:
As a side note: you will need to import the System.Configuration namespace too, by adding “using System.Configuration” at the top of your file.
A possible problem with AppSettings is that we will get back a string. Yet in the above example, we’re clearly working with an integer. We will have to parse the value for it to be more meaningful. Another issue is that there is no compile-time checking that we entered the correct key, as it is just a string.
If your needs are simple, you could be fine with this. If things start to get a little more complicated, you might want to look into “Settings”, which I’ll cover later.
The connectionStrings section is the place to put your connection strings to any databases you want to access. This is a simple example:
Notice how there is also a “providerName”. This tells ORM libraries like Entity Framework which provider they should be using. The provider will differ depending on the database you’re trying to access (e.g. SQL Server, PostgreSQL, MariaDB, etc.).
If you need to access the connection string directly, you can use code like this:
Remember how the AppSettings only provided us with string values? The Settings system was introduced in .NET 2.0 to improve this. To use this, double click the properties of your project:
Then go to the settings tab. In the beginning, your project will not yet have a default settings file, so click on the link to create one. You’ll see a nice UI where you can define your settings, their values, scopes, and types:
I’ve added our “pollInterval” in these settings, and now I can access it like this:
The nice thing is that we have compile-time checking now, and we’re sure the “pollInterval” variable is an integer.
The Settings system has now created two new files under the Properties folder: Settings.Designer.cs and Settings.settings. You do not need to look into these files, and it’s best not to change them manually. They are automatically generated, so any changes will be overwritten anyway.
The result of these two files is a class containing the settings as properties. By the way, you can change the access (public or internal) by using the dropdown in the Settings tab of the project properties.
Working with the Settings system will also alter your app.config. In the above example, our app.config now includes this:
For more on the .NET settings system and the difference in scopes, check out the MSDN documentation.
Custom Configuration Sections
There is a next step in app.config possibilities: custom configuration sections. These merit a separate article, so I will only cover them here shortly.
As I mentioned at the beginning of this article, a class library doesn’t contain an app.config file. But sometimes, the author of a class library might want to allow other developers to configure certain parts of the library in the host’s app.config file.
One option would be for the author to document the necessary AppSettings. But the AppSettings have the disadvantages I’ve already mentioned, and they don’t allow for any deeper hierarchy.
Custom configuration sections give the class library author the solution to this. Whe