[Benchmarks] EFCore.Sqlite.Benchmarks silently fails since SQLitePCLRaw 3.x bump — missing bundle reference

[LoopedBard3]

[Benchmarks] EFCore.Sqlite.Benchmarks silently fails since SQLitePCLRaw 3.x bump — missing bundle reference

Summary

Every benchmark in benchmark/EFCore.Sqlite.Benchmarks fails at
[GlobalSetup] time on dotnet/efcore main with:

System.Exception: You need to call SQLitePCL.raw.SetProvider().
If you are using a bundle package, this is done by calling
SQLitePCL.Batteries.Init().
   at SQLitePCL.raw.get_Provider()
   at SQLitePCL.raw.sqlite3_libversion()
   at Microsoft.Data.Sqlite.SqliteConnection.get_ServerVersion()
   at Microsoft.EntityFrameworkCore.Sqlite.Update.Internal
        .SqliteUpdateSqlGenerator..ctor(UpdateSqlGeneratorDependencies)
   ...
   at Microsoft.EntityFrameworkCore.DbContext.get_DbContextDependencies()
   at BenchmarkDotNet.Autogenerated.Runnable_0.GlobalSetup()

The root cause is the SQLitePCLRaw 3.x bump in #36551 (merged 2025-09-09):
in SQLitePCLRaw 3.x, the bundle packages register the provider via a
[ModuleInitializer], but EFCore.Sqlite.Benchmarks.csproj doesn't
reference any SQLitePCLRaw.bundle_* package — only
Microsoft.Data.Sqlite.Core (via EFCore.Sqlite.Core). So
SQLitePCL.raw.SetProvider() is never called and the very first
SqliteConnection use throws.

BenchmarkDotNet catches the exception, marks every method NA, lists
them under "Benchmarks with issues", and exits with code 0. The
aspnet/Benchmarks crank-based CI pipeline (benchmarks-ci-01) only
inspects the agent-reported error and BDN's brief.json, both of which
indicate success — so AzDO has been showing the
5- EF Core gold-win job as green-with-zero-measurements for
~122 consecutive builds since 2026-03-19 (the oldest build still
retained for definition 1208).

Repro

Local repro with dotnet/crank on a
machine with the net11.0 preview SDK available to crank-agent:

# In terminal A: start a local crank-agent
crank-agent --url http://localhost:5010 `
    --build-path <path>\builds --log-path <path>\logs --no-cleanup

# In terminal B: run the Funcletization scenario locally
crank --config https://raw.githubusercontent.com/aspnet/Benchmarks/main/scenarios/efcore.benchmarks.yml `
      --scenario Funcletization `
      --profile local `
      --application.options.downloadOutput true

Output before fix:

BenchmarkDotNet v0.15.8 ...
  [Host] : .NET 11.0.0 (11.0.0-preview.5.26266.103, 11.0.26.26703), X64 RyuJIT

 Method            | Mean | Error | Op/s |
------------------ |-----:|------:|-----:|
 NewQueryInstance  |   NA |    NA |   NA |
 SameQueryInstance |   NA |    NA |   NA |
 ValueFromObject   |   NA |    NA |   NA |

Benchmarks with issues:
  FuncletizationSqliteTests.NewQueryInstance: ...
  FuncletizationSqliteTests.SameQueryInstance: ...
  FuncletizationSqliteTests.ValueFromObject: ...

The downloaded application.*.log contains the SetProvider/
Batteries.Init() stack trace shown above for every benchmark.

Fix

A single <PackageReference> addition to
benchmark/EFCore.Sqlite.Benchmarks/EFCore.Sqlite.Benchmarks.csproj:

<ItemGroup>
  <PackageReference Include="SQLitePCLRaw.bundle_e_sqlite3" />
</ItemGroup>

The package version is already pinned at the root Directory.Packages.props
as SQLitePCLRaw.bundle_e_sqlite3 = $(SQLitePCLRawVersion) (3.0.3), so
no version change is needed. This is the same package
test/EFCore.Sqlite.FunctionalTests/EFCore.Sqlite.FunctionalTests.csproj
already references.

Verified locally — after the change every Funcletization method reports
real measurements (Mean: 5.443 ms, Op/s: 183.7, …) and no exception is
in application.*.log.

PR coming.

Notes on detection

Crank doesn't surface "all NA" runs as failures today — RunBenchmarkDotNet
in dotnet/crank/src/Microsoft.Crank.Controller/Program.cs only returns a
non-zero exit code when job.Job.Error from the agent is non-empty, and
the application's stdout/stderr (where the exception is) is not pulled
back unless --application.options.downloadOutput true is set. That's
why this regression went undetected for two months. Filing this here
rather than in aspnet/Benchmarks because the fix has to live where the
broken csproj lives.