NGWS SDK Documentation  

This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!

Private and Shared Assemblies

There are two “kinds” of assemblies: private assemblies and shared assemblies. Private and shared assemblies are the same structurally and there is really no difference in the types of functionality they can provide. Instead there are differences in how these assemblies are named, the locations to which they can be deployed, the level of version checking done when they are loaded and how they are referenced.

A private assembly is intended to be used only within one application. Private assemblies are typically authored by the same group or organization that authors the application in which it is used. As a result, the application author has a high degree of control over the naming and versioning of the assembly. In fact, private assemblies must be deployed in the same directory as the application or a subdirectory thereof. This allows the NGWS runtime to enforce that no other application can reference this assembly.

Private assemblies have relatively simple naming requirements – their name just has to be unique within the application and concerns about name spoofing are limited. Private assemblies have what we call a private name, which is simply a descriptive text string that makes up the assembly’s identity along with version and culture.

Because private assemblies are under the control of the application author, and are deployed along with the application, the NGWS runtime does not enforce any versioning or naming rules.

In contrast, shared assemblies are meant to be used by several applications on the machine. Typically a shared assembly is authored by someone other than the author of the application that uses it. Examples of shared assemblies include a UI grid control that is used by several applications or system class libraries like those shipped by Microsoft or other library vendor. The naming requirements for shared assemblies are much more stringent than they are for private assemblies. For example, the name of a shared assembly must be globally unique. In addition, the author of the assembly needs some protection of the name. That is, they need to be guaranteed that a third party can’t release a subsequent version of an assembly they’ve produced and have it picked up by users unknowingly. The NGWS runtime supports these naming requirements through a feature called shared names. Shared names use cryptographic key pairs to ensure name uniqueness and to prevent name spoofing. In addition, shared names also provide the caller of the assembly with information about the identity about the publisher of the assembly. Callers can use this information to ensure that the assembly they use at runtime comes from the same publisher that supplied the assembly they compiled against. More details about shared names can be found in the Shared Name Spec.

Shared assemblies are typically deployed to the global assembly cache. The assembly cache provides for side by side storage of multiple versions of an assembly and provides performance benefits in terms of lookup and code sharing. However, not all shared assemblies must be deployed in the assembly cache. There are several scenarios where an application may want to deploy a shared assembly in its application directory to ensure that version gets loaded.

Unlike references to private assemblies, references to shared assemblies include version checking and the application of version policy as described throughout this document.