The Core

By far the biggest change between Enterprise Library for the .NET Framework 1.1 and Enterprise Library for the .NET Framework 2.0 is in the way configuration is handled. The Configuration Application Block has been deprecated because Enterprise Library now leverages the .NET Framework 2.0 new configuration mechanisms. Additionally, the architecture around instrumentation for all of the application blocks has been refined, and new capabilities that promote the use of dependency injection in Enterprise Library now exist. These assets exist in an enhanced, common assembly known as the Core. This section highlights the primary changes in Enterprise Library that account for the Core.

System.Configuration and the Configuration Runtime

The features provided by the System.Configuration namespace in the .NET Framework 2.0 provide much of the same functionality that the Enterprise Library Configuration Application Block for the .NET Framework 1.1 provides. For example, it provides support for writing and reading configuration information as strongly typed object graphs to and from configuration files. The intent for Enterprise Library has always been to complement the .NET Framework, not to provide solutions that diverge from those offered by the .NET Framework. Therefore, many of the benefits offered by exposing the Configuration Application Block as a separate block are no longer needed when using the .NET Framework 2.0. Thus, the Configuration Application Block was deprecated and combined with the utilities that are found in the Common namespace.

Instead of a full-blown application block, configuration helper classes have been added to the Common assembly to facilitate the use of working with the System.Configuration namespace. These helper classes provide support for functionality needed by Enterprise Library that does not exist in the System.Configuration namespace. One such need is the ability to provide configuration support that allows for polymorphism for the types of objects that can be created. For example, an application can be configured to use the Logging Application Block (note that the word Instrumentation has been dropped from the name of this block) to log information to both a database and the Windows Event Log. Both providers for these logging stores derive either directly or indirectly from the abstract base traceListener class. The configuration helper classes that exist in the Core of Enterprise Library allow the collection of Listeners to be configured as one group.

Another important need provided by the helper classes is the ability to read and write configuration data to data stores other than XML files. The .NET Framework 2.0 supports reading and writing configuration information to XML files, but without a lot of work, it is difficult to store configuration data in a different type of data store, like a database. In the latest release of Enterprise Library, the ConfigurationContext class has been refactored into the ConfigurationSource class in an effort to abstract away the need for developers to understand the intricacies needed to read or write configuration to a particular type of data store while also leveraging the .NET Framework configuration support (like declarative configuration serialization).

Wrappers exist over System.Configuration to write to the application domain configuration files (app.config or web.config) as well as external XML configuration files. Also, a SqlConfigurationSource is provided as a Quick Start that reads, writes, and monitors changes that occur with respect to configuration information stored in a Microsoft SQL Server database. Moreover, the factories that exist for every application block in Enterprise Library for the .NET Framework 2.0 accept a ConfigurationSource. Much like the ConfigurationContext in Enterprise Library for the .NET Framework 1.1, this can be used to programmatically set where configuration is read and written for a particular factory.

For example, in Listing C.1 a database provider is created from a DatabaseProviderFactory that is passed the name of a configuration file. Additionally, a much desired enhancement that was made in Enterprise Library for the .NET Framework 2.0 is the ability to create providers without the need to store any initialization information in a configuration source. That is, the provider can just be "newwed up."

Listing C.1. Creating a Database Provider by Programmatically Setting the Configuration File

