Welcome to MSDN Blogs Sign in | Join | Help

Sharing a Strong Name Key File Across Projects

v2.0 of the .NET Framework deprecated the use of the AssemblyKeyFileAttribute and AssemblyKeyContainerAttribute.  Often times, these attributes were used to share a common key file across several projects.

If you try to share key files using the Visual Studio 2005 <Browse ...> function on the signing property page, you'll find that the key file is copied into your project directory.  In a lot of cases this is exactly the desired behavior since it helps to group all of the artifacts that go into building your project into one location.  However, it is a common requirement that the key file not be copied into every project directory and instead referenced from a single common location.  You can still pull this off using Visual Studio 2005:

Step 1: Add the key file to your project using the Add Existing Item menu.

Add an existing item to the project

Step 2: In the add dialog, instead of choosing to add the key directly (which will make a copy into your project directory), hit the arrow next to the Add button and choose to add the key as a link.

Add a link to the key

Step 3: Go to the signing page of the project properties.  Your key file should now be on the drop down list of available keys.

Select the key on the signing page

Since the key is already a part of the project, Visual Studio will not  make a new copy of it.  One thing to notice, Visual Studio will reference your key as a relative path from the project file.  This may be exactly what you want -- but if you'd rather have a hard coded path, you can open up the project file and change the AssemblyOriginatorKeyFile (and the Include path of the Link to your key).

You'll also want to make sure that on the property sheet of the key file, the Build Action is set to None and Copy to Output Directory is set to "Do not copy" -- You don't want to accidentally start distributing your key file as an embedded resource!

Finally, there are a couple of tweaks you can make for asthetics. After setting up signing, some people like to add the key as a solution item, then edit the project files and add a <Visible>False</Visible> tag to the None tag including the key.  This presents the key in the Solution Explorer at the solution level rather than in each individual project.

Personally, I like to see the key file that each assembly will be signed with, but I don't want it cluttering the root level of the project's files.  The tweak I make is to edit the project files and change the Link tag to have a Properties prefix.  For instance, I might have:

<ItemGroup>
  <None Include="..\App.snk">
    <Link>Properties\App.snk</Link>
  </None>
</ItemGroup>

This puts the key in the properties node of the project, which I think is a more appropriate location for it than the project root.

Published Monday, April 24, 2006 10:00 AM by shawnfa

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# Visual Studio 2005 and sharing key files

Tuesday, April 25, 2006 2:53 AM by Erno de Weerd

# re: Sharing a Strong Name Key File Across Projects

Tuesday, April 25, 2006 8:54 AM by Chris
I went through defining the same process for my company a few weeks ago. An interesting behavior is that once you perform the above steps and get the key file into your projects property pages, you can then go and delete the linked file. The signing page will remain as it was.

Regards,
Chris

# re: Sharing a Strong Name Key File Across Projects

Monday, May 01, 2006 3:43 PM by Matt
Quick question...Is there a problem with security using one SNK for all your projects/assemblies?  or would it be better to create one SNK for each project/assembly?

# re: Sharing a Strong Name Key File Across Projects

Monday, May 01, 2006 4:52 PM by shawnfa
Nope -- that should be fine.

# re: Sharing a Strong Name Key File Across Projects

Tuesday, May 02, 2006 2:13 PM by JohnnieK
Can someone tell me if developers can realistically develop their code using delayed signing?  VS 2005 even tells me that I will not be able to run or debug my assemblies when I check the "Delay Sign Only" checkbox in my project properties page.  I went ahead and used the delayed signing option and sure enough my project would not run.  I used the "sn.exe -Vr *,<publicKeyToken>" command, which allowed my assemblies to run outside of VS, which is something, but I could not debug/run within VS.  I'm thinking that developers should not use keys at all and following our nightly build I'll make a copy of our assemblies and sign them using "sn" for use by QA.  Is that crazy?

# re: Sharing a Strong Name Key File Across Projects

Tuesday, May 02, 2006 2:44 PM by JohnnieK
Oops, I'm wrong.  After signing I was able to run the VS project.  Any tips to make the developer's life easier when using delayed signing?

