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

Published 26 December 5 3:20 PM | Ramon Smits
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

Filed under: ,

Comments

# Arundhati said on May 31, 2006 3:16 PM:

See if this helps..

http://davidkean.net/archive/2005/08/25/1162.aspx

# simon831 said on March 2, 2007 3:02 AM:

Have a look at this:

http://blogs.msdn.com/shawnfa/archive/2006/04/24/582278.aspx