This project is read-only.

Microsoft Enterprise Library 5.0 Beta1 Change Log

Enterprise Library 5.0 – February 2010 is a new release of the Microsoft patterns & practices Enterprise Library. One of the major changes is the implementation of full dependency injection capabilities for instantiating objects, which makes creation of Enterprise Library objects consistent across the entire library. Enterprise Library now offers better support for many dependency injection containers, including the Unity Dependency Injection and Interception that is the default mechanism for creating objects.
This release also includes additions in functionality to several of the existing application blocks.

The following sections discuss these and other changes:

Integration of Unity and Object Builder

In this release of Enterprise Library, the underlying technique for creating objects uses a single dependency injection container; with Unity as the default container. You can use Unity to generate instances of Enterprise Library objects and inject them into other objects. Enterprise Library provides a standard interface for obtaining instances of objects such as a SqlDatabase or a CacheManager, defined in the Enterprise Library configuration, from the Unity container (or from an alternative container providing that you have suitable configuration plug-ins for that container). In addition, "injection-friendly" instance façades are now available in addition to the Enterprise Library static façades, which cannot be used with injection.

Object Builder, the low-level dependency injection mechanism, has also been subsumed into Unity in this release. You no longer need to reference the Object Builder assembly in your projects, or distribute it with your applications.

Note: Support for dependency injection containers requires a reference to the Microsoft.Practices.ServiceLocation assembly, which is included with Enterprise library. For more information, see CommonServiceLocator.

For more information about Unity, see Unity Dependency Injection and Interception in the included CHM file.

For more information on interception, see Using Interception and Policy Injection in the included CHM file.

For more information about the integration of Unity and Enterprise Library, see The Dependency Injection Model in the included CHM file.

For more information about writing application code that takes advantage of Unity integration, see Using Enterprise Library in Applications in the included CHM file.

Note: This release of Enterprise Library fully encompasses the move to using dependency injection techniques through Unity to instantiate objects. The examples and QuickStarts now all use the Unity-based approach. However, the previous techniques that used the static factory classes and the static façades are still supported in this release. For more information about the previous non-Unity approach to instantiating objects, see the online documentation for Enterprise Library 4.1, available on the MSDN Web Site.

Breaking Changes

This section lists the breaking changes in Enterprise Library 5.0 and Unity 2.0.
  • WMI support has been removed from Enterprise Library except for the WMI TraceListener in the Logging block, this includes WMI events and WMI instrumentation. WMI events are not instrumented in Enterprise Library 5.0.
  • Enterprise Library now throws an ActivationException for configuration errors. Previously, the exception raised was System.Configuration.ConfigurationErrorException. This includes errors such as trying to resolve an instance provider that does not have configuration information.
  • Where Enterprise Library in previous versions threw a BuildFailedException upon failure to retrieve the default block instance, now ActivationException is thrown for all application blocks.
  • ObjectBuilder2 DLL is no longer a separate DLL. The code is now completely contained in the Unity assembly and there is no need to reference ObjectBuilder2 anymore in your projects.

Changes That Affect All Application Blocks

The following changes to Enterprise Library affect all the application blocks:
  • Major architectural revisions in Enterprise Library to use the dependency injection mechanism. All of the application blocks and the core system in Enterprise Library now use the dependency injection mechanism, with Unity as the default dependency injection mechanism, to create and manage the lifetime of individual Enterprise Library objects such as Database, LogWriter, CacheManager, and others. Enterprise Library no longer uses the static facades and static classes that were used in previous versions. However, these facades and classes are still included in Enterprise Library for backwards compatibility with existing application code, and you can continue to use the previous approach to creating Enterprise Library objects. For more information, see Using Enterprise Library in Applications in the included CHM file.
  • Container independence accomplished through implementation of IServiceLocator interface provided by the Common Service Locator project. For more information see the "Initializing and Setting a Default Unity Container" section in Creating and Referencing Enterprise Library Objects in the included CHM file.
  • Simplified error messages during Resolve failures due to misconfigurations.
  • The configuration system now exposes a fluentinterface that you can use to create and populate configuration sources for individual objects and for entire applications. The fluent API makes it easier to generate configuration sources for a variety of scenarios, including environment-specific configuration that can ease deployment. For more information, see Using the Fluent Configuration API in the included CHM file.
  • The ConfigurationView classes have been removed from Enterprise Library.
  • Some configuration elements now have default values for their settings, which may differ from previous implicit defaults.
  • Enterprise Library now enables you to create a composite configuration for Enterprise Library by combining all or parts of multiple files. For more information see Using Multiple Configuration Files in the included CHM file.
  • Enterprise Library now enables you to store Enterprise Library configuration sections in different files. For more information see Redirecting Configuration Sections in the included CHM file.
  • Enterprise Library does not support XAML Browser Applications (XBAP).
  • WmiEnabled flag remains in the configuration for backward compatibility but it is ignored in Enterprise Library 5.0 and will be removed in future releases.
  • A-la carte Installer – You can now choose which individual blocks and configuration tools to install. Any libraries not installed initially can be installed later.
  • When using the Unity integration, in previous versions you had to add the core Enterprise Library container extension and an extension per block. Now only the core extension is needed, the rest of the blocks are supported automatically. The old extensions remain in the code solely for backwards compatibility. They now have no function.

Changes to the Configuration Tool

The following changes have been made to this version of the Configuration tools:
  • New Enterprise Library Configuration Tool with new GUI and metadata-driven extensibility model. See the Using the Configuration Tools topic in the included CHM file.
  • Support for wizards in the Enterprise Library configuration tool.
  • New type selector. See the Using the Configuration Tools topic.
  • Unity configuration added to the Enterprise Library configuration tool.
  • Application configuration settings, AppSettings, have a new option to require permission to change settings, RequirePermission.
  • The Enterprise Library installer automatically detects the version of Visual Studio installed enabling you to choose to integrate the configuration tool into the installation of Visual Studio 2008, Visual Studio 2010, or both. Side-by-side installation of the integrated configuration tool with Enterprise Library 4.1 is supported.

Changes to the Caching Application Block

The following changes have been made to this version of the Caching Application Block:
  • Cache scavenging has been completely rewritten for performance optimization.

Changes to the Cryptography Application Block

The following change has been made to this version of the Cryptography Application Block:
  • In previous versions of Enterprise Library the Cryptography block threw a BuildFailedException, now ActivationException is thrown.

Changes to the Data Access Application Block

The following changes have been made to this version of the Data Access Application Block:
  • The block now contains asynchronous versions of the ExecuteReader, ExecuteXmlReader, ExecuteScalar, and ExecuteNonQuery methods. These use the familiar asynchronous approach of a Begin and End method for each one. For more details, see Using the Asynchronous Data Access Methods in the included CHM file.
  • The block contains a series of new methods and classes that allow you to extract data as sequences of objects, in a format suitable for client-side querying using techniques such as LINQ. For more details, see Returning Data as Objects for Client Side Querying in the included CHM file.
  • The existing ExecuteReader method and the new BeginExecuteReader method do not accept a CommandBehavior parameter. By default, the methods will automatically set the CommandBehavior property on the underlying reader to CloseConnection unless you specify a transaction when you call the method. If you do specify a transaction, the methods do not set the CommandBehavior property.

Changes to the Exception Handling Application Block

The following changes have been made to this version of the Exception Handling Application Block:
  • The Logging Exception Handler reuses the LogWriter and Trace Listeners from the Logging application block. This was not the default behavior in previous versions, though it could be achieved by settings the UseDefaultLogWriter property of the LoggingExceptionHandlerData class. This property still exists but is now obsolete.
  • Added ability to return a value from ExceptionManager.Process.

Changes to the Logging Application Block

The following changes have been made to this version of the Logging Application Block:
  • The Rolling Flat File Trace Listener now has an additional property that enables you to specify the number of log files to keep, and can automatically purge older files based on this setting. For more details, see Trace Listener Properties in the included CHM file.
  • The Text Formatter class now supports additional template formatting tokens that provide improved performance when accessing local environment variables such as the machine and process names, and when formatting dates and times. The default template now uses the new local versions of the tokens. This offers additional performance improvements of the Logging Block. If, however, you require the previous behavior (such as when using the log distributor) you must update the default template for any new formatters that you add to the block. For more details, see Configuring Formatters in the included CHM file.
  • In previous releases, the XML Trace Listener did not generate any instrumentation information. In this release, the XML Trace Listener generates the same events and performance counter updates as the other trace listeners. For more details, see Deployment and Operations in the included CHM file.
  • Authentication has been added to EmailTraceListener. For more details see the "Trace Listeners" section in the Design of the Logging Application Block topic in the included CHM file.
  • The primary interface for creating log entries in this release is the LogWriter class, which can be injected into your own objects using dependency injection. However, you can still use the Logger approach and the previous static façade if required.
  • The LogWriter class is now abstract. If your code previously created LogWriter objects directly, you must now either go through the container or use the LogWriterImpl class instead.
  • The parameters of the constructor of the DistributorEventLogger class now define an EventSource object, which better illustrates how the class is used. The EventLogName property has been removed.

Changes to the Policy Injection Application Block

The following changes have been made to this version of the Policy Injection Application Block:
  • The interception mechanism has been separated into the Unity Application Block. As a result, the current Policy Injection Application Block is now comprised only of the call handlers and associated mechanism for using the Unity interception mechanism to add the Enterprise Library features to a policy. For more details, see The Policy Injection Application Block and Using Interception and Policy Injection in the included CHM file.
  • You can no longer specify the configuration source when you call Create or Wrap methods of the static PolicyInjection façade. Instead, you must resolve an instance of the PolicyInjector instance façade and use the corresponding method in this façade.
  • Providers are resolved from the same container from which the handlers themselves are resolved. This means that you cannot store configuration for the block in a separate file when using the default configuration for Enterprise Library.
  • Call handlers are now created per object. They are no longer shared across all methods that use it. Handlers can now safely store the local state.
  • Policy injection is now just one implementation of many possible interception implementations.

Changes to the Security Application Block

The following change has been made to this version of the Security Application Block:
  • None.

Changes to the Validation Application Block

The following changes have been made to this version of the Validation Application Block:
  • The ValidatorWrapper class has been removed. This was an internal class mainly used to add instrumentation to validators. It is replaced by the GenericValidatorWrapper<T> class which can wrap any type of validator.
  • Validation Application Block WPF integration work is completed. Now you can use VAB validators when you define controls in WPF.
  • DataErrorInfoHelper class added for implementing the System.ComponentModel.IDataErrorInfo interface using the Validation Application Block.
  • Decorating LINQ objects with Validation attributes.
  • Support for .NET framework System.ComponentModel.DataAnnotations data annotation attributes have been added to the VAB and the VAB validators can be used where you would use a DataAnnotation attribute. For more information see Using Data Annotation Attributes in the included CHM file.
  • Added a validation specific Unity extension to allow using Unity to resolve Validators. Added configuration support for validation source and ruleset from the Unity configuration file.
  • Added inheritance-aware object validator:
    • Updated the static Validation facade to validate based on the validation target's type.
    • Updated the IValidatorDescriptor to get a ValidatorFactory when building the represented validator.
    • Updated the ObjectValidator and ObjectCollectionValidator to have an "inheritance aware" flag, with false as the default value, and to be configured with ValidatorFactory. Should the validator be inheritance aware, the nested objects would be validated with a freshly built validator for the nested object's type; otherwise, a validator for the static type would be used. Nested object's validators are built with the ValidatorFactory so rules for the outer and the inner validators are retrieved from the same sources.

Note: When specifying the object collection validator (either through attributes or configuration), you would either specify the target type or the "validate actual type" to true.

Changes to the Unity Application Block (Unity 2.0)

Last edited Feb 25, 2010 at 5:31 AM by gmelnik, version 14


wesnur Apr 30, 2010 at 8:37 AM 
It’s true that CAB in Microsoft Enterprise Library is very effective as for as the feature of adoptability is concern. But on the other side of the picture, it has some drawbacks as well. I am talking about the issues like Scalability and Reliability. Like ASP.NET apps frequently run in web farms for scalability reasons. A stand-alone cache is unaware of multiple servers and cache instances and is not synchronized. This leads to data integrity problems. Even Microsoft has realized this problem so they introduced Microsoft Velocity to overcome these problems. but personally I am a fan of NCache is a very good distributed caching product. here is some more info about NCache.