Advanced Configuration Scenarios

The Enterprise Library standalone configuration console and the Visual Studio integrated configuration editor allow you to satisfy a range of advanced configuration scenarios based on external configuration sources such as disk files. For example, you can:

  • Read configuration information from a wide range of sources.
  • Enforce common configuration settings across multiple applications.
  • Share configuration settings between applications.
  • Specify a core set of configuration settings that applications can inherit.
  • Merge configuration settings that are stored in a shared location.
  • Create different configurations for different deployment environments.

The default and simplest scenario for configuring Enterprise Library is to configure your application using the configuration tool without adding a Configuration Sources section or any configuration sources. This is the approach described in Using the Configuration Tools.

When you use the configuration tools without specifying a configuration source, they default to using the System Configuration Source to create a single configuration file that contains the entire configuration for the application. Your application will expect this to be named App.config file (which is copied to [exe-name].config when you compile your application) or Web.config (depending on the technology you are using), and will read it automatically.

You can select Add Configuration Settings on the Blocks menu to display the section that contains the default System Configuration Source. If you click the chevron arrow to the right of the Configuration Sources title to open the section properties pane you can see that the System Configuration Source is also, by default, specified as the Selected Source—the configuration source to which the configuration generated by the tool will be written. When an application that uses Enterprise Library reads the configuration, it uses the settings specified for the selected source.

By adding additional configuration sources, you can implement more advanced configuration scenarios. The following sections describe the scenarios that you can implement using the configuration tools:

You can also change the contents of a configuration file programmatically, which is useful when working with shared configuration stored as disk files. For more information, see Updating Shared Configuration Settings Programmatically. For links to related topics and more details of how the configuration system works, see More Information at the end of this topic.

In this scenario, you want to store your configuration in a file or other type of store, instead of in the application's App.config or Web.config file. You can load the configuration information from a different file that follows the standard .NET configuration format by using a built-in configuration source provided with Enterprise Library. You can also use the example SQL Configuration Source available from the Enterprise Library Contrib Web site to load configuration information from a database, or create a custom configuration source.


For more detailed information on implementing this scenario, see Using a Non-default Configuration Store.

In this scenario, you want to share configuration settings between multiple applications or application layers that run in different locations, such as on different computers. To achieve this, you simply implement the same configuration as described in the previous scenario, locating the configuration file or store in a central location. Then specify this file or configuration store in the settings for the configuration source (such as the built-in file-based configuration source) for each application.


For more detailed information about how to specify different configuration sources for an application, see Using a Non-default Configuration Store.

In this scenario, you not only want to share configuration settings between multiple applications or application layers that run on different computers (as in the previous scenario), but also be able to manage and enforce these configuration settings for this application or its layers on all machines within the same Active Directory® domain.

You use the configuration tools to generate Group Policy templates containing the settings you want to broadcast and enforce, and install these on your domain controller(s). The settings replicate to all domain members. You use a Manageable Configuration Source to read your configuration information from a local or a shared configuration file, but any settings also defined in Group Policy will override the local and shared settings.


For more detailed information on implementing this scenario, see Using Group Policy with Enterprise Library.

In this scenario, you have multiple applications or application layers that must use the same shared configuration for some application blocks (or for some sections of the configuration such as instrumentation settings). Effectively, you want to be able to redirect Enterprise Library to some shared configuration sections, rather than using a complete shared configuration.

For example, you may want to specify the settings for the Logging Application Block and the Validation Application Block and share these settings between several applications, while allowing each application to use its own local settings for the Exception Handling Application Block and the Cryptography Application Block. You achieve this by redirecting specific configuration sections to matching sections of a configuration stored in a shared location. Notice that, in this scenario, local settings for redirected sections are ignored and the shared settings are used.


The XML content shown in the figure is only a logical representation of the actual content of a configuration file. For more detailed information on implementing this scenario, see Sharing Configuration Sections across Multiple Applications.

In this scenario you have a number of applications or application layers that use the same configuration structure and you want to inherit that structure but be able to modify or add individual configuration settings by defining them in your local configuration file. You can specify a configuration that inherits settings from a parent configuration source in a shared location, and optionally define local settings that override inherited shared settings.

For example, you can configure additional providers for an application block whose base configuration is defined in the parent configuration. Notice that, in this scenario, local settings override the shared settings.


The XML content shown in the figure is only a logical representation of the actual content of a configuration file. For more detailed information on implementing this scenario, see Applying a Common Configuration Structure for Applications.

In this scenario, you want to be able to define different configuration settings for the same application that will be appropriate when it is deployed to different environments, such as a development and a test environment. In most cases the differences are minor, and usually involve settings such as database connection strings or the use of a different provider for a block. Enterprise Library implements this capability using a feature called environmental overrides.

The principle is that you specify override values for settings that are different in two or more environments, and the differences are saved as separate delta configuration files. The administrator then applies these differences to the main configuration file when the application is deployed in each environment.


For more information on environmental overrides see Configuring a Deployment Environment.

You can modify any configuration stored in a standard .NET configuration format disk file programmatically by opening it using an instance of the FileConfigurationSource class, which reads the configuration data from the file and returns the data as ConfigurationSection objects. You can then write to this configuration source using code, and update the configuration. You can also open a configuration using an instance of the SystemConfigurationSource class.

When a configuration file changes, an external change event is generated. This prompts a refresh, which entails disposing of the open source files and recreating them. Changes are then reflected in the composed configuration source because the underlying code responds to the generated change event.

You can directly construct configuration source objects such as a FileConfigurationSource and specify a configuration file it will use, as shown in the following code.

FileConfigurationSource fileSource = new FileConfigurationSource(@"ProductApplication.config");