mirror of
https://github.com/DapperLib/Dapper.git
synced 2026-10-17 05:12:13 +08:00
Marc Gravell
8baab07773
2.1.86 shipped Dapper.StrongName and Dapper.EntityFramework.StrongName with an all-zero strong-name signature, so they fail strong-name validation when loaded on .NET Framework. Comparing the shipped assemblies: 2.1.79 sig 128B, nonzero=127 real signature 2.1.86 sig 128B, nonzero=0 public-signed only Both projects carried <PublicSign Condition=" '$(OS)' != 'Windows_NT' ">true</PublicSign> Public signing stamps the public key and sets the STRONGNAMESIGNED flag but writes no actual signature: the assembly claims to be strong-named and is not. .NET Core and later do not verify strong names, so only .NET Framework consumers see the failure. The condition never fired in practice because releases were packed by hand on Windows. release.yml now builds on ubuntu-latest, so it fires on every release - this is a regression introduced by #2230, not by anything in the signing setup. The condition is a legacy workaround from when Roslyn could not fully sign off Windows; it can now. Removing it rather than moving the release job to Windows fixes the cause instead of avoiding it, and keeps a Linux developer build honest too. Verified on Linux: a full Build.csproj pack produces real 128-byte signatures for every TFM of both packages. Dapper.snk is unchanged - untouched since the commit that added Dapper.StrongName - so the public key token is identical and this is a signature fix, not an identity change. Windows builds are unaffected: the condition was already false there.