Welcome to MN VSTS User Group Sign in | Join | Help

Syndication

Tags

    No tags have been created or used yet.

Navigation

Signing Assemblies with a Common Key File

Microsoft recommends that all assemblies be assigned a strong name by signing them with a key file.  It is further recommended that only the build process be allowed to sign assemblies for distribution with a private key.   

In order to meet these requirements with a minimum of inconvenience to developers you can allow developers to fully sign assemblies with a developer’s key and reserve the signing with the production key for the build box.  An easy way to accomplish this is to create an environment variable on the developer’s machines that points to the developer’s key and change the value of this environment variable on the build box to point to the production key file.

The following steps are intended to help step you through the process of setting up an environment variable that points to the DeveloperKey.snk file and to then alter the project file to use this variable.  Setting up the environment variable will only need to be done once on your machine and altering the project file will only need to be done when you first create a new project.

  • Step One, Open System Properties Dialog.

The figure below shows the advanced tab of the System Properties Dialog.  You can access this dialog by selecting the system icon from the control panel

 

 

  • Step 2, Open Environment Variables Dialog

Click the Environment Variables button to open the dialog as shown in the figure below.


 

  • Step 3 Create a new variable

Click new under the user variable section of the dialog to open the New User Variable dialog shown below.  Enter the values shown below, KEY_FILE for the variable name and D:\IT\Object\Lib\DeveloperKey.snk for the variable value.

 

 

This completes the process of creating an environment variable.  This is a one time event.  As long as the DeveloperKey.snk file appears on your machine everything should compile and be strongly named with your key. 

The only other task to discuss on this topic is the alteration to a project file that must be done to take advantage of this environment variable.  This task only needs to be done once for each project as the project is created.

  • Check the project file out of source control for editing. 
  • Open the file in an editing tool.  You can use Visual Studio as long as you do not already have the project open.
  • Change the SignAssembly tag to true as shown in the figure below.
  • Change or Add an AssemblyOriginatorKeyFile tag to specify the environment variable $(KEY_FILE).
  • Check the project file back into source control.

The altered file is shown in the figure below

Published Friday, October 20, 2006 4:36 PM by cdpratt

Comments

# re: Signing Assemblies with a Common Key File @ Monday, December 18, 2006 10:21 AM

I agree that signing is important and that protecting the key is also very important.  

What isn't clear to me is the relationship

between the developer's key and production key.

Also I can't tell whether or not delay signing is being used.

The model I would advocate is the following:

1) the build lab creates the production strong name key.

2) the build lab extracts the public portion of the production key and checks it in to source control in a public area (i.e. and area where anyone who can browse the project source can access).

3) the build lab checks the complete key pair (i.e. the private part) into source control in a location that only the build lab has access to (if your SCC provider does not allow this then choose a location that is secure and backed up frequently).

4) developers get the source code as normal.  The project file has a reference to the public key which is checked into the source control system.  Since this is checked in using a well known location there is no need to use an environment variable.

5) the developers enable delay signing in their project (this is a one-time configuration change).

6) the developers enable strong-name bypassing for the key token for the public key (e.g. "sn -Vr *,<token>").

7) the developers build and debug as normal.

8) the build lab builds as normal and adds a new step to delay sign the build (this only needs to be done for builds that will be published outside of the development org).

Using this approach you get a few benefits over developer private keys.  They are:

1) the developers are using the same key token as the build lab.  Without this hardcoded token values (link demands, InternalsVisibleTo, etc) will not work as expected.

2) the build scripts can rely on a single key token instead of N+1 (N = dev count + production).

3) the MSBuild (csproj) file does not rely on an environment variable.  (if you are going to rely on an environment variable then add a condition to check that is not empty and to flag an error if it is).

4) I can create a private build and overlay my private binary onto a production build and have it work (with strong name bypassing enabled).  Otherwise the references will break when they hit my developer key.

Cheers!

RobertHorvick

# re: Signing Assemblies with a Common Key File @ Monday, January 15, 2007 4:10 PM

Thanks for the comment Robert.  I think I need to clarify a couple of things in my post based on your feedback.

1) This scenario does not use delayed signing.

2) There are only 2 keys involved.  One for all of the developers, which is checked into source control, and one for the production build.

3) The build process only uses one key and doesn't really care about where it is since the project files refer to a environment variable that is set once on the build box and never changed.

4) We do not want any developer to be able to overlay their private binary onto a production build.  This is one of the reasons for not sharing the production key with the entire team.

I hope this clears up any confusion my original post may have caused.

Thanks!

cdpratt

Anonymous comments are disabled