Update SQLitePCL.raw dependency

[Petermarcu]

EFCore using Sqlite doesn't support publishing an app to the generic win-x64 or win-x86 runtime identifier. In .NET Core 2.0, we moved to telling people to use the generic runtime identifiers of win-x64, linux-x64 and osx-x64 but this issue prevents that from working on Windows.

ericsink/SQLitePCL.raw#194

People should be able to dotnet publish -r win-x64 and get a working application on Windows.

If you follow this how to and then try to publish your application using the above command, you will get:

Unhandled Exception: System.TypeInitializationException: The type initializer for 'Microsoft.Data.Sqlite.SqliteConnection' threw an exception. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.DllNotFoundException: Unable to load DLL 'e_sqlite3': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
   at SQLitePCL.SQLite3Provider_e_sqlite3.NativeMethods.sqlite3_libversion_number()
   at SQLitePCL.SQLite3Provider_e_sqlite3.SQLitePCL.ISQLite3Provider.sqlite3_libversion_number()
   at SQLitePCL.raw.SetProvider(ISQLite3Provider imp)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   at Microsoft.Data.Sqlite.Utilities.BundleInitializer.Initialize()
   at Microsoft.Data.Sqlite.SqliteConnection..cctor()
   --- End of inner exception stack trace ---
   at Microsoft.EntityFrameworkCore.Storage.Internal.SqliteRelationalConnection.CreateDbConnection()
   at Microsoft.EntityFrameworkCore.Internal.LazyRef`1.get_Value()
   at Microsoft.EntityFrameworkCore.Storage.RelationalConnection.Open(Boolean errorsExpected)
   at Microsoft.EntityFrameworkCore.Storage.Internal.SqliteRelationalConnection.Open(Boolean errorsExpected)
   at Microsoft.EntityFrameworkCore.Storage.RelationalConnection.BeginTransaction(IsolationLevel isolationLevel)
   at Microsoft.EntityFrameworkCore.Update.Internal.BatchExecutor.Execute(Tuple`2 parameters)
   at Microsoft.EntityFrameworkCore.Update.Internal.BatchExecutor.Execute(IEnumerable`1 commandBatches, IRelationalConnection connection)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.SaveChanges(IReadOnlyList`1 entriesToSave)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.SaveChanges(Boolean acceptAllChangesOnSuccess)
   at Microsoft.EntityFrameworkCore.DbContext.SaveChanges(Boolean acceptAllChangesOnSuccess)
   at Sqlite.Program.Main(String[] args) in C:\temp\Sqlite\Program.cs:line 12

I'm filing this here because I think this should be tracked and likely patched into the 2.0 SDK.

[bricelam]

@Eilon, what are the chances of updating a third-party dependency in a patch?

[Eilon]

@bricelam - it's certainly not impossible. We've done it before in some serious cases.

[bricelam]

Good to know. I'm not sure we'll be able to justify the risk since we'd have to update from version 1.1.7 to 1.1.10+, and the current workaround is simply to use dotnet publish -r win7-x64 (instead of win-)

[Petermarcu]

The workaround gets really painful for some people that are trying to publish win-x64. I have seen other cases where doing win7-x64 breaks people when using. We need to support win-x64 in .NET Core 2.0. How would we service this package if there were a fix we needed in it? Are we saying that we can't take their latest patched version?

[bricelam]

There's nothing preventing users from just putting this in their project:

<PackageReference Include="SQLitePCLRaw.bundle_green" Version="1.1.10" />

Updating the dependency in a 2.0.x patch is a balancing act between value and risk. Forcing every change between SQLitePCL.raw versions 1.1.7 and 1.1.10 onto everyone using EF Core 2.0.x is risky and we need to weigh it against the severity of the issue we're fixing.

Of course we'll update the dependency in 2.1, but those customer are opting into the risk when they update to a new minor version.

[ajcvickers]

@Petermarcu If we feel that this meets the bar for patching, then we would ask Eric to create a new patch version for us that has just this change. We wouldn't just take all the changes since RTM in the same way that we wouldn't do that for our own code. However, based on the information above, including the workarounds, it doesn't seem to me like this meets the bar.

@Eilon @divega Any thoughts on whether this meets the bar to patch?

[Eilon]

If it has such an easy workaround, it is doubtful that we would take it. In fact, there's more than one workaround, and they're both easy (use different RID, or upgrade dependency).

[Petermarcu]

Ok, so it sounds like we should just make sure we pick up the updated version in 2.1?

[ajcvickers]

We update the dependency in 2.1 and verify that the issue is fixed. Leaving this open to track.

[natemcmaster]

FYI Eric Sink just published a version of SQLitePCLRaw that has this fix.

https://www.nuget.org/packages/SQLitePCLRaw.bundle_green/1.1.10-pre20180223200113