The Unity container is highly customizable. No one fixed configuration format can cover everything that you might want to do with the container. As a result, the Unity configuration system itself is extensible, allowing you to add new valid elements to your configuration file. The element allows you to load the code that adds these new options to the configuration file. This lets you specify an implementation of the SectionExtension type.

Section extensions can do the following to the configuration:

• Add new predefined aliases
• Add new container-level elements
• Add new registration-level elements
• Add new value-level elements

You can create your own custom extensions, or use extensions created by third parties, with Unity. Unity also uses default extensions to implement its own functionality. For information about using extensions, see Creating and Using Container Extensions.

One example of a section extension is the InterceptionConfigurationExtension section extension, which ships with the Unity package. This section extension adds the following elements and aliases to the schema:

• Aliases are defined for each of the types (like VirtualMethodInterceptor, TransparentProxyInterceptor, and various matching rules) that are used by the interception configuration.
• The element is added as a valid element child element for the element.
• The , , , and elements are added as valid child elements for the element.

This extension mechanism allows for almost unlimited extensibility of the configuration file on an opt-in basis. Though the schema extension will modify the schema allowed at run time, it does not modify the XSD file used by Visual Studio IntelliSense. As a result, you will still get warnings in the Visual Studio XML editor even though the file will work fine at run time. In order to resolve this problem, the section extension author must provide an updated XSD document for use with their extension.

Note: The InterceptionConfigurationExtension is supported by the schema shipped with Unity.

The element also accepts a user-provided prefix attribute. This is useful in the case where two section extensions both provide extension elements with the same name. In the case of a collision, you can specify a prefix for one or both section extensions, and then use that prefix to disambiguate them.

Consider two schema extensions, both of which add a element. Using the prefix attribute, a configuration file that uses both would look like the following example.

<unity>
    <sectionExtension prefix="ext1" type="MyFirstExtension, MyStuff" />
    <sectionExtension prefix="ext2" type="MySecondExtension, MyOtherStuff" />
    <container>
        <ext1.containerCustomization />
        <ext2.containerCustomization />
    </container>
</unity>