Why use strong named assemblies?

Why use strong named assemblies?

Let me list the benefits of strong naming your assembly first:

1. Strong naming your assembly allows you to include your assembly into the Global Assembly Cache (GAC). Thus it allows you to share it among multiple applications.

2. Strong naming guarantees a unique name for that assembly. Thus no one else can use the same assembly name.

3. Strong name protect the version lineage of an assembly. A strong name can ensure that no one is able to produce a subsequent version of your assembly. Application users are ensured that a version of the assembly they are loading come from the same publisher that created the version the application was built with.

4. Strong named assemblies are signed with a digital signature. This protects the assembly from modification. Any tampering causes the verification process that occurs at assembly load time to fail. An exception is generated and the assembly is not loaded.

More on strong naming from Microsoft is in Strong-Named Assemblies (MSDN).

Strong-named assemblies

Strong-naming an assembly creates a unique identity for the assembly, and can prevent assembly conflicts.

What makes a strong-named assembly?

A strong named assembly is generated by using the private key that corresponds to the public key distributed with the assembly, and the assembly itself. The assembly includes the assembly manifest, which contains the names and hashes of all the files that make up the assembly. Assemblies that have the same strong name should be identical.

You can strong-name assemblies by using Visual Studio or a command-line tool. For more information, see How to: Sign an assembly with a strong name or Sn.exe (Strong Name tool).

When a strong-named assembly is created, it contains the simple text name of the assembly, the version number, optional culture information, a digital signature, and the public key that corresponds to the private key used for signing.

Warning

Do not rely on strong names for security. They provide a unique identity only.

Why strong-name your assemblies?

When you reference a strong-named assembly, you can expect certain benefits, such as versioning and naming protection. In the .NET Framework, strong-named assemblies can be installed in the global assembly cache, which is required to enable some scenarios.

Strong-named assemblies are useful in the following scenarios:

• You want to enable your assemblies to be referenced by strong-named assemblies, or you want to give friend access to your assemblies from other strong-named assemblies.

• An app needs access to different versions of the same assembly. This means you need different versions of an assembly to load side by side in the same app domain without conflict. For example, if different extensions of an API exist in assemblies that have the same simple name, strong-naming provides a unique identity for each version of the assembly.

• You do not want to negatively affect performance of apps using your assembly, so you want the assembly to be domain neutral. This requires strong-naming because a domain-neutral assembly must be installed in the global assembly cache.

• You want to centralize servicing for your app by applying publisher policy, which means the assembly must be installed in the global assembly cache.

If you are an open-source developer and you want the identity benefits of a strong-named assembly, consider checking in the private key associated with an assembly to your source control system.

See also

• Global assembly cache
• How to: Sign an assembly with a strong name
• Sn.exe (Strong Name tool)
• Create and use strong-named assemblies

https://github.com/JamesNK/Newtonsoft.Json/issues/1001

Please review issue #615 and also see this topic.

Our application uses a local reference to Newtsonsoft.Json.dll version 8.02.
Another application (from a different company) installed Newtsonsoft.Json.dll version 8.03 into the GAC.

It totally broke our application. Json.Net has worked flawlessly for us otherwise and has been able to handle everything we've thrown at it.
This is the only issue we've ever really had with Json.Net. The issue has occurred a bunch of times over that past few years and I finally figured out what was going on.

回答:

Every approach to strong naming has issues. This is the issue of the approach I've chosen.