[C#] FileConfigurationSource fileSource =            new FileConfigurationSource("foo.config"); DatabaseProviderFactory factory =            new DatabaseProviderFactory(fileSource); Database db = factory.Create("PortalDatabase"); [Visual Basic] Dim fileSource As FileConfigurationSource = _            New FileConfigurationSource("foo.config") Dim factory As DatabaseProviderFactory = _            New DatabaseProviderFactory(fileSource) Dim db As Database = factory.Create("PortalDatabase")

Change notifications still occur when changes occur in configuration data; however, by default only the Logging Application Block currently registers to receive change notification events. Handlers are exposed if you want to receive change notification for the other application blocks or in your own code.

Instrumentation

In Enterprise Library for the .NET Framework 1.1, instrumentation is turned on for every application block by default. Many of the common problems faced when deploying an application that uses this version of Enterprise Library is due to this fact. If the performance counters, Windows Management Instrumentation (WMI), and event logs are not installed properly and by a user with the necessary credentials (typically an administrator for the machine), then errors will occur when an application block tries to send instrumentation information. To resolve this issue, the counters and schemas need to either be installed properly (by running the InstallServices batch file or the InstallInstrumentation command file), or a version of Enterprise Library needs to be compiled that has instrumentation turned off.

In Enterprise Library for the .NET Framework 2.0, instrumentation is turned off by default for all application blocks, so you don't need to install counters and schemas if you don't intend to use them. In such a scenario, the application blocks can be deployed by simply copying them to the test or production server. This, however, leaves the application blocks without the ability to send instrumentation information, and instrumenting an application is considered a best practice. But rather than requiring the recompilation of the application block assemblies with different compiler directives, as is the case for the previous versions of Enterprise Library, this version made instrumentation configurable. For example, if it makes sense for an application to enable event logging and increment performance counters but there is no need to enable WMI, you can do this with the Enterprise Library Configuration Tool. Figure C.1 shows how to configure instrumentation for Enterprise Library for the .NET Framework 2.0.

Figure C.1. Setting Configuration for Instrumentation

However, what is even more interesting is how the instrumentation subsystem has been improved throughout Enterprise Library. It is based on a publish/subscribe design where the publisher of an instrumentation event is decoupled from Listeners for those instrumentation events. In the new version, an application block may contain InstrumentationProviders that are defined on an event (for example, removing an item from the cache, making a database call, etc.) in the block and specify the name of the event being fired. An InstrumentationListener in the block can be configured to handle the instrumentation event. In the Listener, an InstrumentationConsumer method can be defined that contains the logic for what to do when the event is handled, like incrementing to a performance counter or writing to the Windows Event Log.

ObjectBuilder^[2]

^[2] 2 A lot of information about ObjectBuilder can be found at the ObjectBuilder workspace on Gotdotnet.com (http://practices.gotdotnet.com/projects/objectbuilder), in Brian Button's blog (www.agileprogrammer.com/oneagilecoder), Peter Provost's blog (http://peterprovost.org), and Brad Wilson's blog (www.agileprogrammer.com/dotnetguy).

A lot of the feedback on Enterprise Library for the .NET Framework 1.1 was that extending the blocks was difficult because so much needed to be known about the configuration runtime. In an effort to remedy this, the latest release of Enterprise Library includes a new subsystem named ObjectBuilder that is a reusable, configurable dependency injection and object creation pipeline. In fact, it is so reusable that it was not actually created by the Enterprise Library team. ObjectBuilder was created by the team that developed the Composite UI Application Block (also known as CAB) to provide dependency injection capabilities. Because Enterprise Library's configuration needs were fairly similar to the Composite UI Application Block's needs, Enterprise Library adopted ObjectBuilder and it is now a shared asset between both teams. The idea behind ObjectBuilder is to provide capabilities for an easy and flexible way to create new providers or application blocks and that do not require an intimate knowledge of how the configuration runtime works.

The ObjectBuilder subsystem performs all the repetitive and necessary tasks for creating and disposing object instances. It provides the ability to read configuration data and inject that data to create new providers. It also has the ability to determine whether instrumentation should be used prior to instantiating the new object.

ObjectBuilder can also be used outside of Enterprise Library and can be customized to perform actions other than these. ObjectBuilder consists of a pipeline of different phases in the object creation process. These phases include PreCreation, Creation, Initialization, and PostInitialization. Strategies are registered with ObjectBuilder that determine the actions that should occur for each phase. Each Strategy can collect information at runtime and use it to help create and initialize an object. As mentioned earlier, for Enterprise Library that involves collecting configuration data, creating an object with that configuration data, and connecting it to instrumentation if it applies.

As I have shown throughout this book, every application block exposes instance factories that are used to create an instance of a specific provider for that block. That does not change for Enterprise Library for the .NET Framework 2.0. What has changed, however, is that these instance factories don't really do much anymore. In the latest release, they just define the type of provider that needs to get created and call through to ObjectBuilder to create it.

The Configuration Design-Time API

The Configuration design-time API has also been improved in Enterprise Library for the .NET Framework 2.0. As highlighted in Chapter 2 and shown throughout this book, creating a design-time experience for an application block or provider involves creating the configuration node, a ConfigurationDesignManager, and setting an assembly attribute for the ConfigurationDesignManager. All these actions are still needed; however, the design for ConfigurationDesignManager has been improved to make registering nodes and commands much more logical.

In Enterprise Library for the .NET Framework 1.1, a lot of code was needed both in the configuration nodes and in the ConfigurationDesignManager to register the nodes and commands. In the latest release, CommandRegistrars and NodeMapRegistrars can be created to accomplish this and are simply called from the Register method in the ConfigurationDesignManager. A lot of the responsibility and logic needed in the configuration nodes can be removed in the latest release and the nodes no longer even need to contain an OnSited method.