System.Data.SQLite

When compiling an application that targets multiple platforms, the platform dependent SQLite.Interop.dll is copied to the application output directory. E.g. When targeting the x86 platform application.x86.exe is created. When targeting the x64 platform application.x64.exe is created. Both applications have the same dependencies, however they cannot be deployed in the same directory due to the platform specific SQLite.Interop libraries having the same filename. This issue can be fixed by deploying the platform specific version of the SQLite.Interop.dll into subfolders in the build output directory and adding <dependentAssembly> sections to the app.config files that indicate where to find the platform specific assembly. E.g. The following would allow an application that targets the AnyCPU platform to correctly load the platform specific version of the SQLite.Interop.dll.

<dependentAssembly>
   <assemblyIdentity name="SQLite.Interop.dll" processorArchitecture="x86" culture="neutral"/>
   <codeBase version="1.0.113.0" href="x86/SQLite.Interop.dll"/>
</dependentAssembly>
<dependentAssembly>
   <assemblyIdentity name="SQLite.Interop.dll" processorArchitecture="amd64" culture="neutral"/>
   <codeBase version="1.0.113.0" href="x64/SQLite.Interop.dll"/>
</dependentAssembly>

For x86 or x64 applications only one of the above sections is needed. The same may also be accomplished by using platform dependent file names and similar <dependentAssembly> sections.

This issue is caused by a lack of support for transitive builds. Our application depends on a package which depends on System.Data.SQLite.Core. That package had exclude="Build,Analyzers" for System.Data.Sqlite.Core specified due to how dotnet pack built the package. There are two ways to fix this issue:

1. Support transitive builds by adding a /buildTransitive folder to the System.Data.SQLite.Core.NetFramework package that is a duplicate of the /build folder.
2. We modify our .csproj for the dependent package to specify <ExcludeAssets>none</ExcludeAssets> inside the <PackageReference> for System.Data.SQLite.

Given that I will not be the last person to encounter this issue, I suggest implementing #1 in the System.Data.SQLite.Core.NetFramework package.

Thank you for the quick fix for this. I believe the changes you have made will correct the issue. Given that there probably won't ever be any differences to the .targets in /build and in /buildTransitive you can probably simplify the .targets in /buildTransitive to just import the .targets from /build. From the documentation it looks like it will only use one set of targets during build either from /build or /buildTransitive not both.

FYI, this change broke multi-platform build. Previously we built single netcore target on windows and used it on win/linux/osx without changes. Now for linux/osx builds it cannot locate native dlls/libs and we need to copy them to expected location.

I don't think supporting transitive builds is what is causing your problem. I think your problems stem from spitting the .Net Standard support from the .Net framework support into two separate packages. Transitive build support only ensures that the .Net Framework .targets files get run when an application depends on a package that depends on the SQLite package. If you are not targeting the .Net Framework then the .targets files should not have been used.

The 1.0.113.1 version of the packages had an invalid /runtimes structure that caused multiple copies of the SQLite.Interop.dll files to be found during build. The directory structure of that version resembled the following:

/build
   /net46
      /x86
         SQLite.Interop.dll
      /x64
         SQLite.Interop.dll
      System.Data.SQLite.Core.targets
/runtimes
   /win-x86
      /native
         /netstandard2.0
            SQLite.Interop.dll
         /netstandard2.1
            SQLite.Interop.dll
   /win-x64
      /native
         /netstandard2.0
            SQLite.Interop.dll
         /netstandard2.1
            SQLite.Interop.dll

When System.Data.SQLite.Core was a direct dependency of an application that targets .Net Framework 4.6, the SQLite.Data.SQLite.Core.targets file would copy the /x86 and /x64 directories from the /net46 directory to the build output directory. However, if you were creating an x86 or x64 application, msbuild would also find both copies of SQLite.Interop.dll under the platform dependent /netstandard2.0 and /netstandard2.1 directories and attempt to copy them to the output directory as well. This was due to the fact that the path to these files should have been /runtimes/win-x86/lib/{framework}/SQLite.Interop.dll if framework dependent versions were needed OR /runtimes/win-x86/native/SQLite.Interop.dll otherwise. The Linux and Mac OS X directories had the same structure and would have had the same issues. The latest version of the packages uses the latter approach of using a common library in the native directory, but also moves all .Net Standard files to a separate package.

I'm not saying that transitive builds support broke it, just trying to say that changes in this fix caused new issues(regressions). Anyway I've already filled new issue here https://system.data.sqlite.org/index.html/tktview/83e8001008fdfb8307aa0264c7c4a23f8ab00f71

Ah, sorry. It is already fixed in https://system.data.sqlite.org/index.html/tktview/eb04d8c55f685ea3a302a77a42bd902f19a50b25