* fix CI

* try again

The IL emitted by CreateParamInfoGenerator used Callvirt to invoke
AddParameter on an unboxed struct sitting on the evaluation stack.
Callvirt expects a reference, so the CLR misinterpreted the raw struct
bytes as an object pointer, causing a fatal CLR error (0x80131506).

* first snapshot, warnings

* intermediate

* more

* more fixings

* cleanup

* nuke NETCOREAPP3_1 ref

…& LINQ (#2197)

* Add Settings.PreferTypeHandlersForEnums opt-in flag

When enabled, Dapper checks for a registered TypeHandler for enum types
before falling back to the default integer boxing behavior. This allows
custom enum serialization (e.g. storing enums as strings via TypeHandlers)
to work on both reads and writes.

Patched locations:
- LookupDbType: return DbType.Object with handler when flag is on
- CreateParamInfoGenerator: skip integer boxing when handler exists
- GetSimpleValueDeserializer: route to TypeHandler before Enum.ToObject
- Parse<T>: route to TypeHandler before Enum.ToObject

Default is false — zero behavior change for existing users.

* Patch IL-emitted type deserializer and add tests

- Fix 6th enum-before-handler location in GetTypeDeserializer IL emit,
  preserving Nullable<T> wrapping for nullable enum properties
- Fix em-dash in comment (non-ASCII)
- Add two tests: round-trip write+read via StringEnumHandler, and
  nullable enum with null value

* Update SDK version from 10.0.102 to 8.0.100

* Update global.json

we have fixed the CI glitch separately

---------

Co-authored-by: Marc Gravell <marc.gravell@gmail.com>

* keep deps up to date

* d'oh

* slnx

* Add ReferenceTrimmer and remove unused references

* Update Directory.Packages.props

latest

---------

Co-authored-by: Marc Gravell <marc.gravell@gmail.com>

The docs site now has its own domain. The old dapperlib.github.io URLs still work via a redirect, but there's no reason to keep going the long way round, and PackageReleaseNotes in particular is baked into every package we publish.

Also switches PackageProjectUrl to the docs site, matching DapperAOT; RepositoryUrl still points at the source.

Release note tracking moved to GitHub Releases some time ago; docs/index.md says so and keeps only an archive below that point. PackageReleaseNotes was still pointing at the docs root, so anyone following it from NuGet landed on the archive and had to make one more hop.

The site was running on GitHub's defaults, which take the title and description
from the repo's name and description fields - so an edit in the repo settings UI
quietly changed the site's metadata. Those are pinned now, along with the URL,
which is what jekyll-seo-tag uses to build canonical and og:url.

Also: strip_title, so the page title stops being printed twice (once in the
theme's header banner, once as the heading it was derived from); jekyll-sitemap,
which is not in the always-on GitHub Pages plugin set, for the sitemap.xml and
robots.txt the site did not have; and a favicon built from the project logo,
hooked up via the head-custom.html include the theme provides for exactly this.

Claude-Session: https://claude.ai/code/session_01NxkjXSR7CSGzyw89tJJVtw

…#2225)

* DynamicParameters.AddParameters(IDbCommand): identity-free self-apply

The full bag protocol (per-parameter DbType/direction/size, templates,
literal replacement, RemoveUnused) already lives in AddParameters(command,
identity), but the identity requirement makes it uncallable from outside:
Identity's constructor is internal, and identity.Sql is consumed on the
first line. This overload builds the identity from the command's own text
and type, which is what identity.Sql is in practice - letting external
tooling (for example build-time code generators, aka Dapper.AOT) apply a
bag without reimplementing the protocol.

Test covers the bag+literal composition against a closed connection (no
database needed).

* AddParameters(IDbCommand): dispatch via IDynamicParameters

A subclass that hides AddParameters and re-implements the interface - the
DynamicParameterWithIntTVP pattern from this very test suite - was skipped
by the direct call, which binds statically to the protected base method.
Routing through the interface uses the runtime type's interface map, so
the subclass version runs, matching what vanilla execution does.

…isabled (#2228)

DateOnly/TimeOnly support (#2051) was compiled out in 907a4d9 pending
#2071/#2072. This re-enables it with the root causes fixed, and teaches the
read paths that the date/time family has no IConvertible bridge - which box
a date or time column yields is a provider/version decision (Npgsql 10:
DateOnly/TimeOnly; SqlClient and Npgsql 9: DateTime/TimeSpan), so both
shapes must convert:

- GetFieldValue<T> is no longer demanded of a column whose reported type
  needs a family conversion (a datetime column into a DateOnly member was
  the #2072 breakage; SqlDecimal-style entries, where GetFieldValue from a
  differently-reported column is the whole point, keep it);
- the member, scalar and Parse<T> paths all convert DateOnly/TimeOnly <->
  DateTime/TimeSpan in both directions (IL for members, object-level
  elsewhere), fixing reads against Npgsql 10 date/time columns (#2226);
- Query<DateOnly>/<TimeOnly> in scalar form no longer silently return
  default(T) (#2227): the typeMap entries make them simple types again;
- the same-TypeCode direct-unbox shortcut is restricted to distinct codes:
  TypeCode.Object matching TypeCode.Object says nothing (TimeSpan into
  TimeOnly? threw), while object on either side (sql_variant columns,
  dynamic members) keeps the direct unbox;
- the scalar conversion fallback keeps Convert.ChangeType's strict null
  contract (TestConversionExceptionMessages pins it).

The parked DateTimeOnlyTests are re-enabled, with new tests for the #2072
shape (datetime column into DateOnly member), the #2227 scalar shape, and
date-as-DateTime regression guards; PostgresqlTests gains the Npgsql-10
interchange matrix ([FactPostgresql], so it runs where the documented
container is available).

Fixes #2072, #2226, #2227, #1728; expected to also resolve #2071.

…AppVeyor (#2230)

* Fix the release-tag pattern in version.json

publicReleaseRefSpec requires `^refs/tags/v\d+\.\d+`, but every tag this repo has
ever cut is unprefixed - 2.1.79, 2.1.72, 2.1.66 and so on - so the regex cannot
match any of them. Checking out the real 2.1.79 tag and asking nbgv gives
`2.1.79-g72a54c475f`, PublicRelease False: a tag-triggered build has always
produced a -g suffixed version, which is fine while releases are pushed by hand
and fatal once a workflow does it. Relaxed to `v?` so both spellings work.

Same fix, same reason, as DapperAOT b5194b4 and StackExchange.Redis 611e478.
Also adds the `$schema` line the file was missing.

* CI: report the computed version, build on SDK 11, and test net481

**Report the computed version.** A step writes NuGetPackageVersion to the job
summary and the log, before the build so it stays legible when a later step
fails. Cutting a release now means reading that line off a green main run and
tagging with exactly it - so the number has to be visible. A PR run builds
refs/pull/N/merge, whose height includes the branch commits and the merge, so its
number is *not* the one that will ship; the summary says so on anything that is
not main, rather than inviting a mis-tag. This needs full history, so checkout
gains fetch-depth: 0 (and moves v1 -> v4).

**Build on SDK 11.** global.json already says rollForward:latestMajor, so simply
installing the SDK 11 preview alongside 10 makes it the one that builds. Breakage
from a new major toolchain then surfaces on an ordinary PR instead of when a
release is being cut. Target frameworks are untouched - this changes what compiles
the code, not what the code runs on - and global.json stays the single lever if we
ever want to pin back to 10.

**Test net481.** tests/Directory.Build.targets sets IsTestProject=false for net4x
outside Windows, so the Ubuntu job has never run net481 - and net481 is the only
TFM that compiles the ENTITY_FRAMEWORK, LINQ2SQL and OLEDB code paths. AppVeyor
was quietly the only thing covering them, so retiring it (next commit) without
this would drop that cover silently. New windows-job runs exactly that leg.

GitHub's Windows images ship no SQL Server engine - only the OLEDB drivers -
hence the install step; AppVeyor's image had an MSSQL$SQL2019 instance built in.
MySQL and PostgreSQL are deliberately not provisioned there: FactMySqlAttribute
and FactPostgresqlAttribute probe the server in a static constructor and skip the
tests when it is unreachable, and the Ubuntu job already covers both providers
against real servers.

Also fixes `.NET Lib Pack`, which passed a cmd-style `%CD%\.nupkgs` to a job that
has run on Ubuntu for years, and so has been writing to a directory named
literally that.

* Add release.yml: verify the tag, then publish to nuget.org over OIDC

There has never been a workflow that publishes to nuget.org - AppVeyor pushed to
two MyGet feeds on every main build, and the actual nuget.org releases were pushed
by hand. That is also why the broken tag pattern went unnoticed for years.

Triggered by a published GitHub Release, with workflow_dispatch as a dry run that
does everything except the tag check and the push, so the pipeline can be proven
(and the packages inspected, via the run artifact) without cutting a release.

The guard is the point: nbgv computes the version from version.json plus commit
height, so the tag name does not set it and a mistyped tag would otherwise ship a
package that disagrees with its release. The step compares the two and fails
loudly instead. A leading "v" is stripped, matching the `v?` pattern.

Auth is Trusted Publishing (OIDC) - no long-lived key anywhere, which is the whole
reason for the move. Setup lives outside this file and is recorded in the header
comment: a GitHub environment named "release", a NUGET_USER secret, and a
trusted-publishing policy on nuget.org for each of the six published packages. A
package with no matching policy fails its push, so all six need one up front.

Runs on Ubuntu, matching main.yml: that is the configuration CI actually proves,
and it means bash expands the push glob (DapperAOT 13f9f0d had to unpick exactly
that on Windows). Packages are uploaded as a run artifact before the push, so a
failed push does not cost the build, and --skip-duplicate makes a partial push
safely re-runnable. Output goes to `nupkgs`, not `.nupkgs`: upload-artifact skips
hidden files by default and a dot-directory uploads as an empty artifact.

No tests here - the commit being released already passed CI, and this job's only
job is to reproduce that build and push it.

* Retire AppVeyor, and drop MyGet from the badges

release.yml now publishes to nuget.org on a tagged release, so AppVeyor's two
MyGet deploy providers are both redundant and a second, unversioned place for
packages to appear. The rest of AppVeyor went with them: its Windows build and
test run is now main.yml's windows-job, which is the part worth keeping.

That also retires the two encrypted MyGet API keys the file carried.

Badges and package tables follow: the AppVeyor build badge becomes the GitHub
Actions one, and the MyGet pre-release column and feed link come out of both
readmes, since that feed is no longer fed by anything.

build.ps1 / build.cmd are left in place - AppVeyor was their only caller, but they
still work as a local build-test-pack entry point.

* Stop packing Dapper.ProviderTools

`dotnet pack Build.csproj` produces it, so a release workflow would push it - but
it was last released as 2.0.90 in April 2021 and has had no work since. Shipping
it now means a dormant package jumping to 2.1.x on the next release, and a
nuget.org trusted-publishing policy that has to be kept alive for something nobody
is maintaining.

IsPackable=false instead, which drops the push set to the six packages the readme
actually lists. The project still builds and is still referenced; un-set the
property to resume shipping it.

* Bump Microsoft.SourceLink.GitHub to clear the NU1902 build break

Microsoft.Build.Tasks.Git 10.0.300, pulled in transitively by SourceLink, has
picked up GHSA-23fw-v26w-5fgq. TreatWarningsAsErrors turns the NU1902 audit
warning into an error, so Dapper and Dapper.StrongName fail to build - tests and
benchmarks only warn, since they set TreatWarningsAsErrors=false.

This is not caused by anything else in this PR: it reproduces on main, under SDK
10 and SDK 11 alike. It is bundled here only because it blocks the checks, and
with them the first real run of the new net481 job.

There is no fixed 10.x - the only versions above 10.0.300 are 11.0.100 previews -
so this takes the rc. That is tolerable for this particular dependency: SourceLink
is PrivateAssets=all, a build-time-only asset that never becomes a dependency of
the packages we publish, and it already tracks the SDK we now build with.

Verified locally: NU1902 is gone and the build exits 0, leaving the pre-existing
NU1903 warnings in tests/benchmarks (SQLitePCLRaw, System.Security.Cryptography.Xml)
which are warnings only and are a separate matter.

* Windows: reach SQL Server over shared memory, not TCP

First real run of this job: 735 of 825 net481 tests failed, every one of them
"TCP Provider, error: 0 - The remote computer refused the network connection."

The install itself was fine - ankane/setup-sqlserver puts in a default MSSQLSERVER
instance with SQL auth - but a Windows SQL Server install leaves the TCP/IP
protocol disabled, so nothing is listening on 1433 and every connection to
tcp:localhost,1433 is refused. AppVeyor never hit this because it connected to
`(local)\SQL2019`, not over TCP. Dropping the `tcp:`/port from both connection
strings uses shared memory against the local default instance, which needs no
protocol configuration.

Also pins the engine to 2019: that is what the Ubuntu job's service container
runs and what AppVeyor ran these tests against, and the action otherwise installs
SQL Server 2025. This job exists to preserve cover that already existed - moving
the engine version underneath it at the same time is a separate decision, and the
OLEDB tests in particular use the legacy SQLOLEDB provider.

Adds a reachability check before the tests, so the next time something is wrong
with the server the job says so in one line instead of several hundred identical
connection failures.

* Windows: stop pinning SQL Server 2019, it hangs the install

The pin added in the previous commit hung "Install SQL Server" for 28 minutes
before the run was cancelled; the same step with the action's default took 2m48s
on the same image a run earlier. SQL Server 2019 predates the Windows Server 2025
runner image, and its setup stalls rather than failing outright.

Reverting to the action's default. The conservatism was not worth its cost: it
was meant to keep this job as close as possible to what AppVeyor proved, but it
cannot install at all. The net481 leg therefore runs against a newer engine than
AppVeyor used - worth knowing, and called out in the comment, because the OLEDB
tests reach SQL Server through the legacy SQLOLEDB provider and that combination
has not been exercised before.

The shared-memory connection strings and the reachability check stay: those were
the actual fix for the 735 connection failures, and are independent of version.

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.

…2238)

main.yml filtered pushes with

  paths:
  - '*'
  - '!/docs/*'

GitHub's `*` does not cross a '/', so `'*'` matches only files at the repository
root. Any push touching just Dapper/, tests/ or another subdirectory failed the
filter and the build was skipped - silently, because a skipped workflow is not a
failure. Checking main:

  8becae8 (#2230)  4 root files  ran
  2ca8261 (#2223)  1 root file   ran
  6d48ef6 (#2228)  0 root files  skipped
  41d76c7 (#2225)  0 root files  skipped

So most merges to main never built at all. The second line never worked either:
path filters are repo-relative and take no leading slash, so '!/docs/*' matched
nothing - the docs exclusion it was written for was already being done, by
accident, by the '*' that excluded every subdirectory.

paths-ignore: 'docs/**' says what was meant: run for everything except a
docs-only change.

This matters more than it used to. release.yml takes its version from what a
green main run reports, so a main build that never runs means no version to tag
with - which is how this was noticed.