Share via

Changes in This Release

  • Article

Unity 2.0 – April 2010 is a new release of the Microsoft patterns & practices Unity dependency injection and interception system. This release also includes additions in functionality, and has been adapted to work with Microsoft Visual Studio® 2010; and with the Microsoft .NET Framework versions 3.5 SP1 and 4.0.

Go to CodePlex for information on Known Issues.

The following sections discuss the changes to Unity:

Breaking Changes to Unity

Changes in Unity

Breaking Changes to Unity

This section lists the breaking changes in Unity 2.0.

  • Unity 2.0 uses a new streamlined configuration schema for Configuring Unity. Partial backward compatibility is provided for previous configuration schemas. The new schema breaks previous container extension configurations that use <extensionConfig>.

  • Unity 2.0 configuration API change:

    The previous API used to load container configuration has been deprecated. Previous versions used the following approach:

    IUnityContainer myContainer = new UnityContainer();
UnityConfigurationSection section 
    = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
section.Containers["containerName"].Configure(myContainer);

    In Unity 2.0, you have the two choices. You can use ConfigurationManager and Configure to load a given container from a specific named configuration section, as shown in the following example.

    IUnityContainer myContainer = new UnityContainer();
UnityConfigurationSection section
    = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
section.Configure(myContainer, "containerName");

    Otherwise, you can use LoadConfiguration to load a given named container from the default configuration section, as shown in the following example.

    IUnityContainer myContainer = new UnityContainer();
myContainer.LoadConfiguration("containerName");

    Note

    There are several overloads of the new LoadConfiguration extension method. See Using Design-Time Configuration for more information.

  • The arrangement of call handlers and matching rules has been changed. For more information see Configuring Policy Injection Policies and Enterprise Library Call Handlers.

  • The Unity for Silverlight® assembly has changed from Microsoft.Practices.Unity.DLL to Microsoft.Practices.Unity.Silverlight.dll.

Changes in Unity

The following changes are implemented in this release:

  • The ObjectBuilder generic dependency injection mechanism, which was previously distributed as a separate assembly, is now integrated with Unity. You no longer need to reference the ObjectBuilder assembly in your projects.
  • The StaticFactory.StaticFactoryExtension to Unity, which allows you to specify a factory function that the container will use to create an object, was shipped as a separate project in Unity 1.2. In this release, it is contained within the main Unity assembly but is deprecated. Use the new InjectionFactory class.
  • A new InjectionFactory class has been added. It enables you specify a factory method that the container will use to create the object. It is an easier way to accomplish the same task as the old StaticFactory.StaticFactoryExtension.
  • Unity provides a new interception process and provides interceptors that enable you to intercept calls to objects and attach behaviors to the intercepted methods. A behaviors pipeline is used instead of the previous call handlers pipeline. Interception is supported with or without a dependency injection container. See Interception with Unity.
  • A HierarchicalLifetimeManager is provided to register an object in the parent container such that each child container resolves its own instance of the object instead of sharing one with the parent. Understanding Lifetime Managers
  • Dependencies can be made optional by using the <optional> element in configuration files, the [OptionalDependency] attribute, or OptionalParameter in your code. See Annotating Objects for Property (Setter) Injection.
  • Unity now provides the ability to specify parameter values for constructors, or specific values for properties, at Resolve time. These values override what the container would have otherwise supplied. ParameterOverride, PropertyOverride, and DependencyOverride are ResolverOverride implementations that provide support for overriding the registration information for resolving instances of types. Resolving Objects by Using Overrides
  • A PerResolveLifetimeManager registers an object such that the behavior is like a TransientLifetimeManager, but also provides a signal to the default build plan, marking the type so that instances are reused across the build up object graph. Understanding Lifetime Managers
  • The Registrations property and IsRegistered method have been added. These let you query the container and retrieve information about what is currently registered. See Retrieving Container Registration Information.
  • You can use the .NET standard type Func<T> (C#) or Func(Of T) (Visual Basic®) with the Resolve method if you wish to defer the resolution of an object. For more information see Deferring the Resolution of Objects.
  • Specifying a resolved array without providing any members will result in an empty (zero length) array.
    • In a configuration file, the <array /> element with no child elements will generate a zero-length array for both generic and non-generic types. If you want to resolve all configured types to populate the array (effectively invoking the ResolveAll behavior), you must use a <dependency /> element instead.
    • When performing run-time configuration, the ResolvedArrayParameter and GenericResolvedArrayParameter classes will generate a zero-length array if you do not specify the members for the array. If you want to resolve all configured types, use the GenericParameter class and specify the array type followed by the appropriate brackets to indicate an array type in the language you are using. For example, GenericParameter("T[]") in C# or GenericParameter("T()") in Visual Basic.