When testing delay signed assemblies using VS test projects, we sometimes got security strong name validation errors. Why? According to [2], this should not happen, as quoted:

“So to give the developer a fighting chance to debug and test his code, he needs a way to make it look like the assembly has a strong name. Delay signing uses a temporary private key and puts data in his registry that records that this temporary key is a substitute for the real one. The CLR looks for this registry key when it checks the strong name, giving the okay when it finds it.

So everything works like it normally does. As long as it is done on the specific machine that delay-signed the assembly”

We can fix this problem [3] by x32 or x64 version of sn using the following line.

sn.exe -Vr *,PUBLIC_KEY_TOKEN_HERE

We can verify the entry in the registry at

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\StrongName\Verification

If above method also fails, we might have to use a technique called conditional configuration [1]

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
   <SignAssembly>true</SignAssembly>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
   <AssemblyOriginatorKeyFile>Xyz.snk</AssemblyOriginatorKeyFile>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
   <DelaySign>true</DelaySign>
</PropertyGroup>

 

References:

1. https://blogs.msdn.microsoft.com/mcsuksoldev/2013/05/23/unit-testing-delay-signed-assemblies-on-the-hosted-tfs-build-service/

2. https://stackoverflow.com/questions/21902883/my-delay-signed-assembly-is-debugging-why-is-it-like-this

3. https://stackoverflow.com/questions/5784910/how-to-unit-testing-delay-sign-assemblies-using-nunit

4. https://bartwullems.blogspot.com/2016/08/

5. https://windows-hexerror.linestarve.com/0x8013141A

Advertisements