SGEN with delay-signing on 64-bit Server

Question

I'm trying to resolve a problem where SGEN is throwing an error when invoked as part of my .NET solution build on a build server. I'm running the build from the command-line on the server to eliminate the CI server as a factor.

The specific error message supplied is:

SGEN : error : Could not load file or assembly 'MyAssembly.dll, Version=0.0.0.0, Culture=neutral, PublicKeyToken=56e8273d901d717f' or one of its dependencies. Strong name validation failed. (Exception from HRESTULT: 0x013141A)

There are no other errors produced by running the build script from the command-line.

The assembly in question is a delay-signed assembly, built with a public key matching the specified token.

On the server, I have registered the key token for verification skipping using the sn.exe tool (*,56e8273d901d717f), as this is required to run some of the testing steps of the build process before the full signing stages are attempted.

The build process works successfully on developer desktops and on a Win2K3 server. I'm running these tests on a new Win2k8R2 server, which is to replace the older box.

Answer 1

The issue lies with the sn.exe tool.

Although I've added the verification-skip entry to the server, the SGEN tool was not looking at this, because it was running as a 64-bit process and the sn tool was the 32-bit version (despite existing in the 64-bit "Program Files" folder).

• The 32-bit sn.exe lives at C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\sn.exe.
• The 64-bit sn.exe lives at C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\x64\sn.exe

These two tools write to completely independent registries - verification must be added to either depending on the "bit-ness" of the .NET installation on the machine and the "bit-ness" of the exe being invoked.

Registering an entry with the 64-bit sn.exe has resolved the problem.