System.Data.SQLite
Ticket Change Details
Not logged in
Overview

Artifact ID: 22e7b916b9aca9e814a211ed38c96f782f5d8bed
Ticket: cb42aa912604fcf1377936880c385386a863d284
SQLite.Interop.dll doesn't get coppied to output directory when not a direct dependancy on SDK style projects
User & Date: anonymous 2020-02-11 20:54:21
Changes

  1. foundin changed to: "1.0.112"
  2. icomment:
    [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.
    
  3. login: "anonymous"
  4. mimetype: "text/x-markdown"
  5. private_contact changed to: "736061a37afdcd686c0dbef035a68052775f1ce3"
  6. severity changed to: "Important"
  7. status changed to: "Open"
  8. title changed to:
    SQLite.Interop.dll doesn't get coppied to output directory when not a direct dependancy on SDK style projects
    
  9. type changed to: "Packaging"