|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here.|
Strong-Name Signing for Managed Applications
Strong-name signing, or strong-naming, gives a software component a globally unique identity that cannot be spoofed by someone else. Strong names are used to guarantee that component dependencies and configuration statements map to exactly the right component and component version.
A strong name consists of the assembly's identity (simple text name, version number, and culture information), plus a public key token and a digital signature.
For Visual C#, Visual Basic, and Visual J# projects, Visual Studio enables strong-naming through the Signing pane in the Project Designer; see.
For Visual C++ projects, you use linker options to sign your assembly; see.
Reasons to Use Strong-Naming
Strong-naming gives an application or component a unique identity that other software can use to refer explicitly to it. For example, strong-naming allows application authors and administrators to specify a precise servicing version to be used for a shared component. This allows different applications to specify different versions without affecting other applications. In addition, you can use the strong name of a component as security evidence to establish a trust relationship between two components.
What Can Be Strong-Named
You can strong-name .NET Framework assemblies and XML manifests. These include:
Application Assemblies (.exe)
Application Manifests (.exe.manifest)
Deployment Manifests (.application)
Shared Component Assemblies (.dll)
What Should Be Strong-Named
Shared DLLs should be strong-named. Regardless of whether a DLL will be deployed to the Global Assembly Cache, a strong name is recommended when the DLL is not a private implementation detail of the application, but is a general service that can be used by more than one application.
What Must Be Strong-Named
You must strong-name the following:
DLLs, if you wish to deploy them to the global assembly cache (GAC).
ClickOnce application and deployment manifests. The Visual Studio project system enables this by default for ClickOnce-deployed applications.
Primary interop assemblies, which are used for COM interoperability. The TLBIMP utility enforces strong-naming when creating a primary interop assembly from a COM type library.
What Should Not Be Strong-Named
In general, you should avoid strong-naming application EXE assemblies. A strongly named application or component cannot reference a weak-named component, so strong-naming an EXE prevents the EXE from referencing weak-named DLLs that are deployed with the application.
For this reason, the Visual Studio project system does not strong-name application EXEs. Instead, it strong-names the Application manifest, which internally points to the weak-named application EXE.
In addition, you may want to avoid strong-naming components that are private to your application. In this case, strong-naming can make it harder to manage dependencies and add unnecessary overhead for private components.
How To Assign a Strong Name
In Visual Studio, you strong-name an application or component using the Signing pane of the Project Designer. The signing pane supports two methods of strong-naming: using a strong-name key file, or using a key provider. For information on signing manifests, see; for information on creating strong-name key (.snk) files, see .
When using the key-file method, you can use an existing key file or create a new one. You should always protect your key file with a password to prevent someone else from using it.
Key providers or certificate stores provide another means of securing your strong-name keys. Some key providers use a smart card as a means of verifying your identity and preventing your key from being stolen.
Updating Strong-Named Components
A strong-named component cannot be serviced or upgraded just by copying a new version over the old one.
You can update a weak-named DLL in an application directory simply by copying a new version into the application directory; the common language runtime (CLR) will load whatever version is physically present.
With strong-named DLLs, you must either recompile the entire application so that all assembly references point to the new version, or you must update the application's .config file to instruct the runtime to load the new version instead of the old one.
Although strong-named components require a little more maintenance, the benefit is that applications can be very explicit about which versions of other components they require at run time.