Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
nwoolls opened this issue Nov 29, 2017 · 12 comments
Closed

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

nwoolls opened this issue Nov 29, 2017 · 12 comments

Comments

@nwoolls
Copy link

nwoolls commented Nov 29, 2017

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
Copy link
Owner

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
Copy link
Author

nwoolls commented Nov 29, 2017

Some official docs on the topic:

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):

@ericsink
Copy link
Owner

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
Copy link
Contributor

bricelam commented Nov 30, 2017

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
Copy link
Owner

@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
Copy link
Owner

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

@jwdavidson
Copy link

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
Copy link

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
Copy link
Owner

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
Copy link

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

@ericsink
Copy link
Owner

Ah, yes. That makes sense.

@ilbassodigenova
Copy link

ilbassodigenova commented Aug 9, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants