Dapper.StrongName 2.1.86 fails strong-name signature verification (all TFMs) — works in 2.1.79

[GlennCameronNZ]

Description
Dapper.StrongName 2.1.86 fails strong-name signature verification (sn -vf) on every target framework build in the NuGet package, while 2.1.66 and 2.1.79 pass. This breaks loading on .NET Framework, which enforces strong-name verification at assembly load time.

Repro
Could not load file or assembly 'Dapper.StrongName' or one of its dependencies.
Strong name signature could not be verified. The assembly may have been
tampered with, or it was delay signed but not fully signed with the correct
private key. (Exception from HRESULT: 0x80131045)

Thrown by a .NET Framework 4.8 web app referencing Dapper.StrongName 2.1.86 via PackageReference.

Verified directly with sn.exe against the DLLs extracted from the NuGet package cache (%userprofile%.nuget\packages\dapper.strongname):

> sn -vf Dapper.StrongName.dll   (2.1.86, lib\net461)
Failed to verify assembly -- Strong name validation failed.

> sn -vf Dapper.StrongName.dll   (2.1.86, lib\net8.0)
Failed to verify assembly -- Strong name validation failed.

> sn -vf Dapper.StrongName.dll   (2.1.86, lib\net10.0)
Failed to verify assembly -- Strong name validation failed.

> sn -vf Dapper.StrongName.dll   (2.1.86, lib\netstandard2.0)
Failed to verify assembly -- Strong name validation failed.

Same check against 2.1.79 and 2.1.66, all pass:

> sn -vf Dapper.StrongName.dll   (2.1.79, lib\net461)
Assembly '...' is valid

> sn -vf Dapper.StrongName.dll   (2.1.66, lib\net461)
Assembly '...' is valid

[mgravell]

Huh, that's weird. I changed the CI, but I don't know how that broke. Will investigate, thanks.

[mgravell]

Apologies. Misconfiguration in the build - it used public signing by mistake. Should be able to re-deploy tomorrow.

[mgravell]

Should be resolved in https://github.com/DapperLib/Dapper/releases/tag/2.1.89