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.
As a last resort, if these warnings are blocking you from getting builds out, you can temporarily disable them using code like the following:
#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.
