System.Data.SQLite

Login
This project makes use of Eagle, provided by Mistachkin Systems.
Eagle: Secure Software Automation
Ticket Hash: 5a35f3a26aea5204a768705816715f730efb8fd5
Title: BadImageFormatException with SDK style .Net Framwork project
Status: Closed Type: Incident
Severity: Minor Priority: Medium
Subsystem: NuGetPackage Resolution: Duplicate
Last Modified: 2021-05-02 18:20:11
Version Found In: 1.0.112
User Comments:
anonymous added on 2019-11-04 14:36:55:
When using System.Data.SQLite in a .Net Framework project using the new SDK *.csproj file format a BadImageFormatException is triggered when opening a database connection.

Build environment
-----------------
* Visual Studio 2019 (16.3.7)
* SDK style *.csproj, TargetFramework "net472"

A minimal example project will be attached.

With .Net Framework projects the native interop files are placed in x86 and x64 subfolders in the build output directory, enabling SQLite to work when called from both 32 bit and 64 bit applications.

When the new SDK style *.csproj format is used for a .Net Framwork project, a single *additional* interop is copied:
During build the target "_CopyFilesMarkedCopyLocal" (verbose build output needed in Visual Studio to see this) the file "system.data.sqlite.core\1.0.112\runtimes\win-x86\native\netstandard2.0\SQLite.Interop.dll" is copied directly in the "\bin\Debug\net472" output folder. This file seems to have precedence over those in the x86 and x64 subfolders, triggering a BadImageFormatException when the application is started in 64bit mode.

When this additional interop file is deleted from the output directory after the build, the application can be used without triggering the exception (no problem for deploy, but unpractical when debugging in VS).

The problem does not exist with the legacy format for .Net Framework projects, or with the new format for .Net Core projects.

I am aware that currently only legacy *.csproj files are officially supported. Therefore I am marking this as "Minor". See also a previous issue I had with a similar setup: [b2c278db3884e37e]

mistachkin added on 2019-12-08 04:40:57:

This sounds like a bug in the "_CopyFilesMarkedCopyLocal" build target. I'm not sure how this could be worked around from within the NuGet package.


anonymous added on 2019-12-18 05:14:58:

Try specified RuntimeIdentifier or RuntimeIdentifiers for workaround

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net472</TargetFramework>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
  </PropertyGroup>
</Project>

anonymous added on 2020-10-16 14:13:11:

I'm running into this same issue. The stated workaround did not work for me, because the assembly I'm building is built as "Any CPU" (so I need both SQLite.Interop.dll files and the extraneous copied version is always one or the other). I haven't been able to track down the root cause of the extra DLL, beyond what's given in the original ticket.


mistachkin added on 2020-10-24 19:06:47:
This issue may be related to (or a duplicate of) [ba4a3a4ac5e06a40].

mistachkin added on 2020-10-28 01:40:42:

This issue may be fixed on trunk (and in the newly deployed NuGet packages).

If possible, please test them in your environment and let us know.