Share via

Assemblies Side by Side

  • Article

CLR today supports multiple versions of an assembly side by side, contrast to native loader.

 

In the native world, when you call LoadLibrary(“foo.dll”) multiple times, you will only get one copy of foo.dll loaded. In CLR, since the assembly name includes version number, you can issue Assembly.Load() on different versions of assembly foo, and multiple versions of assembly foo will be loaded. (Let’s ignore the binding policy here).

 

But assemblies side by side does not come for free.

 

  1. If the assembly has AppDomain/Process wide states, multiple versions of the assembly may change the states simultaneously, causing unexpected result.
  2. Types from different versions of the assembly can not be casted to each other.

 

The second one is the killer. You have to be very careful about expose types from the assembly, since any type could potentially be compared against a type from a different version of the same assembly, results in InvalidCastException.

 

Assemblies side by side works when none of the types are exposed by other assemblies, or consumers of the two versions of the assembly work independently, and never talk to each other.

 

Beyond those simple scenarios, it requires strict engineering and QA to make multiple versions of an assembly side by side work.

 

These restrictions make assemblies side by side much less useful than it sounds.

Comments

  • Anonymous
    May 25, 2005
    "CLR today supports multiple versions of an assembly side by side, contrast to native loader."

    Huh? Then what is this all about: http://msdn.microsoft.com/library/en-us/sbscs/setup/isolated_applications_and_side_by_side_assemblies_start_page.asp
  • Anonymous
    May 26, 2005
    Isolated application and assemblies means different applications can use different assemblies. But in the same application, only one version of assemblies is allowed.

    CLR does not have this restriction.
  • Anonymous
    June 02, 2005
    The comment has been removed
  • Anonymous
    June 02, 2005
    Thanks Mike.

    The CLR model is really no different from the native sxs model. Each type has a qualified assembly token, and the assembly token has the version number. In native sxs, the assembly token is implied by the containing manifest. The difference is really a binding policy.

    I certainly won't argue which one is better. They are just different.
  • Anonymous
    May 25, 2007
    One of the important facets of successful solution design is realizing that the less code you develop