File e_sqlite3.dll not included when publishing for runtime win-x64

[nwoolls]

Given the following project:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="SQLitePCLRaw.bundle_green" Version="1.1.9" />
  </ItemGroup>
</Project>

Running the following publish command:

dotnet publish -f netcoreapp2.0 -c release -r win7-x64

Yields a publish folder with the e_sqlite3.dll file:

> ls bin/release/netcoreapp2.0/win7-x64/publish/e_sqlite3.dll
bin/release/netcoreapp2.0/win7-x64/publish/e_sqlite3.dll

However, running the following publish command (runtime is win-x64 rather than win7-x64):

dotnet publish -f netcoreapp2.0 -c release -r win-x64

Results in a publish folder that is missing e_sqlite3.dll:

> ls bin/release/netcoreapp2.0/win-x64/publish/e_sqlite3.dll
ls: bin/release/netcoreapp2.0/win-x64/publish/e_sqlite3.dll: No such file or directory

This results in an error at runtime: System.DllNotFoundException: Unable to load DLL 'e_sqlite3': The specified module could not be found. (Exception from HRESULT: 0x8007007E).

[ericsink]

Others have mentioned this before. At one point (quite some time ago), I had the impression that win7-x64 was the correct choice.

If there is definitive documentation on which is correct, I don't think I have seen it.

Nonetheless, it does seem like perhaps I should change this...

[nwoolls]

Some official docs on the topic:

• https://docs.microsoft.com/en-us/dotnet/core/rid-catalog
• https://blogs.msdn.microsoft.com/dotnet/2017/08/14/announcing-net-core-2-0/#user-content-much-easier-to-target-linux-as-a-single-operating-system

Similar improvements have been made for Windows and macOS. You can now publish for the following “runtimes”.

• linux-x64, linux-arm
• win-x64, win-x86
• osx-x64

And discussion of how these changed WRT .NET Core 2.0 (vs 1.0):

• https://stackoverflow.com/questions/41766002/what-does-the-win-any-runtime-mean-in-net-core/41863501#41863501

[ericsink]

Hmmm. Thanks for the links. But this information (surprisingly) doesn't clarify things.

Most of the information seems to focus on what RID you can provide to "dotnet publish", as opposed to what the RID folder in the nuget package should be named.

I'm putting native files in runtimes\win7-x64\native, because in general, I get the impression that the name of the RID folder in the nupkg should be more specific. Based on the compatibility graph information, I would expect that publish for win-x64 should work with this approach, but it apparently does not.

Looking at other packages which bundle a native library, I see them using RID folders like win7-x64, just as I am. I haven't found an example of someone using win-x64 as a RID folder in the package.

I am not saying that I don't want publish win-x64 to work. I do. I'm just saying that I am not sure about the correct way to achieve that. I suppose I could just change the name of that folder to win-x64 and see if it works.

[bricelam]

Here are the rules: https://github.com/dotnet/corefx/blob/v2.0.3/pkg/Microsoft.NETCore.Platforms/runtime.json

Notice win-* and win7-* aren't actually equivalent. win assets are compatible with win7, but win7 assets aren't compatible with win. So if I publish for win-x64, it won't look for assets under win7-x64.

For package authors, this means native assets probably shouldn't ever be under win7-*. They should use win-* instead. (Also, instead of win8-arm, use win-arm; instead of win10-arm64, use win-arm64.)

For users publishing, this means they should use the exact RID they're publishing for. Use win10-x64 if it will only ever run on Windows 10, not win-x64. This ensures the most correct assets get published.

[ericsink]

@bricelam Excellent.

So for a package author, a single native code asset which is compatible with Windows 7, 8 or 10 would go under win-. (This is my situation.)

But if a package author had a native code asset which is specifically for Windows 7, they would use win7-, and so on.

And if they had separate builds for Windows 7, 8 and 10, they would put each one under the corresponding specific RID.

Thanks!

[ericsink]

This issue should be fixed in 1.1.10, which is now on nuget.org

[jwdavidson]

In addition when I tried to rename the provided SQLitePCL.Raw.provider.e_sqlite3.dll to just e_sqlite3.dll it did correct the issue with the dll not found, but introduced a new error about libversion information not being found. See @smitpatel above for original report

[jwdavidson]

The package with the fix does not show as an available update, when using Microsoft.AspNetCore.All

It looks like the shortcut may create as many issues as it solves. I was able to update a 3 project solution from Core 1.0 to Core 2.0 in about 3 hours, but spent another 10 trying to get those projects work in production due to this single issue.

[ericsink]

I'm not sure what "shortcut" you mean. Maybe "tried to rename the provided SQLitePCL.Raw.provider.e_sqlite3.dll to just e_sqlite3.dll". If so, yeah, you should not do that. :-)

Anwyay, as you discovered, the problem you found was fixed in 1.1.10.

[jwdavidson]

The package Microsoft.AspNetCore.All is a shortcut, rather than providing the names of all the individual packages required for ASPNet Core.

[ericsink]

Ah, yes. That makes sense.

[ilbassodigenova]

Still have the problem. One (or two) out of three times i debug with VS2017, i got this
DllNotFoundException: Unable to load DLL 'e_sqlite3': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

The project is in .net Framework 4.8
There is a walkaround: When cleaning, changing architecture (move from AnyCpu to x64 and viceversa) everything goes fine again. For once or twice.

Edit: Found a solution:
http://www.korober.ru/2018/01/25/you-need-to-call-sqlitepcl-raw-setprovider-if-you-are-using-a-bundle-package-this-is-done-by-calling-sqlitepcl-batteries-init-solving/

If you get same error when try use Sqlite, check your dependencies:

you should have:

Microsoft.EntityFrameworkCore.Sqlite