Signing Assemblies With C# in Whidbey


You may be in for a surprise when you try to rebuild your strongly named assemblies written in C# under Whidbey for the first time. If you’re using the AssemblyKeyFile attribute, you’ll get a warning similar to this:



signed.cs(4,11): warning CS1699: Use command line option ‘/keyfile’ or appropriate project settings instead of ‘AssemblyKeyFile’


Warning CS1699 directs you to use the C# compiler’s /keyfile option to sign your assemblies, rather than using the AssemblyKeyFile attribute. Although AssemblyKeyFileAttribute will still work on Whidbey, it’s recommended you move to /keyfile for several reasons.



  • AssemblyKeyFile embeds the path to the .snk file into your assembly. (For instance, if you ildasm mscorlib.dll, you can see that the machine Microsoft builds the CLR on stores the key in “E:/com99/bin/EcmaPublicKey.snk”). This kind of information disclosure is generally bad. Although it’s not a direct threat, oftentimes things like server names and user names are in this path.
  • Using relative paths with the AssemblyKeyFile attribute gets confusing. When building from Visual Studio, you generally have to prefix the file with “..\..\”, whereas when compiling from the command line, this is often not needed. This is because when the attribute starts looking for the key, it’s actually starting from the output location.
  • It’s another warning in your build. If you’re treating warnings as errors, you may not even be able to finish the build until you make the change.

Fixing this for Whidbey will be relatively painless, just remove the attributes and set the compile flag in your build system. If you’re using Visual Studio to build, from the project properties you can go to the new signing tab, and select the key you want to use. This page will also let you generate and password protect a new key. In addition to key files, the signing property page has options to delay sign or use a key container.

VS Whidbey Assembly Signing Tab

As a last resort, if these warnings are blocking you from getting builds out, you can temporarily disable them using code like the following:



// disable warning about using /keyfile instead of AssemblyKeyFile
#pragma warning disable 1699
[assembly:AssemblyKeyFile(“test.snk”)]
#pragma warning restore 1699


This change also affects key containers as well; you’ll get the warning 1699 unless you switch to using the /keycontainer command line switch.

Comments (16)

  1. That’s a great feature!

  2. Its about time Ms decided to make code signing more secure and easily maintainable, nice one Microsoft, now lets get our hands on Whidbey !!

  3. We’ve already talked about using the /keyfile or /keycontainer switches to sign C# and VB assemblies…

  4. Derek Wilson says:

    Am I missing something here?

    I understand that this mechanism is a better idea than using the old attributes however I am using VS2005 Beta 2 and the project properties sheet does not have a UI for the KeyContainer. It does have a UI for the KeyFile but I really do not want the keyfile copied around to every project.

    How can I set /keycontainer switch from the UI in VS2005 Beta2?

  5. I’m having the same problem as Derek, and frankly, can’t understand why having the key in the CSP should cause a warning to be emitted (the whole KeyFile concept with relative paths was broken, but referencing the CSP seems a lot better than having to hand-compile my projects using /keycontainer or /keyfile).

    Can I at least hand-edit my project files to support this? Anyone? :)

  6. Ok, figured it out: Adding <Container>yada</Container> within the <AssemblyKeyContainer> tag works and VS no longer complains while compiling..

  7. I understand the information disclosure issue, and that using the command line switches will fix it. What I don’t understand is why the compiler adds the custom attribute metadata to the assembly. The [AssemblyKeyFile] attribute is a message to the compiler, it is not used by the runtime and AFAIK no user code uses it, so why did the compiler writers add it to the assembly as metadata? I think a simpler solution would have been to prevent the generation of the metadata

  8. . says:

    What are the pros and cons, tradeoffs

    between compile options keycontainer and keyfile (formerly attributes AssemblyKeyName and AssemblyKeyFile)?

    Also why does VS2005 only provide support for keyfile, but not for keycontainer?

    Thanks.

  9. Richard, the compiler adds the custom attribute metadata to the assembly because that is how other custom attributes work as well. You can even create your own custom attributes and use them, then their data will be there (create a class that extends from ‘System.Attribute’ and add it to the AssemblyInfo.cs file ‘[assembly: MySignatureAttribute("Jason was here!")]’). I don’t think these should have ever been made into custom attributes to start with for this reason, they are really to tell the compiler where to find the file.

  10. Microsoft has released a beta version of a new blog authoring tool called Windows Live Writer . I’ve

  11. One of the early frustrating features of 2005 initially was the deprecated ability to specify where your