Signing the assemblies

Topics: General
May 30, 2012 at 3:57 PM

I'm building the assemblies from source. I want to give them to the dev teams working on projects that use aspnetwebstack, but I need to produce signed assemblies.

When I try to sign one of the assemblies, I get the following:

sn -R bin\release\System.Json.dll tools\35MSSharedLib1024.snk

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.1
Copyright (c) Microsoft Corporation.  All rights reserved.

Failed to re-sign the assembly -- The parameter is incorrect.

Any ideas what is going on here???

Coordinator
May 30, 2012 at 4:49 PM

Hi,

That key is a test-signing key used for delay signing. All the c# projects in the source tree are already set up to use that key, so there is no additional signing step to take. Test-signing is, as the name implies, for testing purposes, and not for deployment. We can't give our the full Microsoft key because it is effectively the same as a password. If we give it out it would be like giving our top secret Microsoft key away.

The nightly signed builds that we publish on MyGet use the real key.

To run the test-signed assemblies you need to run the SkipStrongNames utility that we describe in the setup steps. This must be done on every machine that you want to run the product on. To run nightly signed builds you don't need anything special at all.

Thanks,

Eilon

May 30, 2012 at 10:12 PM

Thanks. I didn't realize that; I thought there'd be a key to use for the open source version that would be different than the eventual commercial version.

I'll try the packages from MyGet.

Coordinator
May 31, 2012 at 3:34 AM

Sorry, we don't have a key for that purpose. You could, however, generate your own strong name key and sign the DLLs with that key. However, because it would have a different strong name key, you wouldn't be able to use DLLs that depend on the official Microsoft-signed DLLs. For example, the Web API Contrib project builds against the official Microsoft-signed Web API DLLs and would not work against your custom-signed DLL unless you also recompiled Web API Contrib to point to the new DLL.

All in all I think that using the nightly builds is the best bet if you want to stick to the official DLLs and ensure the best compatibility. But the good news is that even if you want to build the DLLs yourself you still have lots of options!