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!

How to Assign and Reference a Shared Name

In general, the process of giving an assembly a shared name and later referencing it by that name works as follows:

  1. Assembly A is created with a shared name using either a development environment that supports shared names or by the sn.exe utility in the NGWS runtime SDK.  The development environment or tool encrypts the hash of the file containing the assembly's manifest with the developer’s private key. This " shared name blob" is stored in the PE file containing the assembly manifest in Assembly A.
  2. Assembly B, a consumer of Assembly A, would include a "token" that represents Assembly A’s public key in the reference section of Assembly B's manifest.  A "token" of the public key is stored rather than the key itself.
  3. The NGWS runtime verifies the shared name signature when the assembly is placed in the local assembly cache. When binding by shared name at runtime, the NGWS runtime compares the key stored in Assembly B’s manifest with the key used to generate the shared name for Assembly A. If the runtime security checks pass and the bind succeeds, Assembly B has some level of comfort that the bits it is getting haven't been tampered with and that they do in fact come from the developers of Assembly A.

The above scenario does not address trust issues. Assemblies can carry full PKCS standard compliant Digital Signatures.  These signatures include a certificate that establishes trust.  It is important to note that shared names do not require code to be signed in this way.  In fact, the keys used to secure the assembly's name don't even have to be the same key used to sign the assembly itself.