Using the Unity XSD to Enable Visual Studio IntelliSense

Microsoft Enterprise Library 5.0

DropDown image DropDownHover image Collapse image Expand image CollapseAll image ExpandAll image Copy image CopyHover image

You can enable IntelliSense in Visual Studio to assist the manual editing of Unity configuration files.


Note:
The XSD is not required. Configuration will work at run time without it. It is only required for IntelliSense in Visual Studio.


In order for the XSD to be used by the Visual Studio editor the <unity> element must have an XMLNS attribute with the correct namespace. The following are the two ways to get the correct namespace instead of manually entering it:

  • You can force the editor to use the schema by clicking Schemas on the XML menu and selecting the entry for the unity configuration schema. After that, the <unity> element will appear as an alternative in the IntelliSense dropdown and by choosing it from IntelliSense the xmlns attribute will be populated. This is a per-user and per-project setting, so every user working on the project would be required to select this setting.
  • You can enter <unity xmlns=" and then IntelliSense will show a list of namespaces which are targeted by a known schema. You can then choose the right namespace, http://schemas.microsoft.com/practices/2010/unity, which will show up in the IntelliSense list when you click on the xmlns attribute and complete the entry. Visual Studio will then associate the URL with the actual physical file. This is the recommended option, since the setting persists when you pass the configuration file to another user.

Collection elements, such as aliases, containers, extensions, namespaces, and assemblies are not supported by the xsd, but they do work in the configuration file.

There are some pre-defined type names for some type attributes, such as for lifetime managers, but these are just suggestions and any type name is accepted.

The schema for the register element imposes a specific order for its children, an order that is not required by the configuration runtime but makes the schema more robust. The order of children is as follows: one optional lifetime, one optional constructor, and then as many of method, property, interceptor, interceptionBehavior, addInterface and any custom element as desired, in any order.