Say something at the mute overloads (DAP057), and open 1.1

[mgravell]

Gap #0 from parity.md — the cheapest safety win on the list, and the one that most deserves to be in a release.

The problem

34 public overloads told the consumer nothing at all. They work under JIT — the call-site just stays on vanilla Dapper — and fail after a native-AOT publish, with no build-time signal anywhere. That is the shape behind issues #112, #158 and #165.

Every one is CommandDefinition-shaped, because the analyzer only inspects call-sites carrying SQL as a string argument and these hide it inside the struct. Two groups, two answers:

• 21 are operations we do support, in a spelling we cannot read → new DAP057, reported from the generator (the analyzer never sees them), naming the method and pointing at the overload that takes the SQL directly;
• 12 are unsupported in any spelling — ExecuteReader, multi-map, QueryMultiple → DAP001 from the generator, the same id their visible siblings already get from the analyzer, so both spellings behave alike.

Severity follows PublishAot

Leaving a call-site on vanilla Dapper is a missed optimization under JIT and a latent publish-time crash under native AOT. Same fact, very different stakes — so DAP057 reports at the severity that matches:

JIT project:                  info DAP057: 'Execute' passes its SQL inside a CommandDefinition…
PublishAot=true:           warning DAP057: 'Execute' passes its SQL inside a CommandDefinition…

The SDK sets EnableAotAnalyzer when PublishAot is on and it is compiler-visible by default, so this needs no build props of our own — PublishAot itself is not compiler-visible, which is why that property stands in. Proved end to end against the packed package: a net10.0 project reports info at default verbosity, and the same project with PublishAot=true reports warning.

The point: an upgrade does not bury a JIT project in new warnings (and cannot break anyone's TreatWarningsAsErrors), while an AOT project is told about every call-site that will not survive publishing.

Numbers

Surface report — gains an unsupported: CommandDefinition bucket and collapses unsupported API (undiagnosed), since nothing is undiagnosed any more. Silent skips 34 → 1. The survivor is a reporting artifact rather than a gap: GetRowParser<T>(concreteType) does different things depending on whether a given call passes the Type, which a symbol-level report cannot say (the bound #214 documented). Call-sites there get DAP056 or are handled, correctly.

Corpus (round 15 rig, net10.0, local SQL Server):

	before	after
skipped silently	25	0
refused with diagnostics	203	228
handled	432 of 736	432 of 736
suite	729 / 800	729 / 800

Behaviour is untouched — this adds diagnostics and nothing else. Unit suites: 380/380 on net8.0 and net10.0.

Also here: opening 1.1

version.json moves to 1.1 with versionHeightOffset: -1, so the first build is 1.1.0 rather than 1.1.1. Confirmed by packing: Dapper.AOT.1.1.0-g.nupkg.

DAP001 follows PublishAot too (second commit)

Originally left out as a separate decision; folded in, because leaving it made the PR incoherent — an AOT project would be warned about Execute(CommandDefinition) but not about QueryMultiple, which fails identically after publish.

It turned out to matter more than tidiness. Info-severity analyzer diagnostics do not surface in a normal dotnet build — only in IDEs and at raised verbosity. So DAP001 was effectively being emitted into a void, and the surface report's unsupported API (diagnosed) bucket was true on paper and silent in practice. Proof — the same three call-sites, before and after the promotion:

Program.cs(11,58): warning DAP001   <- QueryMultiple(CommandDefinition)   [generator]
Program.cs(13,70): warning DAP001   <- QueryMultiple("...")               [analyzer]
Program.cs(15,60): warning DAP001   <- Query<int,int,int>("proc", ...)    [analyzer]

As Info, none of those three appeared at all. So this is what makes the whole unsupported surface visible to the people it will hurt, rather than just the CommandDefinition slice.

Blast radius, Dapper suite built with the AOT flag set (MSBuild double-lists, so halve): 152 DAP001 + 50 DAP057 — about 76 and 25 real call-sites, every one of which fails after publish. A JIT consumer sees no change whatsoever.

12 lines across three files: the TargetsNativeAot plumbing already existed, the analyzer just needed an AnalyzerOptions overload, and DAP001 has only two report sites. No golden churn — the test harness sets no MSBuild properties, so goldens stay info.

Verification

Unit suites 380/380 on net8.0 and net10.0. Corpus unchanged at 729 / 800 with both commits in — this PR adds diagnostics and changes no behaviour.