e_sqlite3.dll is being copied to the publish directory

[jp2masa]

I'm using Microsoft.Data.Sqlite 2.0.0, but e_sqlite3.dll is being copied to the publish directory, causing errors at runtime. This seems to be a regression after #360.

EDIT: It can't be a regression in this repo, but it's probably an external problem. Any idea about what may be causing this? Thanks in advance.

[bricelam]

Does installing SQLitePCLRaw.bundle_green version 1.1.8 fix the issue?

[jp2masa]

No, it's still being copied.

[ericsink]

What are those "errors at runtime"?

[jp2masa]

Something like "e_sqlite3.dll not found", but removing e_sqlite3.dll from the publish directory works.

[ericsink]

Can you distill this down to a small project that reproduces the problem?

[jp2masa]

I'll try to do that. This is the error message:

[jp2masa]

The project that uses Microsoft.Data.Sqlite is an MSBuild tasks assembly. I tried to create a repro, but it was not possible, although e_sqlite3.dll is copied to the publish directory. Is e_sqlite3.dll supposed to be copied to the publish output (not inside x86 and x64 folders)?

EDIT: The project is targeting .NET Framework 4.6.2.

[jp2masa]

A more complete log:

An error occurred: 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)
at SQLitePCL.Batteries_V2.Init()
--- 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 System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at Microsoft.Data.Sqlite.Utilities.BundleInitializer.Initialize()
at Microsoft.Data.Sqlite.SqliteConnection..cctor()
--- End of inner exception stack trace ---
at Microsoft.Data.Sqlite.SqliteConnection..ctor(String connectionString)

[jp2masa]

I think that this is the cause of the problem:

I have two projects:

• Project A (net462), has direct dependency on Microsoft.Data.Sqlite
• Project B (netstandard2.0), has direct dependency on Microsoft.Data.Sqlite

Project A depends on Project B.
When publishing project A, e_sqlite3.dll from Project B is copied to the publish directory of Project A, and two directories are created (x86 and x64) by the Project A publish itself.

[jp2masa]

I think that I finally solved the problem. e_sqlite3.dll wasn't being deployed in the VSIX, which depends on Microsoft.Data.Sqlite. I had to create an MSBuild "hack" to fix it.