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.
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.
Do not rely on strong names for security. They provide a unique identity only.
Why strong-name your assemblies?
For .NET Framework, 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
friendaccess 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.
For .NET Core and .NET 5+, strong-named assemblies do not provide material benefits. The runtime never validates the strong-name signature, nor does it use the strong-name for assembly binding.
If you are an open-source developer and you want the identity benefits of a strong-named assembly for better compatibility with .NET Framework, consider checking in the private key associated with an assembly to your source control system.