Share via

Strong Naming the Enterprise Library Assemblies

  • Article
Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
The latest Enterprise Library information can be found at the Enterprise Library site.

If you build Enterprise Library from the source code, you may decide to apply strong naming to the assemblies. A strong name consists of the assembly's identity—the simple text name, version number, and culture information (if provided)—plus a public key and a digital signature. The strong name is generated from an assembly file (the file that contains the assembly manifest, which in turn contains the names and hashes of all the files that make up the assembly), using the corresponding private key. Signing an assembly with a strong name ensures that its name is globally unique. Assemblies with the same strong name are expected to be identical.

For example, if you intend to share the Enterprise Library assemblies among several applications, you can install them into the global assembly cache. Each assembly in the global assembly cache must have a globally unique name. You can use a strong name to ensure this. Even if you use the assemblies within only a single application, you can strong name the assemblies to ensure that your application uses the correct version of the assemblies.

Strong names satisfy the following requirements:

  • Strong names guarantee name uniqueness by relying on unique key pairs. No one can generate the same assembly name that you can because an assembly generated with one private key has a different name than an assembly generated with another private key.
  • Strong names protect the version lineage of an assembly. A strong name can ensure that no one can produce a subsequent version of your assembly. Users can be sure that a version of the assembly they are loading comes from the same publisher that created the version originally provided with the application.
  • Strong names provide a strong integrity check. Passing the .NET Framework security checks guarantees that the contents of the assembly have not been changed since it was built. However, note that strong names alone do not imply a level of trust such as that provided by, for example, a digital signature and supporting certificate.

You can apply strong naming to assemblies in two ways:

  • Using the patterns & practices Strong-Naming Guidance Package
  • Using Visual Studio to Strong Name Enterprise Library Assemblies

For information about deploying assemblies into the global assembly cache, see Working with Assemblies and the Global Assembly Cache.

Using the patterns & practices Strong-Naming Guidance Package

The patterns & practices group provides a strong-naming guidance package that integrates with Visual Studio. It automates the process of strong-naming collections of projects and modifies any [InternalsVisibleTo] attributes to include a public key. This guidance package is particularly useful for Enterprise Library, but it can also be used with other .NET Framework solutions.

Note

For details of the Strong-Naming Guidance Package, see the patterns & practices community site on CodePlex.

Using Visual Studio to Strong Name Enterprise Library Assemblies

If you do not want to use the Strong-Naming Guidance Package, you can strong-name the Enterprise Library assemblies with Visual Studio. To sign an assembly with a strong name, you must have a public/private key pair. This public and private cryptographic key pair is used during compilation to create a strong-named assembly. If many developers are using the Enterprise Library, they should all use the same strong-named assembly. This means that everyone should use a single key pair to sign the assemblies. This key pair should be securely stored.

The first procedure describes how to create a key pair. (You can also use an existing key pair. If you have an existing key pair, you can skip this procedure.) The second procedure describes how to extract and display the public key. The third procedure describes how to assign the public key to an assembly. The last procedure describes how to update the InternalsVisibleTo attribute.

To create a key pair

  1. At the Visual Studio command prompt, go to the directory that will hold the key pair.
  2. To create a key pair, type sn —k keyfile.snk.

Note

You can also use the CreateStrongName dialog box in Visual Studio to create a key pair. To access this dialog box, select a project node in Solution Explorer. On the Project menu, click Properties. When the Project Designer appears, click the Signing tab. On the Signing page, select Sign the assembly, and then click New in the Choose a strong name key file drop-down list box.

You must extract the public key from the key pair (the public key is required for updating the InternalsVisibleTo attribute). The following procedure describes how to extract and display the public key.

To extract and display the public key

  1. At the command prompt, type sn —p keyfile.snk publickey.pk to extract the public key from the key pair.
  2. Type sn —tp publickey.pk to display the public key in hexadecimal. Keep the Configuration Console window open (or copy the output to a text file).

The next procedure describes how to assign the key to the Enterprise Library assemblies. Open the EnterpriseLibrary.sln solution file. Follow these steps for each project, including the unit tests and design projects.

To assign the public key to a project assembly

  1. In Visual Studio, select the project node in Solution Explorer. On the Project menu, click Properties (or right-click the project node in Solution Explorer, and then click Properties).
  2. In the Project Designer, click the Signing tab.
  3. Select the Sign the assembly check box.
  4. In the Choose a strong name key file drop-down list box, click Browse.
  5. In the Select File dialog box, navigate to the key file you created or enter its path in the File name box. Click Open to select it.
  6. Close the Properties window and save the changes.

The application block unit tests are in assemblies that are separate from the application block assemblies. To give the unit test assemblies access to the application block assemblies' internal types and members, the application blocks use the InternalsVisibleTo attribute. You must update this attribute to include the public key of the strong-named assemblies.

To update the InternalsVisibleTo attribute

In Visual Studio, point to Find and Replace on the Edit menu, and then click Find in Files.

Search the entire solution for the InternalsVisibleTo attribute.

For each occurrence of the InternalsVisibleTo attribute, follow these steps:

  1. Copy the full public key (not the token) that you extracted from the key pair.
  2. Add the public key to the attribute, as shown in the following example.
  3. Save each file you changed.

Rebuild the entire solution.