Glossary / Strong naming
Strong naming
Strong naming gives an assembly a cryptographic identity based on its name, version, culture, and public key, and signs it with a private key. It supports identity and binding scenarios in .NET, especially legacy .NET Framework and some plugin ecosystems, but it is not a security boundary, code-trust certificate, or substitute for package signing/provenance.
Signing and loading
A strong-named assembly contains a public key and signature; the private key must be protected. Consumers can reference the strong identity, and .NET Framework historically uses strong names for Global Assembly Cache installation and binding policies. Modern .NET has different loading and deployment behavior; strong naming is often a compatibility requirement rather than a security recommendation. Delay signing embeds the public key while postponing final signing and has operational/security caveats.
Rotating a strong-name key changes assembly identity and can break consumers. Public signing and signing validation behaviors differ by tool/runtime. Treat key files as secrets and avoid committing private signing keys. Package signature and NuGet repository provenance are separate mechanisms.
Engineering guidance
Use strong names only when required by platform, consumer, or organizational contract. Document key ownership/rotation and validate signatures in release pipelines. Do not use a public key token as proof that code is trustworthy or authorized.
Interview questions
- What does strong naming identify? Assembly name/version/culture plus public-key identity and signature.
- Is it a security boundary? No; it is not a trust or authorization mechanism.
- Why can key rotation break consumers? The public key is part of assembly identity.
- What is the difference from package signing? Strong naming identifies/signs an assembly; package signing/provenance attest distribution artifacts/origin.
- When require it? Legacy .NET Framework/GAC or explicit consumer compatibility requirements.