This project is read-only.

Microsoft Enterprise Library 5.0 Beta2 Change Log

Enterprise Library 5.0 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 LogWriter, 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 Trace Listener in the Logging block. Enterprise Library no longer exposes its configuration through WMI, and the application blocks no longer raise WMI events. Only the WMI Trace Listener in the Logging block still raises WMI events.
  • Enterprise Library now throws an ActivationException for configuration errors. Previously, the exception raised was System.Configuration.ConfigurationErrorsException. 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 an ActivationException is thrown for all application blocks.
  • In previous versions of Enterprise Library, an ArgumentNullException was thrown if a null source was passed to the container in the call to the CreateDefaultContainer method. In this release, a NullReferenceException is thrown.
  • ObjectBuilder2 is no longer a separate assembly. The code is now completely contained in the Unity assembly and there is no need to reference ObjectBuilder2 dll in your projects.
  • If you fail to close the DbDataReader, you can cause random and hard to find errors in your code—particularly when you are operating under an implicit transaction created within a TransactionScope context. You must always ensure that your application closes the DbDataReader in a timely fashion, either by explicitly closing the reader with the DbDataReader.Close method or by forcing the disposal of the DbDataReader, which results in the Close method being called. Code that forces closure of a DbDataReader by terminating an enclosing TransactionScope may leak a connection or fail unpredictably.
  • The signature for the FileConfigurationSource.Save method has changed. The method now has two parameters instead of three.
  • You must use ValueValidatorAttribute as the base class for custom validators instead of ValidatorAttribute. If you derive a custom validator from ValidatorAttribute instead of ValueValidatorAttribute it may fail when used for validation of Data Annotations.
  • The Policy Injection Application Block call handlers have been moved from the PolicyInjection assembly to the corresponding assemblies of the application blocks to which they apply; with the exception of the Performance Counter call handler, which remains in the PolicyInjection assembly.
  • The CachingCallHandler in the Policy Injection Application Block has un-resolvable security vulnerabilities, and has been removed from the Policy Injection Application Block. If you still wish to use this call handler, you can obtain it from the patterns & practices: Enterprise Library Contrib Web site.

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, 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 incorrect configurations.
  • The configuration system now exposes a fluent interface 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).
  • The 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.
  • An improved installer allows you to choose the individual blocks and configuration tools to install. Any libraries not installed initially can be installed later.
  • When using 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 required, the individual blocks are automatically supported. The old extensions remain in the code solely for backwards compatibility. They now have no function.
  • In Enterprise Library 5.0, assembly resolution is performed only if the Enterprise Library 5.0 editor is opened in Visual Studio. This improves assembly load handler performance.

Changes to the Configuration Tools

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 Using the Configuration Tools topic in the included CHM file.
  • Support for wizards in the Enterprise Library configuration tool.
  • New type selector. See Using the Configuration Tools topic.
  • Unity configuration added to the Enterprise Library configuration tool.
  • The Configuration Tool configuration settings sections now have a new RequirePermission property that enables you to require permission to change configuration section settings at run time. The RequirePermission value indicates whether the associated configuration section requires access permissions. When RequirePermission is set to true, methods or properties that allow access to configuration section handlers are restricted by the trust level set for the Web application. For more information see RequirePermission on MSDN.
  • 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. Side-by-side installation of the integrated configuration tool with Enterprise Library 4.1 is supported.
  • The signature for the FileConfigurationSource.Save method has changed. The method now has two parameters instead of three.
  • The Enterprise Library 5.0 Configuration tool does not support Environmental Overrides for the PIAB Logging handler Categories. You cannot use the configuration tool at design time to customize the run time settings of your PIAB configuration for Logging handler Categories based on the environment.

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 changes have been made to this version of the Cryptography Application Block:
  • None.

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 the capability to return a value from ExceptionManager.Process method.

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 TextFormatter 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 moved into the Unity Application Block, and all except one of the call handlers has been moved to the associated application block. As a result, the current Policy Injection Application Block is now comprised only of legacy components for backwards compatibility. The five call handlers you can use, and their assemblies and namespaces are:
    • Authorization handler
      • Assembly: Microsoft.Practices.EnterpriseLibrary.Security.dll
      • Namespace: Microsoft.Practices.EnterpriseLibrary.Security.PolicyInjection
    • Exception Handling handler:
      • Assembly: Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.dll
      • Namespace: Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.PolicyInjection
    • Logging handler
      • Assembly: Microsoft.Practices.EnterpriseLibrary.Logging.dll
      • Namespace: Microsoft.Practices.EnterpriseLibrary.Logging.PolicyInjection
    • Validation handler
      • Assembly: Microsoft.Practices.EnterpriseLibrary.Validation.dll
      • Namespace: Microsoft.Practices.EnterpriseLibrary.Validation.PolicyInjection
    • Performance Counter handler
      • Assembly: Microsoft.Practices.EnterpriseLibrary.PolicyInjection.dll
      • Namespace: Microsoft.Practices.EnterpriseLibrary.PolicyInjection.CallHandlers
    • For more details, see The Policy Injection Application Block and Using Interception and Policy Injection in the included CHM file.
  • If you use the legacy the static PolicyInjection façade, you can no longer specify the configuration source when you call Create or Wrap methods. 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:
  • Support for .NET framework System.ComponentModel.DataAnnotations data annotation attributes has been added to the block, and the validators can be used anywhere you would use a Data Annotation attribute. For more information see Using Data Annotation Attributes in the included CHM file.
  • A validation specific Unity extension allows you to use Unity to resolve Validators. In addition, you can now configure the validation target and rule sets in a Unity configuration file.
  • Validation Application Block WPF integration work is complete. You can now use the validators when you define controls in WPF.
  • You can now apply Validation attributes to LINQ objects.
  • 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.
  • DataErrorInfoHelper class is added for implementing the System.ComponentModel.IDataErrorInfo interface using the Validation Application Block.
  • An inheritance-aware object validator has been added:
    • 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 Mar 16, 2010 at 2:52 AM by gmelnik, version 8


No comments yet.