-
-
Notifications
You must be signed in to change notification settings - Fork 116
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
Comments
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... |
Some official docs on the topic:
And discussion of how these changed WRT .NET Core 2.0 (vs 1.0): |
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 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 I am not saying that I don't want |
Here are the rules: https://github.com/dotnet/corefx/blob/v2.0.3/pkg/Microsoft.NETCore.Platforms/runtime.json Notice For package authors, this means native assets probably shouldn't ever be under For users publishing, this means they should use the exact RID they're publishing for. Use |
@bricelam Excellent. So for a package author, a single native code asset which is compatible with Windows 7, 8 or 10 would go under But if a package author had a native code asset which is specifically for Windows 7, they would use And if they had separate builds for Windows 7, 8 and 10, they would put each one under the corresponding specific RID. Thanks! |
This issue should be fixed in 1.1.10, which is now on nuget.org |
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 |
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. |
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. |
The package Microsoft.AspNetCore.All is a shortcut, rather than providing the names of all the individual packages required for ASPNet Core. |
Ah, yes. That makes sense. |
Still have the problem. One (or two) out of three times i debug with VS2017, i got this The project is in .net Framework 4.8 Edit: Found a solution:
|
Given the following project:
Running the following publish command:
Yields a publish folder with the
e_sqlite3.dll
file:However, running the following publish command (runtime is win-x64 rather than win7-x64):
Results in a publish folder that is missing
e_sqlite3.dll
: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)
.The text was updated successfully, but these errors were encountered: