Problems using winsqlite3.dll in UWP applications

[divega]

Current builds of Windows 10 include a winsqlite3.dll assembly that should be usable in UWP applications. I tried to do it following the Local SQLite on UWP walkthrough and adding a call to SqliteEngine.UseWinSqlite3() early on in the application, but I run into a couple of issues:

1. Native calls through interop such as sqlite3_open_v2() fail when targeting winsqlite3.dll instead of sqlite3.dll in an UWP application:

   • In debug the application crashes with code 0xc0000409
   • In release the APIs just fail

   I don't know the exact reason an that is going to require further investigation but there seems to be some kind of mismatch in the declaration of the interop call. In fact I tried a couple of tentative workarounds that made the application work:

   1. Changing the calling convention from CallingConvention.Cdecl to CallingConvention.StdCall or CallingConvention.Winapi.
   2. Switching from our custom marshalling of UTF8 strings to use [MarshalAs(UnmanagedType.LPStr)]. Note that this is not an acceptable workaround because it wouldn't work correctly for international characters, but hopefully [MarshalAs(UnmanagedType.LPUTF8Str)] will become an option when https://github.com/dotnet/corefx/issues/7804 gets in for .NET Core 1.1.0.

2. The assembly sqlite3.dll is deployed with the application and loaded in memory regardless. I verified this with Process Explorer. I even tried removing the assembly from disk but then the application fails to start.

[bricelam]

I'm not able to repro the first issue on my machine. I wonder if the second issue is caused by this line of code...

[divega]

Glad that you are not able to repro the first problem in your machine. It may be just a problem in my machine 😞

[bricelam]

Looks like having sqlite3.dll loaded (and requiring it) is a quirk of .NET Native. I'm not sure what we'll be able to do here...

[divega]

Maybe we need to wait to have the NoNative packages? Or is this enough to prioritize the NoNative packages for 1.0.0?

cc @rowanmiller

[bricelam]

I'm not sure the NoNative packages would help; none of the sqlite3.dll code paths are being executed, but because of the way .NET Native works, it tries to load sqlite3.dll before running the application code.

[bricelam]

Splitting the P/Invoke code into separate assemblies may help. I think it all depends on whether tree shaking can remove the P/Invoke code.

[bricelam]

We could also try taking over the loading and calling of the dll--bypass P/Invoke using Win32 APIs.

[divega]

Splitting the P/Invoke code into separate assemblies may help. I think it all depends on whether tree shaking can remove the P/Invoke code.

I see. I guess it is just static analysis, not much they can do.

[divega]

@bricelam are we still planning to do anything about this for 1.1.0-preview1 or are we going to rely on the switch to SQLitePCL.raw to take care of it at a later point?

[bricelam]

The current plan is to switch to SQLitePCL.raw in 1.2.0 where they've already solved this problem.

[bricelam]

After #21 & #148, using winsqlite3.dll will be as simple as:

Install-Package Microsoft.Data.Sqlite.NoNative
Install-Package SQLitePCLRaw.bundle_winsqlite3

[bricelam]

No need to call SqliteEngine.UseWinSqlite3(), but we could keep it around as an obsolete no-op.

[bricelam]

After #320, using winsqlite3.dll is as easy as:

Install-Package Microsoft.Data.Sqlite.Core
Install-Package SQLitePCLRaw.bundle_winsqlite3