Prepare 1.11 Release

[praeclarum]

No description provided.

[praeclarum]

I'm holding off the merge until @ericsink has verified the package versions.

[ericsink]

@praeclarum You asked if config.e_sqlite3 is the same as bundle_green: It is not.

The bundle_green package was: Use e_sqlite3 builds everywhere except iOS, and on iOS, use the system SQLite.

The config.e_sqlite3 package is: Use e_sqlite3 builds everywhere.

I deprecated bundle_green because it was only intended to be used by sqlite-net, but others kept using it without understanding it. If you still prefer the bundle_green behavior for sqlite-net-pcl, I will incorporate the stuff from bundle_green into sqlite-net-pcl. Let me know.

[praeclarum]

@ericsink Understood, thank you for explaining.

Overall I'm OK with bundling sqlite.

• I don't love increasing app sizes but sqlite tends to be small so it's not the worst thing...
• I am a little suspicious of Apple breaking things somehow
• I worry a little bit about MacCatalyst - whether your bundled sqlite will work well there.

However these are just worries and we can address the situation if any of them become real problems.

In terms of Raw initialization, is this PR OK?

[ericsink]

Actually, this should probably change from config.e_sqlite3 to bundle_e_sqlite3. The "config" package says "reference e_sqlite3 but don't actually bring it into the build". The "bundle" package says "reference e_sqlite3 and include it in the build".

[ericsink]

bundle_e_sqlcipher has been deprecated. I suggest deprecation of sqlite-net-sqlcipher. Such cases can be handled with the sqlite-net-e package, which uses config.e_sqlite3, which allows custom builds of SQLite using the e_sqlite3 name.

[ericsink]

And actually, I don't see the sqlite-net-e package here in this file either. I'd suggest adding it here. The raw3 branch contains my work on this.

Which raises another issue.: sqlite-net-e was published with a version number of 1.11.0. We should synchronize all these, but it would difficult to go back now.

I can add you as an owner of sqlite-net-e.

[ericsink]

And FWIW, my e_sqlite3 builds do support maccatalyst.

[ericsink]

SQLitePCLRaw 3.0.3 has been released.

[praeclarum]

@ericsink OK. I'll add maccat, and switch the version to 1.11 beta. Once I've proven to myself everything is OK on iOS, I'll ship as 1.11. Sound good?

Sorry, but I'm a bit confused about packages.

• ApiDIff doesn't actually do any database work, just compiles and checks the API surface area.
• Why would sqlite-net-pcl (package) (SQLite-net-std (project)) reference sqlite-net-e? I thought that was a clone of this project. I see, sqlcipher got renamed to e
• What should sqlite-net-base (package) reference? From your descriptions, I'm assuming config? I'm following your lead from the raw3 branch.

[jamesmontemagno]

HYPE

[praeclarum]

@ericsink ah OK, I've checked out your branch now. Working on merging it into this PR. That PR is now #1303

[praeclarum]

@ericsink Should we change this to IsApple and check for macos and maccatalyst also?

[ericsink]

I think so, yes.

[ericsink]

I suppose it depends on whether you want to use the system SQLite on those platforms or my builds.

[ericsink]

Acknowledging: I'll take a look at all this in the morning. Thanks.

[ericsink]

Overall, looking good. I want to give everything another look outside of review mode so I can see whole files better. But this is close.

[ericsink]

I may need to verify compatibility of my packages with the net8 mobile workloads. I'm pretty sure I'm avoiding dependencies on the mobile workloads whenever possible, but when needed, I'm building with net10 versions.

[praeclarum]

I generally prefer net8 at the moment because I know some shops that are still on it. But since this change is to support modern Android, I'm vaguely OK with using net10. I'll leave it at net8 for the moment unless you tell me otherwise.

[ericsink]

I suppose it depends on whether you want to use the system SQLite on those platforms or my builds.

[praeclarum]

@ericsink Thanks for the feedback. I'll release a beta today, and if I like it, get a release out soon.

Just one more question:

My sqlite-net-base was meant to be the version that accepted different Raw backends. But now that you've release sqlite-net-e I'm not sure what its purpose is. Doesn't -e do the same thing? Have the same goals? Or are they different. Raw is so complicated now haha :-)

[ericsink]

Raw is so complicated now

I know, right?

IIRC, -base only depends on SQLitePCLRaw.core, which means it makes no assumptions about where the native SQLite library is coming from. It still has valid use cases.

The -e variant is a bit different. It means "always look for a SQLite with e_sqlite3 as the name, but don't actually specify which one".

In my view, both still have a place.

[jamesmontemagno]

Hmmm @praeclarum I seem to get:

   at SQLite.SQLiteAsyncConnection.<>c__DisplayClass33_0`1[[SQLite.CreateTableResult, SQLite-net, Version=1.11.272.0, Culture=neutral, PublicKeyToken=null]].<WriteAsync>b__0()
   at System.Threading.Tasks.Task`1[[SQLite.CreateTableResult, SQLite-net, Version=1.11.272.0, Culture=neutral, PublicKeyToken=null]].InnerInvoke()
   at System.Threading.Tasks.Task.<>c.<.cctor>b__288_0(Object obj)
   at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---
   at System.GC.GuardedFinalize(Object o)

