[Benchmarks] Reference SQLitePCLRaw.bundle_e_sqlite3 in EFCore.Sqlite.Benchmarks#38293
Merged
AndriySvyryd merged 1 commit intoMay 19, 2026
Conversation
Since the SQLitePCLRaw 3.x bump in dotnet#36551, every benchmark in EFCore.Sqlite.Benchmarks throws on [GlobalSetup]: 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 BenchmarkDotNet.Autogenerated.Runnable_0.GlobalSetup() In SQLitePCLRaw 3.x the bundle packages register the provider via a ModuleInitializer, so referencing SQLitePCLRaw.bundle_e_sqlite3 (the same package used by EFCore.Sqlite.FunctionalTests) is sufficient - no code change is needed. The package version is already pinned in the root Directory.Packages.props as SQLitePCLRaw.bundle_e_sqlite3 = $SQLitePCLRawVersion (3.0.3). The aspnet/Benchmarks benchmarks-ci-01 pipeline has been silently running zero EF Core measurements (every method reports NA in BDN, but crank treats BDN's normal exit as success) for roughly two months since 2026-03-19 / build 2930691. Verified locally with crank + crank-agent --profile local: before the fix every method is NA, after the fix all methods report real Mean and Op/s. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
This PR fixes EFCore.Sqlite.Benchmarks failing at BenchmarkDotNet [GlobalSetup] after the SQLitePCLRaw 3.x upgrade by ensuring the SQLitePCLRaw provider gets registered via the bundle package’s module initializer.
Changes:
- Add a
PackageReferencetoSQLitePCLRaw.bundle_e_sqlite3in the SQLite benchmarks project so provider registration happens automatically at runtime.
AndriySvyryd
approved these changes
May 19, 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
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.
Fixes #38292. This was generated by AI, so if there is a different preferred approach, feel free to close.
Since the SQLitePCLRaw 3.x bump (#36551), every benchmark in
EFCore.Sqlite.Benchmarksthrows on[GlobalSetup]:In SQLitePCLRaw 3.x the bundle packages register the provider via a
[ModuleInitializer], so referencingSQLitePCLRaw.bundle_e_sqlite3(the same package
EFCore.Sqlite.FunctionalTestsalready uses) issufficient — no code change is needed. The version is already pinned in
the root
Directory.Packages.propsasSQLitePCLRaw.bundle_e_sqlite3 = $(SQLitePCLRawVersion)(3.0.3).This regression has been silently masking every EF Core measurement in
the
aspnet/Benchmarksbenchmarks-ci-01pipeline for ~122consecutive builds since 2026-03-19. BenchmarkDotNet reports every
method as
NAunder "Benchmarks with issues" but exits with code 0,and crank's
RunBenchmarkDotNetonly fails on agent-side errors, sothe AzDO task is marked succeeded. See the issue for the full
investigation.
Verification
Reproduced locally with
crank+crank-agent --no-cleanupon theagent's net11.0 preview SDK. Funcletization scenario:
Before:
After the one-line
<PackageReference>add: