s:
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. When 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 