Click to Rate and Give Feedback
Collapse All/Expand All Collapse All
This page is specific to
Microsoft Visual Studio 2008/.NET Framework 3.5

Other versions are also available for the following:
Deployment in Visual Studio
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).

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.

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.

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.

Tags What's this?: Add a tag
Community Content   What is Community Content?
Add new content RSS  Annotations
Strong Naming and Assembly Integrity      Dan Appleman   |   Edit   |   Show History

This article does not address the value of strong-naming for EXE assemblies with regards to detecting external modifications to those assemblies. Strong Naming does not just ensure binding to the correct assembly, it also allows you to validate that an assembly is unchanged. Given the ease with which .NET assemblies can be decompiled, modified, and recompiled, Strong Naming is a key tool for verifying application integrity.
In the case of private components, the component can use strong naming to validate that the caller has not been modified by validating the signature against the publisher's public key (known to the component).
While validating EXE assembly integrity is not necessary in all situations, it is essential in the case of most licensed applications - as failing to Strong Name the EXE assembly makes it relatively easy for hackers to remove any licensing code.

Processing
© 2009 Microsoft Corporation. All rights reserved. Terms of Use | Trademarks | Privacy Statement | Site Feedback
Page view tracker