# re: Sharing a Strong Name Key File Across Projects

Wednesday, May 03, 2006 4:52 PM by syed
Is this possible in vs 2003?

# re: Sharing a Strong Name Key File Across Projects

Thursday, May 04, 2006 1:18 AM by v.v..s.kumar
hi,

ur information is very very good . but same public key generating to assemblies.Is it possible to generate different public key to assembly using same SNK file.
 

thanks
v.v.s.kumar

# re: Sharing a Strong Name Key File Across Projects

Thursday, May 04, 2006 11:01 AM by Brad
I think the bigger problem with signing .NET assemblies via the Properties page is that you end up with multiple copies of your SNK file floating around.  Also, you usually end up checking in the SNK file along side the source code.  All that just feels unsecure to me...maybe I'm being too paranoid.

I sign my .NET assemblies in 1 of 2 ways:
1. the old fashioned way, with the AssemblyKeyFile attribute in the AssemblyInfo.cs (making sure I can still compile despite the deprecation warning)
2. creating a key container (/i) and adding a KeyContainerName in each of my CSPROJ files.

# re: Sharing a Strong Name Key File Across Projects

Thursday, May 04, 2006 11:30 AM by shawnfa
Hi Johnnie --

Well I know for sure it's possible to use delay signing in a production environment, since that's how we build the .NET Framework :-)  You're right that VS doesn't have great support for it though, since you'll have to manually do the skip verification step.

On the CLR team, we have a setup script to install builds of the runtime.  As part of that script, we register our keys for skip verification so that our delay signing system works.

-Shawn

# re: Sharing a Strong Name Key File Across Projects

Thursday, May 04, 2006 11:31 AM by shawnfa
V.V.S. Kumar -- it's not possible to do that since public and private keys are mathematically related and tied together. If you want two different public key tokens then you'll need to use two different private keys to generate their signatures.

-Shawn

# re: Sharing a Strong Name Key File Across Projects

Thursday, May 04, 2006 11:34 AM by shawnfa
Brad,

