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
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
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.
, 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
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
MSDN Web Site.
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,
- 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
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:
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)