Unity Configuration – Registration by Convention

To make container setup easier and less verbose, we are adding a new feature in Unity 3.0 – registration by convention.

What is the Registration by Convention feature?

This feature (also referred to as auto-registration) is intended to simplify your type registrations. Rather than specify each type mapping individually (lots of container.RegisterType<IFoo, Foo>()) , you can direct the Unity container to scan a collection of assemblies and then automatically register multiple mappings based on a set of rules that identify the types and their locations.

The following code shows example usage of the current implementation of registration by convention:

using (var container = new UnityContainer())  {







What conventions are supported?

A convention must specify which available types should be mapped in the Unity container as well as how those type mappings are defined. Currently, the available conventions work by specifying the following rules:

1. Identify the list of assemblies to scan for types to be registered: you can provide your own list of assemblies, use only currently loaded assemblies, or use assemblies that reside in the base path of your application. You can further filter the list of types by names, suffixes or other predicates by using LINQ queries or extension methods. This first step results in a list of types to potentially register with the container. By the way, by default, all system assemblies will be skipped – you have to opt-in for them to be included. Note: you don’t need to start from our helper method for loading types. You can use any method to obtain an enumeration of types, even as simple as an array of literal types.

2. Optionally, specify which types (typically interfaces or abstract classes) you want the container to resolve to each of the types identified in step 1. Currently, conventions include:

a. Create mappings where the following naming convention is followed: type Foo and interface IFoo.

b. Map each type to all of the interfaces it implements.

c. Map each type to all of the interfaces it implements where those interfaces are in the same assembly as the type.

3. Optionally, specify whether to use a named registration. In this case Unity uses the type name as the name of the registration.

4. Optionally, specify which lifetime manager to use for the registrations.

5. Optionally, identify any members of the type that should be injected.

What about Windows Store Apps?

The registration by convention will also be supported by Unity for Windows Store Apps with some limitations enforced by the framework, such as you won’t be able to scan the loaded assemblies and you won’t be able to scan a particular folder, but you can assemblies packaged with the app.

What other specific conventions should we support?

As always, we seek your feedback on the new features. As we are finalizing the implementation of the registration by convention, it would be helpful to get your thoughts on the following:

1. Do you see a requirement for out-of-the-box automatic creation of mappings for abstract types as well as interfaces?

2. Do you see a requirement for out-of-the-box support for scanning other locations for assemblies? E.g. arbitrary folders.

3. In scanning the assemblies in some location, would you want to have a way of annotating specific assemblies with an optional attribute?

4. Do you see any requirement for context specific conventions? Such as ASP.NET MVC, WCF, etc. Or is Unity auto-wiring sufficient in these cases?

5. If you are providing injection members, some of those will be associated with the “from” type, but most will be associated with the “to” type. Do you see the need to be able to specify more fine-grained injection members, or is the support for “to” types sufficient?

Comments (10)

  1. Sla says:

    1. yes

    2. no

    3. yes

    4. yes, but as a separate modules, not built in by default.

  2. I've been using nuget.org/…/UnityConfiguration to provide convention support to Unity. One of the things I like about it is that the registry (convention configuration) can automatically detect and run other registries.

    This is handy because a registry can be written for each layer in a project so that the convention can be scoped to that layer. Without this, the top layer (typically the UI) must be coupled to all layers in order to provide the convention configuration across them all.

  3. Isaac Abraham says:

    This looks good. Hopefully it will render the likes of UnityConfiguration and my nuget.org/…/Lydian.Unity.Automapper obsolete. It looks like you've got it working prettty slickly – I can't impress upon you how important I think it is to make it hit the sweet spot whereby the most common requirements will be met by the smallest amount of conventions.

    I'd like to see Policy Injection made a little more accessible – it's such a powerful feature but you have to go through so many hoops to use it that it turns a lot of developers off to it. Have a look at how I've wrapped around it in the Automapper to try to make it as easy as possible…

  4. .Net says:

    Where is MappedTo class defined? Visual Studio cannot find it. Using Unity nuget 3.0.1304.0

  5. .Net says:

    From VB.Net you call it like this. Took me a while to figure it out.



               Function(i) WithMappings.FromMatchingInterface(i),

               Function(i) WithName.Default(i),

               Function(i) WithLifetime.Transient(i))

  6. Is there a way to use Registration by convention in the unity.config file?

  7. gmelnik says:


    There is no config file support for this feature. Programmatic only.

  8. Not even plans? I understand the problem with Func in the config file, but could have some extension in the config file to register the RegistrationConvention as a type, with parameters like every type, and them run through all of the RegistrationConvention classes, it's easy to implement and I'll probably do it, but could be inside unity.

  9. Alexander Batishchev says:

    Hi Grigori,

    Looks like API has changed: instead of MappedTo.MatchingInterface now it's  WithMappings.FromMatchingInterface.

    Please update the post.

  10. gmelnik says:

    Thank you, Alexander.

    Updated now.