Strong Naming an Assembly using the Project settings in VS2005

[Guest]

You get warnings when compiling a project that is using the AssemblyKeyFile
attribute. It recommends changing this to use the compiler option.
I read about this and the reasons sound good, HOWEVER signing using project
settings require that the snk file exists in the project directory. In fact,
if it doesn't and you browse to the file through the UI it copies it to the
local directory and adds it to your project.

Is there a reason this won't take the key file from a relative path? I do
not want to have to have the key file in every project I create. It would be
better if the key file was in one place and all projects just referred to the
same key file in a common top level directory.

Thanks.

 

[Nicole Calinoiu]

If you add the snk file to your project as a linked file, you should be able
to specify the relative path without a local copy being made. (See the
"Adding an Existing Item as a Link" section at
http://msdn2.microsoft.com/en-us/library/9f4t9t92 if you're not sure how to
add a linked file to a project.)

 

[Guest]

Thanks for your response Nicole!
I tried that but it still looks for the file in the local directory. It
doesn't seem to honor a link.

 

[Nicole Calinoiu]

It works for me in the August CTP, but I don't recall if I tried using
linked key files in earlier releases, so the problem might lie with the
release that you're using. However, just in case it has something to do
with how you're trying to specify the key, you might want to try these
steps:

1. Remove all strong naming key attributes from the project code.
2. On the "Signing" tab of the project properties window, specify that the
assembly should not be signed.
3. Remove any existing linked key files from the project.
4. Save the project/solution.
5. Add your desired key file to your project as a linked file.
6. On the "Signing" tab of the project properties window, specify that the
assembly should be signed and select the linked key file from the list (the
target file path will probably be displayed in the list even though the file
is linked).
7. Save and compile the project.

 

[Guest]

Thank you Nicole. I figured out why it didn't work the first time.
The keys were stored in a file with a .keys extension instead of the .snk
extension.
If I change the file to have the snk extension, everything works as expected.

Thanks again,

Chris

 

[Keith Patrick]

You want to sign a bunch of different assemblies with the same key? That
kinda goes around the notion of a strongly-named assembly, as the unique ID
is now shared among assemblies, and if any assembly had the filename changed
to that of one also signed with this key, then the runtime would consider
both assemblies to be the same.

 

[Nicole Calinoiu]

You want to sign a bunch of different assemblies with the same key? That
kinda goes around the notion of a strongly-named assembly, as the unique
ID is now shared among assemblies, and if any assembly had the filename
changed to that of one also signed with this key, then the runtime would
consider both assemblies to be the same.

No, it won't. The signature is just one of several elements that form an
assembly's strong name. (The others are the assembly text name, version,
and culture.) There is nothing at all unusual about signing multiple
assemblies with a single strong naming key. In fact, in a small development
shop, all assemblies might typically be signed with the same key. Larger
groups may prefer to use separate keys for separate product lines (for
example, Microsoft uses a different key for SQL Server assemblies than it
does for .NET Framework assemblies). However, signing each and every
assembly with a different key is essentially a pack of hassle with little
real benefit.

 

[Keith Patrick]

Is there an MS doc that discusses best practices on this? Granted, you are
probably going to have a unique name within your company using a single SNK,
with shared ones, it becomes that much easier to have a name collision.
Let's say two teams share a common key file among products. If each had a
DLL within their product named "Common.dll", what happens if they aren't
careful and share the same key file among the two DLLs? They are different
DLLs in functionality and code branch, but because their canonical name is
the same, and because culture and version can also collide, the one truly
unique differentiator is contaminated, meaning those two files could get
mixed up but the runtime wouldn't know better. Even if the key is kept in
the same product family, who is to say that filenames won't change in the
future?
I personally would just rather grant each assembly a key file (it's a couple
of clicks in the Properties tab) and not worry about cross-contamination.

 

[Bjarke Lindberg]

I personally would just rather grant each assembly a key file (it's a couple
of clicks in the Properties tab) and not worry about cross-contamination.

I disagree here. A company should only use a single key, or maybe a key
for each development department. If you're using best practice naming
your assemblies, they'll never share the same name. It'll be something
like "<CompanyName>.<Technology>.<WhatEver>". It is much easier to
administrate the delay signing of assemblies before release, and it'll
make it possible to use the StrongNameIdentityPermissionAttribute in a
usefull way.

If you know the company always uses the same key, it's easier to
administrate the grant of full trust to a single companys assemblies.

/B.signing

 

[Nicole Calinoiu]

Is there an MS doc that discusses best practices on this?

I've never seen one.

Granted, you are probably going to have a unique name within your company
using a single SNK, with shared ones, it becomes that much easier to have
a name collision. Let's say two teams share a common key file among
products. If each had a DLL within their product named "Common.dll", what
happens if they aren't careful and share the same key file among the two
DLLs?

This is one possible rationale for assigning different keys to different
teams. However, it's also a scenario that is easily addressed by setting up
assembly naming policies.

They are different DLLs in functionality and code branch, but because
their canonical name is the same, and because culture and version can also
collide, the one truly unique differentiator is contaminated, meaning
those two files could get mixed up but the runtime wouldn't know better.
Even if the key is kept in the same product family, who is to say that
filenames won't change in the future?
I personally would just rather grant each assembly a key file (it's a
couple of clicks in the Properties tab) and not worry about
cross-contamination.

The main problem there lies in management of the private keys. With a key
per assembly, how would you protect these? How would you even know if one
has slipped outside your key management process?