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 correct 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# and Visual Basic projects, Visual Studio enables strong-naming through the Signing pane in the Project Designer; see Signing Page, Project Designer.
For Visual C++ projects, you use linker options to sign your assembly; see Strong Name Assemblies (Assembly Signing) (C++/CLI).
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 enables application authors and administrators to specify a precise servicing version to be used for a shared component. This enables 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 the following:
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 want to deploy them to the global assembly cache (GAC).
ClickOnce application and deployment manifests. By default, the Visual Studio project system enables this 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. Therefore, 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 more difficult 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 by 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 about signing manifests, see How to: Sign Application and Deployment Manifests; for information about creating strong-name key (.snk) files, see How to: Create a Public/Private Key Pair.
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 by copying a new version over the old one.
You can update a weak-named DLL in an application directory by just 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 whole 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 bit more maintenance, the benefit is that applications can be very explicit about which versions of other components they require at run time.
See Also
Tasks
How to: Sign Application and Deployment Manifests
How to: Sign an Assembly (Visual Studio)
How to: Delay Sign an Assembly (Visual Studio)
Reference
Signing Page, Project Designer
Concepts
Securing ClickOnce Applications
Strong Name Assemblies (Assembly Signing) (C++/CLI)