Share via

Deployment and Operations

  • Article

When you use Unity in your applications, you must deploy the required assemblies with your application or install the assemblies on the target computer in the global assembly cache (GAC). You must include the assembly named Microsoft.Practices.Unity.dll. If you are using interception, you will also require the assembly named Microsoft.Practices.Unity.Interception.dll.

You can deploy an application that uses Unity in one of two configurations:

  • As private assemblies in the application folder hierarchy
  • As shared assemblies in any file system location or in the global assembly cache

For advice on using Unity with applications that run in partial trust modes, see Using Unity in Partial Trust Environments.

For advice on updating existing versions of Unity assemblies, see Updating the Unity Assemblies.

When you compile the installed version of Unity source code, the assemblies produced will not be strong named. As a result, they cannot be installed in the global assembly cache, nor will they have the other benefits associated with strong-named assemblies. To learn how to strong name Unity assemblies, see Strong Naming the Unity Assemblies.

Note

Unity throws (and handles internally) LockSynchronization exceptions. LockSynchronization exceptions may be observed in the debugger output but they are handled internally and no action is required.

Using XCopy

You are not required to use strong names or to install Unity assemblies in the global assembly cache. You can compile and deploy Unity—without modifying it—in the directory structure of any application that uses Unity. This simplifies deployment because you can use the xcopy command to install the entire application, including the Unity assemblies, on the target computer. However, if multiple applications on the same computer use Unity, you must install a copy of the assemblies in each application's folder hierarchy.

Using the Global Assembly Cache

Alternatively, you can sign Unity assemblies with a strong name key. This will ensure that their names are globally unique and will also provide versioning. If you take this additional step, you can deploy Unity assemblies in a shared location and multiple applications can use them. For example, you could deploy Unity assemblies in the global assembly cache. If you do this, all applications on the computer can use Unity. To learn how to strong name Unity assemblies, see Strong Naming the Unity Assemblies.

Installing an Assembly in the Global Assembly Cache

You can use one of the following tools to install an assembly in the global assembly cache:

  • An installer program, such as the Microsoft Windows Installer version 2.0
  • The global assembly cache tool command line utility (Gacutil.exe)
  • The .NET Framework configuration tool (Mscorcfg.msc)

For more information about deploying .NET applications, see Deploying.NET Framework-based Applications on MSDN.

Versioning

All the assemblies provided with Unity are strong named, which provides versioning and naming protection. This means that the name of the binary code is guaranteed to be unique and that the versions being loaded are the ones intended to be used with the application. Because the assemblies are strong named, you can install them in the global assembly cache, where they can be shared by multiple applications on the computer.

The Unity installation package includes compiled assemblies for Unity. It also includes the source code and scripts that you can run to create the complied assemblies. The assemblies you create this way are not strong named. To sign an assembly with a strong name, you must have a public/private key pair. For more information, see Strong-Named Assemblies and Versioning Tutorial.

It is not recommended that you use Unity namespaces because it makes it difficult to identify the source of the code. Instead, you should choose a root namespace that meets your own coding and versioning standards.