Delay Signing an Assembly

An organization can have a closely guarded key pair that developers do not have access to on a daily basis. The public key is often available, but access to the private key is restricted to only a few individuals. When developing assemblies with strong names, each assembly that references the strong-named target assembly contains the token of the public key used to give the target assembly a strong name. This requires that the public key be available during the development process.

A delayed or partial signing can be used at build time to reserve space in the portable executable (PE) file for the strong name signature, but defer the actual signing until some later stage (typically just before shipping the assembly).

The following steps outline the process to delay sign an assembly:

1. Obtain the public key portion of the key pair from the organization that will do the eventual signing. Typically this key is in the form of an .snk file, which can be created using the Strong Name tool (Sn.exe) provided by the .NET Framework SDK.

2. Annotate the source code for the assembly with two custom attributes from System.Reflection:

i. AssemblyKeyFileAttribute, which passes the name of the file containing the public key as a parameter to its constructor.

ii. AssemblyDelaySignAttribute, which indicates that delay signing is being used by passing true as a parameter to its constructor. For example:

sn –Vr myAssembly.dll

CAUTION Use the -Vr option only during development. Adding an assembly to the skip verification list creates a security vulnerability. A malicious assembly could use the fully specified assembly name (assembly name, version, culture, and public key token) of the assembly added to the skip verification list to fake its identity. This would allow the malicious assembly to also skip verification.

5. Later, usually just before shipping, you submit the assembly to your organization's signing authority for the actual strong name signing using the –R option with the Strong Name tool.

The following example signs an assembly called myAssembly.dll with a strong name using the sgKey.snk key pair.

sn -R myAssembly.dll sgKey.snk

Creating a Setup project for distributing components

Using the Deployment tools in Visual Studio .NET developers can create Windows Installer (.msi) files that can be distributed and installed on other computers. As the requirements and specifications of various projects are different the deployment method is also varied. The components that we design are usually shared between several projects and in this case we use Merge Module Project to create a setup project for distributing components. This method creates a merge module file with an extension .msm. This file includes all files, resources, registry entries, and setup logic for the component. This .msm file that we create can be merged into other deployment projects. This method allows us to have a consistent installation of the components across multiple applications.

Creating a new merge module project

On the file menu, Choose Add Project and click on New Project

• In the dialog box Add new Project dialog box and select setup and deployment projects.
• Choose Merge Module Project
• A new Merge Module project is created.

The assembly of the component can be added to the module and the module can be built.

In this window developers can choose the assembly of the component that has to be distributed.

The above graphic shows the successful creation of the project.

To Add an Existing merge module project to a solution:

1. On the File menu choose Add Project and then Click on exiting project

2. A dialog box Add Existing Project opens. Browse to the location of the merge module project and click open.

The above graphic shows the menu for adding existing project.

The above graphic shows the merge module successfully built including the newly added module.

First Page: Shared Assembly