• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 862
  • Last Modified:

Strongly Named Assemblies

According to Microsoft, Assemblies that reference strongly named assemblies must themselves by strong named, otherwise it would compromise the security pof the strong named assembly.

Ok. If that is true, then how come an assembly I created, which references strong named Crystal reports assemblies, and strong named Custom controls assemblies, works, and my assembly is not signed with a strong name?

I want to sign my assemblies now with a strong name. Will that break backwards compatibility with other assemblies that reference my assemblies, if those assemblies do not have a strong name? (my assemblies are not stored in the GAC)
1 Solution
1. It is just a recommendation that assemblies referencing strong named assemblies should themselves be strong named. It is not a required crieteria.. That's why you are able to reference a strong named assembly in a simple assembly..

2. It won't.. you can sign your assemblies now with a strong name. It will not break backwards compatibility with other assemblies that reference your strong named assemblies that do not  have a strong name..This is possible because of point number 1.

Hi gregasm,
The correct Rule is just the opposite, i.e. if an assembly is strong named, ALL ASSEMBLIES REFERENCED BY THIS ASSEMBLY SHOULD ALSO BE STRONG NAMED.
Think of it this way, if your statement is true then we can never create assemblies without strong name using the .net framework assemblies (like System.dll) as all framework assemblies are strong named.
Let me try to understand your second question. I assume that you have an assembly A which you want to strong name. There are assemblies X,Y and Z referring to this assembly A. If this is the scenario, then you will need to RECOMPILE the assemblies X/Y/Z to be able to use the newer version of A. To understand this, you will need to understand the use of strong naming the assembly:
1. Strong naming an assembly involves assigning a public-private key pair to it.
2. When an assembly is strong named, a hash is created from the assembly content and then it is encrypted using the private key used for strong naming.
3. At runtime, when a strong named assembly (say the crystal reports assembly) is to be loaded, the CLR will calculate the hash of the assembly again. The CLR will then decrypt the encrypted hash generated earlier using the public key. The CLR compares the decrypted hash to the hash calculated. If the they are the same, then the CLR assumes that the crystal assembly is a valid assembly. But if it is not same (because for some reason some one tampered with the contents of the crystal assembly dll) the CLR will not allow the loading of the assembly.

In your case if you do not recompile X/Y/Z and just replace the older version of A with the strong named version, you will get an error like "Comparing the assembly name resulted in the mismatch: PUBLIC KEY TOKEN".

Hope this helps...

Featured Post

The new generation of project management tools

With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now