Ramon Smits

Tell me your secrets and i'll tell you mine

Recent Posts

Tags

Community

Email Notifications

Patterns & Practices / Guidelines

EntLib

Nant

Blogs that I monitor

Archives

Use command line option '/keyfile' or appropriate project settings instead of 'AssemblyKeyFile'

I got the following error after converting an old project.

Use command line option '/keyfile' or appropriate project settings instead of 'AssemblyKeyFile'

So I did what it asked me and then suddenly it added my keyfile to my project! Well... that wasn't really what I wanted because now it would be part of my project that is saved in my code repository (subversion by the way..). So I did a rollback (sometimes having version control is a big plus), run the build again and voila the warning appeared again. My fingers hit the F1 button to see what the microsoft help propaganda had to say about this and then the following text appeared:

There were security issues due to the attributes being embedded in the binary files produced by the compiler. Everyone who had your binary also had the keys stored in it.

Well I was in shock when I read this. But this is an error I presume? Shouldn't this be "Everyone who had your binary also had the PUBLIC keys stored in it" ? Well I hope that is the case or else my strongnamed assemblies would be worth shit security wise!

So I continued reading and read the following:

There were usability issues due to the fact that the path specified in the attributes was relative to the current working directory, which could change in the integrated development environment (IDE), or to the output directory. Thus, most times the key file is likely to be ..\\..\\mykey.snk. Attributes also make it more difficult for the project system to properly sign satellite assemblies. When you use the compiler options instead of these attributes, you can use a fully qualified path and file name for the key without anything being embedded in the output file; the project system and source code control system can properly manipulate that full path when projects are moved around; the project system can maintain a project-relative path to the key file, and still pass a full path to the compiler; other build programs can more easily sign outputs by passing the proper path directly to the compiler instead of generating a source file with the correct attributes.

Well yes! Exactly.. that is why I wanted to use the attribute this way! :) But they are correct with all that relative path mess so I thought let's install the keypair in a key container. This is all working well with the good old AssemblyKeyName attribute! But now again a compiler warning.

Use command line option '/keycontainer' or appropriate project settings instead of 'AssemblyKeyName'

So I browsed the project properties to see if there is an option to select a key container to sign the assembly but that isn't possible. Opening the project file (*.csproj) revealed an element named AssemblyKeyContainerName but Microsoft Visual C# 2005 Express Edition doesn't use it when compiling because the resulting output is still unsigned.

The help doesn't show me how to use a key from a container so I am currently stuck with leaving the last warning as is.

If anybody knows how to solve this then leave your comment please :-)

Update:
I can atleast disable the warning with the new #pragma keyword (found that one here, it also shows a different settings screen then in VC#2005 ED).

#pragma warning disable 1699
[assembly: AssemblyKeyName(@"MyCoolKeyContainer")]
#pragma warning restore 1699

Comments

Arundhati said:

# May 31, 2006 3:16 PM

simon831 said:

# March 2, 2007 3:02 AM

Dipen said:

In VS 2008 open the project properties and from signing tab check Sign the Assembly and choose the strong key file and save the project

# December 31, 2009 6:50 PM

hfrmobile said:

I also think that the AssemblyInfo.cs / Attrbiute is the correct location where to do that!

Imagine if you use a NAnt build and the <csc> tag. So you have to provide the .snk also here ...

Keep DRY! (Don't Repeat Yourself) (which is not possible when providing the .snk in project file AND build script)

So the solution/workaround disabling the warning is helpful!

If the keyfile could'nt be found when the build runs then you'll get an error and it will not be possible that the build succeeds without strong-naming the assembly. Again: DRY ;-)

Thank you for that hint!

# December 4, 2010 5:09 PM

hfrmobile said:

I also think that the AssemblyInfo.cs / Attrbiute is the correct location where to do that!

Imagine if you use a NAnt build and the <csc> tag. So you have to provide the .snk also here ...

Keep DRY! (Don't Repeat Yourself) (which is not possible when providing the .snk in project file AND build script)

So the solution/workaround disabling the warning is helpful!

If the keyfile couldn't be found when the build runs then you'll get an error and it will not be possible that the build succeeds without strong-naming the assembly. Again: DRY ;-)

Thank you for that hint!

# December 4, 2010 5:10 PM
Leave a Comment

(required) 

(required) 

(optional)

(required) 


Please add 6 and 2 and type the answer here: