Key Containers and Visual Studio 2005: What's Microsoft Trying To Say?

As noted in Signing Assemblies in Visual Studio 2005 with Key Containers, Visual Studio 2005 doesn't exactly deal well with key containers (there's no way to use the UI to specify one, as one can do with key files).

And when I was exploring Web Deployment Projects, I was reviewing "Managing ASP.NET Precompiled Output for Deployment Using the aspnet_merge.exe Command" (aspnet_merge.exe is used by Web Deployment Projects to combine the assemblies produced by aspnet_compiler.exe). That article states that "...you can use the following options with aspnet_merge.exe: -keyfile, -keyContainer, or -delaysign...". I'm a strong advocate of signing assemblies. While there may not be a strong (ha, ha) case for doing it in this instance, it at least provides some level of assurance that the code deployed is truly the code that is supposed to be running. And I prefer key containers to key files. So given the way that specifying a key container works in Visual Studio 2005, I was excited to see that aspnet_merge.exe supported key containers.

Then I checked out the Web Deployment Project property pages. The Signing tab had a place to specify a key file location, but no way to specify a key container.



Argh! Here we go again, I thought. So I went about the process of trying to tear up the .WDPROJ file that is the Visual Studio 2005 project file for Web Deployment Projects. I tried the same technique that worked for .CSPROJ files, but that didn't work. I checked Microsoft.WebDeployment.targets in %programfiles%\MSBuild\Microsoft\WebDeployment\v8.0 to see if there was some way to specify a key container there. I couldn't find anything for key containers, but there were certainly ways to specify a key file and that the merged assembly should be delay signed. Dead end there.

Next I cracked open Reflector and inspected Microsoft.WebDeployment.Tasks.dll (also from %programfiles%\MSBuild\Microsoft\WebDeployment\v8.0). In that assembly, there is a class named "AspNetMerge" that implements the merge task as instructed by MSBuild. (The class inherits from Microsoft.Build.Utilities.ToolTask.) The "AspNetMerge" class has the following private fields (as reported by Reflector):

    private string _applicationPath;
    private string _assemblyInfo;
    private string _contentAssemblyName;
    private bool _copyAttributes;
    private bool _debug;
    private bool _delaySign;
    private bool _errorStack;
    private string _exePath;
    private string _keyFile;
    private string _logErrorFile;
    private bool _mergeXmlDocs;
    private bool _nologo;
    private string _prefix;
    private bool _removeCompiledFiles;
    private string _singleAssemblyName

Sigh. A setting for a key container name is nowhere to be found. If the tool doesn't support key containers, no amount of creative configuration will get it there.

The next thing I did, in retrospect, was probably the first thing I should have done:

aspnet_merge -?

In short, aspnet_merge only supports the following parameters:

• -?
• applicationPath
• -keyfile
• -delaysign
• -o
• -w
• -prefix
• -copyattrs
• -debug
• -nologo
• -errorstack
• -r
• -xmldocs
• -a
• -log

Aspnet_merge.exe does NOT support the -keycontainer option, as the "Managing ASP.NET Precompiled Output for Deployment Using the aspnet_merge.exe Command" article had stated.

So, given that there's no way to use a Web Deployment Project / aspnet_merge.exe to use a key container to sign an assembly, and one needs to edit the raw .CSPROJ file to get VS2005 to use a key container to sign an assembly, it seems that Microsoft is trying to say something about key containers.

I wouldn't be surprised to see key containers completely dropped in Orcas...