You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The EntityFramework.Sqlite NuGet package has a dependency on the Microsoft.Data.Sqlite NuGet package, which contains the sqlite3.dll. If we use a custom sqlite3.dll (distributed either as an Extension SDK or as a NuGet package) with the EntityFramework.Sqlite NuGet package, the build will fail because there are 2 sources for the sqlite3.dll.
When using a custom version of the sqlite3.dll, you have a few options:
Copy the custom version of the sqlite3.dll into the .nuget\packages\Microsoft.Data.Sqlite\1.0.0-beta6\runtimes folders.
Manually deleting the sqlite3.dll from the .nuget\packages\Microsoft.Data.Sqlite\1.0.0-beta6\runtimes folders.
Create a custom nuget package, with all the EntityFramework.Sqlite dependencies manually added. Not a big fan of doing this, especially since the packages are already built with the small problem of providing the sqlite3.dll.
All of these solutions are okay for a single developer but with multiple dev teams to contend with; several build servers which are shared with other projects; automated builds; etc... they're not very maintainable.
If the Entity Framework NuGet packages did not contain the sqlite3.dll, this would allow users to use either a custom version, a version that was previously downloaded as an Extension SDK, or a NuGet package.
If you have any suggestions or input on alternative solutions, we would be greatly appreciative.
Thanks!
The text was updated successfully, but these errors were encountered:
It's a shame NuGet doesn't have virtual packages. Then the users could choose how to satisfy the Native SQLite Library dependency.
If we did split out the native components into its own package, I wonder if using Install-Package Microsoft.Data.Sqlite -IgnoreDependencies would work, or if automatic package restore would just bring it in anyway.
If we can't make anything else work, having another package without the dependency (e.g. Microsoft.Data.Sqlite.BringYourOwnNative) wouldn't be awful.
To be fair, I guess users already have to "bring their own" if they're running outside of win10 or win-x86.
The EntityFramework.Sqlite NuGet package has a dependency on the Microsoft.Data.Sqlite NuGet package, which contains the sqlite3.dll. If we use a custom sqlite3.dll (distributed either as an Extension SDK or as a NuGet package) with the EntityFramework.Sqlite NuGet package, the build will fail because there are 2 sources for the sqlite3.dll.
When using a custom version of the sqlite3.dll, you have a few options:
Copy the custom version of the sqlite3.dll into the .nuget\packages\Microsoft.Data.Sqlite\1.0.0-beta6\runtimes folders.
Manually deleting the sqlite3.dll from the .nuget\packages\Microsoft.Data.Sqlite\1.0.0-beta6\runtimes folders.
Create a custom nuget package, with all the EntityFramework.Sqlite dependencies manually added. Not a big fan of doing this, especially since the packages are already built with the small problem of providing the sqlite3.dll.
All of these solutions are okay for a single developer but with multiple dev teams to contend with; several build servers which are shared with other projects; automated builds; etc... they're not very maintainable.
If the Entity Framework NuGet packages did not contain the sqlite3.dll, this would allow users to use either a custom version, a version that was previously downloaded as an Extension SDK, or a NuGet package.
If you have any suggestions or input on alternative solutions, we would be greatly appreciative.
Thanks!
The text was updated successfully, but these errors were encountered: