About the January 2006 Release

About the Enterprise Library – January 2006 Release

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

The latest Enterprise Library information can be found at the Enterprise Library site.

The Enterprise Library for .NET Framework 2.0 – January 2006 release has been redesigned and differs from earlier releases of the Enterprise Library in a number of ways. The primary change is that the Enterprise Library now uses the functionality of the .NET Framework 2.0. For example, configuration is now based on the .NET Framework System.Configuration namespace. The Logging Application Block uses the System.Diagnostics namespace. However, most of the changes to the application blocks are internal. In general, the public APIs are the same as they were in the earlier release. Any differences in the APIs are discussed in the documentation for the particular application blocks.

The next sections highlight the most significant changes between the January 2006 release and earlier releases.

Changes That Affect All Application Blocks

The changes to the Enterprise Library that affect all the application blocks are the following:

  • The Configuration Application Block, which was included in previous releases of Enterprise Library, no longer exists. Most of the configuration functionality supported by the application block is now provided by the System.Configuration namespace in .NET Framework 2.0. All Enterprise Library application blocks now use this functionality. The Enterprise Library Core still includes some helper classes for configuration, as well as the configuration design-time components and the Enterprise Library Configuration Console.
  • As with earlier releases, all Enterprise Library application blocks are instrumented with performance counters, Windows Management Instrumentation (WMI), and event logs. In Enterprise Library for .NET Framework 2.0, the instrumentation subsystem has been improved. You can now use configuration to control which types of instrumentation are enabled. By default, all instrumentation is disabled, and you can use xcopy to deploy the application blocks in low-rights environments such as ASP.NET.
  • The Enterprise Library includes a new subsystem named ObjectBuilder. It is located in the Microsoft.Practices.ObjectBuilder namespace. The ObjectBuilder subsystem performs all the repetitive and necessary tasks for creating object instances, while still providing a high level of flexibility. Enterprise Library uses the ObjectBuilder subsystem for tasks such as injecting configuration data into application block classes and for connecting instrumentation classes to application blocks. The use of the ObjectBuilder subsystem also makes it much easier to use the application blocks with or without configuration files. However, you do not have to understand the ObjectBuilder subsystem to use Enterprise Library.

Changes to Individual Application Blocks

The significant changes to the individual application blocks are described in the following sections. They discuss changes to the Data Access Application Block, the Logging Application Block, and the Security Application Block.

Cryptography Application Block

The application block now stores each key in a separate file that you name using the Enterprise Library Configuration Console. The Data Protection API (DPAPI) encrypts the key in the file.

Data Access Application Block

This release of the Enterprise Library Data Access Application Block includes the following changes:

  • The Data Access Application Block still makes it easy to manage connection strings in configuration, but this new release also makes it much simpler to use connection strings that are managed in other ways. For example, you can dynamically create a connection string based on business logic and use this connection string to create instances of Database classes.
  • The Data Access Application Block now uses the new ADO.NET <connectionStrings> configuration section. This allows connection strings to be shared between the application block and other .NET classes that use this section.
  • You can now use the Data Access Application Block with any ADO.NET 2.0 managed provider by using the GenericDatabase class, even if there is no Enterprise Library Database-derived class designed specifically for that database type. You can still build Database-derived classes for specific database types to provide increased functionality (such as parameter discovery) and transparency between different database implementations. This release of the application block includes Database-derived classes for Microsoft SQL Server and Oracle. You can use the GenericDatabase class to access OLE-DB and ODBC databases.

Logging Application Block

This release of the Enterprise Library Logging Application Block includes the following changes:

  • The Logging Application Block has been redesigned to take advantage of classes in the System.Diagnostics namespace, such as the TraceListener class and the CorrelationManager class. Most notably, the log sinks in the earlier releases of the application block have been replaced by trace listeners. The Logging Application Block ships with a full set of trace listeners. You can also use existing .NET or third-party trace listeners with the application block.
  • Information that is logged by using the application block is represented in an instance of a LogEntry class. In earlier releases of the application block, each LogEntry instance could only be in a single category. The new release supports a single LogEntry instance being in multiple categories. Because categories are used to filter and route LogEntry instances to different trace listeners, the ability to specify multiple categories significantly improves the flexibility of the application block.
  • The Logging Application Block uses implementations of the LogFilter class to prevent certain events from being logged, in accordance with rules specified in configuration. Examples of these rules are minimum priorities or specific categories. These filters are now extensible and pluggable, meaning developers can program their own filters. In addition, it is now possible to query filters from the application block's API so that developers can avoid costly data gathering when a LogEntry instance is going to be filtered out.
  • The architecture of the application block has been simplified by eliminating the concept of distribution strategies. The functionality provided by distribution strategies, such as the use of Message Queuing for centralized and asynchronous logging, is now supported through trace listeners.

Security Application Block

Much of the functionality from the earlier release of the Security Application Block has been removed because new features in the .NET Framework 2.0 provide equivalent functionality. Specifically, the factories, interfaces, and providers for authentication and roles and profiles have been removed. Equivalent functionality is provided by the new .NET Framework System.Web.Security.Membership class and System.Web.Profile namespace. The documentation provides migration guidance for existing users of the Security Application Block who want to use these new classes. The new Security Application Block still includes the factories, interfaces, and providers for authorization and security caching.

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

The latest Enterprise Library information can be found at the Enterprise Library site.
Show:
© 2016 Microsoft