We actually deprectaed those attributes due to information leakage -- they end up in your final assembly and people can use that to deduce information about your build environment.  (For instance, you can tell that the Microsoft key for v1.1 of the framework was stored on E:\com99\bin\EcmaPublicKey.snk on the build machine.  If it's on a share you might be able to deduce some machine names in the build network).  This may or may not be a concern for you.

This post itself was about solving the multiple copies of the SNK file problem though ...

-Shawn

# re: Sharing a Strong Name Key File Across Projects

Friday, May 05, 2006 12:27 PM by Walter Mitty
Why did this change?  It wasn't broken in VS 2003 and now VS 2005 just makes it harder to achieve.  The feature could have been added without to 2005 without removing the old functionality.

# .NET Resources

Saturday, May 06, 2006 4:31 AM by mattonsoftware.com
The following links to .NET resources have been collated over time with the assistance of colleagues.&amp;nbsp;...

# re: Sharing a Strong Name Key File Across Projects

Monday, May 08, 2006 11:00 AM by John Vottero
Isn't using a key container the best way to manage private keys?  It's easy to steal a private key when it's in a .snk file.  I *think* it's hard to steal a key that's stored in a key container.  It's also easier to manage, even across different solutions.

VS 2005 broke key containers because it depricated AssemblyKeyName without providing a replacement.  We still manage to use them by editing the .csproj file and adding <KeyContainerName>TheName</KeyContainerName>

John

# re: Sharing a Strong Name Key File Across Projects

Monday, May 08, 2006 11:08 AM by Dave Comer
Is there a good reference to how to use this approach with a key file stored on a smart card?

# re: Sharing a Strong Name Key File Across Projects

Monday, May 08, 2006 12:41 PM by shawnfa
Key containers require being setup on the client machine, and can be ACLed.  However SNK files can also be ACLed.  Since key containers require machine setup, there's no way to check a project out of source control and just build it.

On the CLR, we keep the public key files checked into source control, and then pass them over to a carefully guarded machine on Microsoft to do the final signing.

If you want to protect your keys, I recommend using a self signed certificate instead.

-Shawn

# re: Sharing a Strong Name Key File Across Projects

Monday, May 08, 2006 12:41 PM by shawnfa
Check out Ivan's blog http://dotnetthis.com/Articles/SNandSmartCards.htm for information on signing with a smart card.

-Shawn

# re: Sharing a Strong Name Key File Across Projects

Saturday, May 13, 2006 11:54 AM by Heath Stewart
For everyone wondering about previous versions of VS (and this is possible in 2005 as well), you can store the key pair that you create in VS in a store. It's one of the options when you create the key (and can be done using sn.exe as well). Instead of using a file, get it from the container. For those using older versions of VS, use the AssemblyKeyNameAttribute instead of the AssemblyKeyFileAttribute. The name is whatever the name of the key pair you put into the store.

# re: Sharing a Strong Name Key File Across Projects

Monday, May 15, 2006 12:35 PM by shawnfa
Right.  However, be aware that using a key container instead of a key file does require that development and build machines run some setup before they can produce a build of your product.

-Shawn

# re: Sharing a Strong Name Key File Across Projects

Monday, May 15, 2006 8:38 PM by Mitch
We ran into the same issues on our project (wanting to use a common keyfile) and came up with a similar, but different solution.

Instead of using the linking option in VS2005, we make use of an environment variable.  We simply update the ".csproj" file to set the "SignAssembly" property to "true" and the "AssemblyOriginatorKeyFile" to the environment variable to use (e.g. $(MY_KEY_FILE) ).

This is nice because the developers can build with their own keyfile, and the CM can build on their machine with the real keyfile.  This is all done by just simply setting the environment variable.  If the environment variable is not set, then it will create assemblies that are not signed.

Once the project file is updated initially, you can run any of these permutations without needing to update the project file again.  Very flexible.

(Additionally, you can override the value in the projects by invoking msbuild with the "/p:AssemblyOriginatorKeyFile=" option if you don't want to mess with environment variables in your scripts.

-Mitch

We decided to use an environment variable to point to the keyfile.  Then

# re: Sharing a Strong Name Key File Across Projects

Monday, May 15, 2006 8:52 PM by shawnfa
That's a great tip Mitch!

-Shawn

# re: Sharing a Strong Name Key File Across Projects

Saturday, May 20, 2006 2:40 PM by hema
I am working in VS.Net 2000.

can you please tell me the sharing a strong name in that version.

Also I wish to develop a webservice in .net and to call it in Visual Basic.kindly help me to do this

# re: Sharing a Strong Name Key File Across Projects

Tuesday, May 23, 2006 7:38 PM by shawnfa
Hi Hema,

There was no Visual Studio 2000, so I assume you mean either 2002 or 2003.  In those versions, you can just have the AssemblyKeyFileAttribute point at the same location.

-Shawn

# re: Sharing a Strong Name Key File Across Projects

Wednesday, May 24, 2006 10:50 AM by Slava Brosgol
How key file sharing will affect application publishing (click-once)?

# re: Sharing a Strong Name Key File Across Projects

Wednesday, May 24, 2006 12:57 PM by shawnfa
It shouldn't have any affect on ClickOnce at all.

# I can&#8217;t remember where I read it&#8230;. &raquo; Sharing Strong Name Keys Across Multiple Projects In VS2005

# DaveZ's TFS Tome : Signing Assembly Tricks

Friday, October 20, 2006 3:13 PM by DaveZ's TFS Tome : Signing Assembly Tricks

# Lars Wilhelmsen &raquo; Blog Archive &raquo; links for 2006-12-18

Sunday, December 17, 2006 7:35 PM by Lars Wilhelmsen » Blog Archive » links for 2006-12-18

# Strong Named Key File Per Solution

Monday, January 08, 2007 11:25 AM by RoBlog

Strong Named Key File Per Solution

Leave a Comment

(required) 
required 
(required) 

  
Enter Code Here: Required
 
Page view tracker