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.

Read more: Codeproject

Posted via email from .NET Info