Assembly Delay Sign and Assembly Installation

Occasionally I receive questions about assembly delay sign and assembly installation (to GAC). In this post I’ll summary what I have seen.

1. I have this wonderful assembly foo. I made a nice MSI package to install this assembly to GAC, but it keeps failing with error 0x80131045. What is wrong?

0x80131045 is defined in CorError.h as FUSION_E_SIGNATURE_CHECK_FAILED.  It means fusion failed to validate the strong name signature of your assembly. Either your assembly is corrupted, or your assembly is delay signed. If latter, you can use “sn –Vr” to enable skipping strong name verification for you assembly.

2. OK, my assembly is indeed delay signed. I ran “sn –Vr” on my assembly. But my MSI package is still failing. Now what?

The security system (that is responsible to verify the strong name signature) caches all the  strong name verification entries. In order to let your entry to take effect, you need to flush the security system’s cache.  In the case of MSI, you need to restart the Windows Installer service.

3. Sounds good. Now I am on a 64 bit OS. I ran “sn –Vr”, and I restarted Windows Installer service. My MSI package still fails to install. You guys are killing me.

Bt patient and you will be saved:)

Strong name verification skipping entries are recorded in registry under HKLM\Software\Microsoft\StrongName\Verification. On 64 bit OS  due to registry redirection, there is a 64 bit version of it, and a 32 bit version of it. 64 bit processes read/write the 64 bit version of it, and 32 bit processes read/write 32 bit version of it.

On 64 bit OS, MSI packages are installed by Windows Installer service, which is a 64 bit process , and it will read the 64 bit version of the strong name verification skipping section. To properly register your assembly for MSI on 64 bit OS, use 64 bit version of sn.exe.

Of course, strong name verification skipping is always a security hole. If possible, consider move to Test Key Signing, to avoid the security hole.