To Strong Name or Not to Strong Name

Posted by nhughes Sat, 09 Jul 2005 04:08:00 GMT

Awhile back, I did some research on strong naming (ie signing) and the GAC. I thought it might be an interesting post. We ultimately signed all of our assemblies.

When strong names MUST be used:

  1. Any assemblies loaded into the GAC must have strong names.
  2. For a .NET class to take advantage of Enterprise Services (COM+ Services), such as distributed transactions and object pooling, the assembly that contains the class—called a Serviced Component because it inherits from the class EnterpriseServices.ServicedComponent—must have a strong name.
  3. For a .NET component to be used by a non-.NET component. (This is the reason we ultimately signed all of our assemblies, since we have a component that must be called by a VB 6.0 app).

Advantages of using strong names:

  1. Versioning: Eliminates DLL Hell
    - Developers can uniquely identify versions of .NET assemblies.
    - Different versions of the same assembly can run side-by-side.
  2. Authentication
    - Strong names ensure the code is provided by the publisher.
    - Strong names can be used with code groups to provide levels of access to the assembly. For instance, Admins and Developers can use strong names with code groups to provide assemblies with higher permissions than the default .NET framework permission level.
  3. Binary Integrity
    - The CLR can tell from the signing of the assembly whether it has been tampered with since it was last compiled.
  4. Potentially fixes a problem where shared assemblies get added multiple times in a Microsoft Setup Project. This may not be necessary with Beta 2, though.

Disadvantages to using strong names:

  1. Creates additional work to go through and sign every assembly in a project (and every assembly referenced, like Enterprise Library Assemblies).
  2. When you sign assemblies, the CLR first looks for the assembly reference in the GAC and if it cannot find it, it then probes for it. This could be inefficient for your processes if you have no assemblies in the GAC.
  3. Signing the assemblies will bring tighter security, and may cause a security issues between assemblies, requiring more troubleshooting time to figure out the problems.

Note: If you decide to sign your assemblies and you are using Enterprise Library, you will have to ensure that every assembly you use is referencing the signed copy of Enterprise Library. This gave us fits.

RSS feed for this post trackback uri

Comments are disabled