Compartilhar via


Assinatura de Nome Forte para Aplicativos Gerenciados

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 Assinatura de Página, o criador do projeto.

For Visual C++ projects, you use linker options to sign your assembly; see Assemblies com Nome Forte (Assinatura de Assembly).

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. O assinatura painel oferece suporte a dois métodos de nomeação forte: usando um arquivo de chave de nome forte ou usando um provedor de chaves. For information about signing manifests, see Como: Assinar manifestos de aplicativo e implantação; for information about creating strong-name key (.snk) files, see Como: Criar um par de chaves pública/particular.

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.

Consulte também

Tarefas

Como: Assinar manifestos de aplicativo e implantação

Como: Assinar um Assembly (Visual Studio)

Como: Atrasar a assinatura de um Assembly (Visual Studio)

Referência

Assinatura de Página, o criador do projeto

Conceitos

Protegendo aplicativos de ClickOnce

Assemblies de nomes fortes

Assemblies com Nome Forte (Assinatura de Assembly)

Outros recursos

Gerenciando Assinatura de Assembly e Manifesto