Migration and Side-by-Side Execution

In general, applications that use previous versions of Unity will function with this release without the need for any code changes. It will be necessary, however, to update the references to refer to the new assemblies and to update the configuration files to reference the correct version of the assemblies.

This version of Unity can also be installed side by side with earlier versions. You can deploy new applications written for this version of Unity along with applications written for earlier versions. In addition, you can also choose to migrate existing applications to the new version.

If you decide to use side-by-side execution, you must deploy the different Unity versions in different directories. In any specific directory, you cannot mix and match assemblies from different versions.

The shipped project files use data in the AssemblyInfo.cs file to build assemblies that have different version information. This allows you to use strong names and to add different versions to the global assembly cache (GAC) for side-by-side execution.

Partial Migration

Each assembly in an application can refer to only one version of Unity, but an application that has multiple assemblies can refer to more than one version. For example, you may have an application with two assemblies, both using the Unity 1.1. One assembly can be migrated to use Unity 2.0, and the other assembly can remain unchanged. This means you can gradually migrate your application, one assembly at a time. However, although partial migration is supported, it is somewhat complicated to implement; therefore, it is not recommended.

For details on migrating applications and configuration files see the "Enterprise Library 5.0 and Unity 2.0 Migration Guide" at https://www.codeplex.com/entlib/ .

For details on migrating extensions see Reusing Configuration Files Based on a Previous Schema.