Assemblies Side by Side

New and Notable 73

Sam Gentile's Blog — Wed, 25 May 2005 18:20:23 GMT

re: Assemblies Side by Side

Anonymous — Thu, 26 May 2005 11:32:25 GMT

"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

re: Assemblies Side by Side

junfeng — Thu, 26 May 2005 18:39:18 GMT

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.

re: Assemblies Side by Side

mgrier — Thu, 02 Jun 2005 19:50:16 GMT

Two relevant points:

1. For native sxs support, we took it as a basic requirement that we were not going to change all the myriad APIs which bind to objects based on names of some sort (file names, guids, whatever) and change the APIs to take additional parameters. Thus, within any context ("activation context"), bindable names have to be unique and unambiguous.

To avoid setting false expectations, we more simply refused to allow more than one assembly into a given context with the same name. This restriction could be relaxed over time but still when someone calls CoCreateInstance() with some guid, it has to map unambiguously to exactly one COM server, so the apparent utility of loading multiple versions of the same component into a given context is pretty low since the versions would have had to change all the public bindable names (e.g. rename all the DLLs, reguid all the com servers, change all IIDs, change all progids, etc.).

Personally I think that this is a much better solution than what CLR did in putting component identities on each type name reference. It gives us a lot more agility and the restriction to not be able to load more than one version of a component into a given context simultaneously is not much of a restriction in practice.

2. The real problem here is that "Elvis friendly" type signatures are, in general, directly at odds with "compatibility friendly" type signatures. I think this is just life and we need to stop our hand-wringing and wailing "surely something must be done!". There have been several grand experiments in this space and basically they all failed in their grandiose plans. Either you get locked into compatibility on an API with a huge surface area or you end up breaking your clients all the time. This dilemma is exactly why we invented sxs in the first place to give some flexibility here.

re: Assemblies Side by Side

junfeng — Thu, 02 Jun 2005 21:06:01 GMT

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.

Third party components and versioning conflicts in their shared dependencies

Michael Christensen — Fri, 25 May 2007 21:40:15 GMT

One of the important facets of successful solution design is realizing that the less code you develop