Dela via

Signing Assemblies With C# in Whidbey

  • Artikel

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

  • Anonymous
    April 15, 2004
    That's a great feature!
  • Anonymous
    May 22, 2004
    Its about time Ms decided to make code signing more secure and easily maintainable, nice one Microsoft, now lets get our hands on Whidbey !!

  • Anonymous
    July 14, 2005
    We've already talked about using the /keyfile or /keycontainer switches to sign C# and VB assemblies...
  • Anonymous
    July 28, 2005
    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?
  • Anonymous
    October 01, 2005
    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? :)
  • Anonymous
    October 02, 2005
    Ok, figured it out: Adding <Container>yada</Container> within the <AssemblyKeyContainer> tag works and VS no longer complains while compiling..
  • Anonymous
    November 06, 2005
    The comment has been removed
  • Anonymous
    December 07, 2005
    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.
  • Anonymous
    December 27, 2005
    The comment has been removed
  • Anonymous
    June 21, 2006
    The comment has been removed
  • Anonymous
    August 14, 2006
    Microsoft has released a beta version of a new blog authoring tool called Windows Live Writer . I've
  • Anonymous
    October 20, 2006
    One of the early frustrating features of 2005 initially was the deprecated ability to specify where your