| Ticket Hash: | cb42aa912604fcf1377936880c385386a863d284 | |||
| Title: | SQLite.Interop.dll doesn't get coppied to output directory when not a direct dependancy on SDK style projects | |||
| Status: | Closed | Type: | Packaging | |
| Severity: | Important | Priority: | Medium | |
| Subsystem: | NuGetPackage | Resolution: | External_Bug | |
| Last Modified: | 2020-04-06 21:45:13 | |||
| Version Found In: | 1.0.112 | |||
| User Comments: | ||||
anonymous added on 2020-02-11 20:54:21:
(text/x-markdown)
[This isn't entirly a new issue](https://stackoverflow.com/questions/13028069/unable-to-load-dll-sqlite-interop-dll). However the existing sujested [workaround](https://system.data.sqlite.org/index.html/tktview/db7a713f4f0ad2b4f965) no longer works for SDK style projects because target files from package `build` folders are not [imprted from transitive packages](https://github.com/NuGet/Home/wiki/Allow-package--authors-to-define-build-assets-transitive-behavior) ## Expected behavior When importing a package or referencing a project that depends on System.Data.Sqlite `x86/SQLite.Interop.dll` and `x64/SQLite.Interop.dll` are copied to the output folder ## Observed Behavior When importing a package or referencing a project that depends on System.Data.Sqlite `x86/SQLite.Interop.dll` and `x64/SQLite.Interop.dll` are **not** copied to the output folder [example files](https://drive.google.com/file/d/1EDUgCTprVBqe9RBVXtqmIE03PYGXI_5R/view?usp=sharing) Since Nuget 3.5 there is [support](https://github.com/NuGet/Home/issues/2782) for including multiple native libraries. native libraries are resolved based on the [RID](https://docs.microsoft.com/en-us/dotnet/core/rid-catalog) of the target platform. mistachkin added on 2020-02-20 03:42:48: (text/x-markdown) Based on the issue you linked, this sounds like a bug in NuGet itself. | ||||