2026-05-16 16:38:20.821548-0700 DCPTracker[35098:7015745] Unhandled managed exception: The type initializer for 'SQLite.SQLiteConnection' threw an exception. (System.TypeInitializationException)
   at SQLite.SQLiteConnectionWithLock..ctor(SQLiteConnectionString connectionString)
   at SQLite.SQLiteConnectionPool.Entry..ctor(SQLiteConnectionString connectionString)
   at SQLite.SQLiteConnectionPool.GetConnectionAndTransactionLock(SQLiteConnectionString connectionString, Object& transactionLock)
   at SQLite.SQLiteConnectionPool.GetConnection(SQLiteConnectionString connectionString)
   at SQLite.SQLiteAsyncConnection.GetConnection()
   at SQLite.SQLiteAsyncConnection.<>c__DisplayClass33_0`1[[SQLite.CreateTableResult, SQLite-net, Version=1.11.272.0, Culture=neutral, PublicKeyToken=null]].<WriteAsync>b__0()
   at System.Threading.Tasks.Task`1[[SQLite.CreateTableResult, SQLite-net, Version=1.11.272.0, Culture=neutral, PublicKeyToken=null]].InnerInvoke()
   at System.Threading.Tasks.Task.<>c.<.cctor>b__288_0(Object obj)
   at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---
   at System.GC.GuardedFinalize(Object o)
e_sqlite3 (System.DllNotFoundException)
   at SQLitePCL.SQLite3Provider_e_sqlite3.SQLitePCL.ISQLite3Provider.sqlite3_libversion_number()
   at SQLitePCL.raw.SetProvider(ISQLite3Provider imp)
   at SQLitePCL.Batteries_V2.Init()
   at SQLite.SQLiteConnection..cctor()

I had to manually add

and then revert to the previous beta and call SQLitePCL.Batteries.Init(); and it worked, but this isn't in the latest beta

[ericsink]

Which SQLite-net package were you using?

[jamesmontemagno]

Currently: https://github.com/jamesmontemagno/app-dcp-tracker

Just:

	<PackageReference Include="sqlite-net-pcl" Version="1.11.272-beta" />

However if I do this:

	<PackageReference Include="sqlite-net-pcl" Version="1.10.196-beta" />
	<PackageReference Include="SourceGear.sqlite3" Version="3.50.4.5" />
	
	and then call the SQLitePCL.Batteries.Init(); 
	
	Works alright

[ericsink]

I'll take a look and figure this out. Thanks.

[ericsink]

FWIW, the attached minimal sample works for me with 1.11.272-beta. I'm not sure yet why app-dcp-tracker is having trouble.
this_works.zip

[jamesmontemagno]

Maybe it's just an iOS specific thing hmmmmm

[jamesmontemagno]

I just tested it on android emulator and also mac catalyst - and it worked alright, so maybe just iOS

[ognjensuljagic]

In order to suport the 16kb pages on Android I moved
from sqlite-net-sqlcipher 1.9.172
to sqlite-net-pcl 1.11.272-beta

Now on Android the local DB works fine after the upgrade, but on iOS I am getting this:

System.DllNotFoundException: e_sqlite3
  at int SQLite3Provider_e_sqlite3.SQLitePCL.ISQLite3Provider.sqlite3_libversion_number()()
  at void raw.SetProvider(ISQLite3Provider imp)()
  at void Batteries_V2.Init()()
  at static SQLiteConnection()()

[ericsink]

@ognjensuljagic That looks like the same problem @jamesmontemagno is describing. Now that I can see that it's iOS-specific, I'm pretty sure I know what it is. I should have it fixed today.

[ericsink]

Hmmm. The problem is something wrong with the iOS-specific logic in SQLite-net-std.csproj, but it's not as obvious as I hoped.

And the iOS build configuration on my dev machine is currently messed up. I have what feels like a constant battle with the Maui workloads and Xcode where things get out of date and stuff stops working. Anyway, I'm probably going to have to do the Xcode/workload dance so I can actually test any fixes.

[ericsink]

@jamesmontemagno @ognjensuljagic I've got my dev environment updated now, and I'm having trouble reproducing this problem. I'm using a basic sample (dotnet new iOS) under the iOS simulator, with the dotnet 9 SDK, and just sqlite-net-pcl 1.11.272-beta. Opening a db connection to :memory: works, and the output folder indicates the right provider is being built.

Something I'm doing here is different.

[jamesmontemagno]

Hmmmmm... I'm on .NET 10, what if you do dotnet new maui on it? just to make sure there is no difference. If you have a project uploaded i can pull it down as well.

[ericsink]

I'll try that. If I can reproduce the problem, it should be easy to fix.

[jamesmontemagno]

I'll try to get a tiny reproduction tomorrow for you as well.

[ericsink]

OK, I've got a repro now. Fixing coming soon I hope.

[ericsink]

Looks like the problem is:

That package is being built for net8.0-ios and net9.0, so it gets a dependency group for each of those frameworks. When consumed from net10.0-ios, it matches the net9.0 dependency group instead of the net8.0-ios one, so it gets the wrong provider. If I add net9.0-ios to the build for the sqlite-net-pcl package, it works.

Does this seem like the right fix?

[jamesmontemagno]

interesting..... i wonder then if it should be net8.0-ios;net9.0-ios;net10.0-ios

[ericsink]

Or maybe we should try just removing net9.0 plain? The problem seems to be that net9.0 plain takes precedence over net8.0-ios.

I assume that adding all three of the -iOS tfms would mean that all 3 of those workloads would need to be present at build time, so that's a possible issue.

[jamesmontemagno]

@ericsink @praeclarum #1305 to try

[ericsink]

FWIW, I removed net9.0 and ran the same quickie test with a 'dotnet new maui' app on .NET 10, and it worked fine. But I don't know why net9.0 was there, or if its removal might cause problems on other platforms, etc.

[ericsink]

Interesting:

https://learn.microsoft.com/en-us/dotnet/standard/frameworks

Apparently the docs cover this exact problem with TFM precedence rules.

[ognjensuljagic]

@praeclarum
The current beta release has issues with iOS and needs an update.
Can you please see the above comments.