Shared Application Settings in machine.config

Background

Application behavior frequently depends on exogenous parameters, such as a service URI or file paths, that are supplied by a developer or administrator. These inputs must be amenable to quick change without the need to refactor or recompile. A common answer to this requirement is to place such inputs in a configuration file: app.config for Windows applications or web.config for web applications. When settings are stored in an xml file, an administrator can easily edit them as needed.

This solution works well for a single application. .NET architecture also provides a way for multiple applications to access shared settings. As a simple example of when this may be desirable, suppose you have some functionality that needs to be exposed via a command-line interface, a GUI and a web app. Since only the interfaces are different but the functionality is the same, there is a good case to pool the settings into one place.

When the applications are on the same machine, their shared settings can be stored in the machine.config file. As you probably already know, you can add an <appSettings> element to a configuration file to contain custom data that your applications need. However, all data in appSettings is stored as strings and is exposed by the framework as a NameValueCollection, which is suboptimal for a number of reasons. In the next sections, I demonstrate a better solution.

Solution Overview

.NET already has a good alternative to appSettings, and it has a similar name: Application Settings. In contrast to appSettings, application settings are exposed as class properties, which permits them to be strongly typed, easily refactored and used in bindings. However, by default application settings are saved to app.config instead of machine.config and are accessible only within the assembly.

The solution is to move the settings out of app.config into machine.config and make the class that exposes them visible outside the assembly. Multiple applications can then access these settings by simply referencing the assembly.

Step-by-Step Guide

1. Create a new class library

For this example, I started with an empty Visual Studio solution and created a new class library project, which I named Netrudder, to serve as a base reference for projects in the same namespace.

2. Add settings

Add a new Settings template to the project. I named mine NetrudderSettings.
Open the new .settings file. The Settings Designer comes up.
Add your settings. Make sure to assign correct Type, and to change scope from User to Application.
Change Access Modifier to Public. This affects the visibility of the class whose properties map to the settings. It was created for us alongside the .settings file.
Save the project.

Read more: Codeproject

Posted via email from .NET Info