Fully sign the StrongName assemblies on every platform - #2237
Merged
Merged
Conversation
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.
This was referenced Sep 23, 2026
This was referenced Sep 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Dapper.StrongNameandDapper.EntityFramework.StrongName2.1.86 fail strong-namevalidation on .NET Framework: they shipped with an all-zero signature blob.
Evidence
Signature blob of the shipped
Dapper.StrongNameassemblies:Same for
Dapper.EntityFramework.StrongName.Dapperand the other packages are notstrong-named and are unaffected.
Cause
Both projects carried:
Public signing stamps the public key and sets the
STRONGNAMESIGNEDflag but writes noactual signature — the assembly claims to be strong-named and isn't. .NET Core and later
don't verify strong names, so only .NET Framework consumers hit it.
The condition never fired before because nuget.org releases were packed by hand on Windows.
release.yml(added in #2230) builds onubuntu-latest, so it now fires on every release.This is a regression introduced by #2230.
Fix
Remove the condition so every platform fully signs. That
PublicSigndance is a legacyworkaround from when Roslyn couldn't fully sign off Windows — it can now. Fixing the cause
beats moving the release job to Windows to avoid it, and it keeps Linux developer builds
honest as well.
Verified locally: a full
dotnet pack Build.csprojon Linux produces real 128-bytesignatures for every TFM of both packages.
Dapper.snkis unchanged — untouched since the commit that introducedDapper.StrongName—so the public key token is identical. This is a signature fix, not an identity change, and
Windows builds are unaffected (the condition was already false there).
After merging
Release 2.1.87, then unlist the two broken 2.1.86 StrongName packages on nuget.org.