Welcome to MSDN Blogs Sign
in | Join
| Help

.Net Security
Blog

This Blog

About

Email

Mar

April 2006

May

S

M

T

W

T

F

S

26

27

28

29

30

31

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

1

2

3

4

5

6

Syndication

RSS 2.0

Atom 1.0

Search

Go

Archives

May 2006
(1)

April 2006
(7)

March 2006
(6)

February 2006
(7)

January 2006
(9)

December 2005
(7)

November 2005
(8)

October 2005
(8)

September
2005 (11)

August 2005
(7)

July 2005
(8)

June 2005
(4)

May 2005
(10)

April 2005
(6)

March 2005
(10)

February 2005
(9)

January 2005
(10)

December 2004
(10)

November 2004
(11)

October 2004
(12)

September
2004 (10)

August 2004
(10)

July 2004
(10)

June 2004
(11)

May 2004
(7)

April 2004
(15)

March 2004
(21)

February 2004
(12)

January 2004
(3)

December 2003
(1)

November 2003
(5)

October 2003
(1)

June 2003
(2)

News

What's New
in Security for v2.0

List of
CLR Bloggers

Getting
Help with your .NET Questions

Navigation

Home

Photos

Post Categories

CAS
(79)

ClickOnce
(22)

Cryptography
(56)

Debugging
(19)

Other
(25)

Policy
(9)

Security
(161)

SSCLI /
Mono (11)

StrongName
(32)

Under
the Hood (34)

Visual
Studio (17)

Windows
(34)

XML
(18)

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.

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.

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.

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
Filed
Under: Visual
Studio, StrongName

Comment Notification

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

You can also stay up to date using your favorite aggregator by subscribing to
the CommentRss
Feed

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

#
.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;...

What do you think?

Title
(required)*

Name required*

Your URL

Comments
(required)*

Remember Me?