1

I've been going circles on this one for over a day now. I have a WPF project that is making use of sqlite-net-pcl.

I'm ready to package this project up into an MSI for distribution (x64). The first hitch was that I need to directly add the nuget for the dependency (SQLitePCLRaw.bundle_green). I've come across this before when a nuget package contains content files that need to find their way into the final release. Smooth sailing.

At this point, the bin/x64/release is good and runs fine. However, when I build an installer and run the installed version I get the following exception:

System.BadImageFormatException: Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Reference assemblies should not be loaded for execution. They can only be loaded in the Reflection-only loader context. (Exception from HRESULT: 0x80131058) ---> System.BadImageFormatException: Cannot load a reference assembly for execution.

Doing a file compare between my release folder and the application install folder I find the following:

    Binary Difference: System.Buffers.dll
    Binary Difference: System.Numerics.Vectors.dll
    Binary Difference: System.Runtime.CompilerServices.Unsafe.dll
    Installer Only: netstandard.dll
    Installer Only: System.Diagnostics.Tracing.dll
    Installer Only: System.IO.Compression.dll
    Installer Only: System.IO.Compression.FileSystem.dll
    Installer Only: System.Net.Http.dll

After inspecting further and digging in to the DLLs, I find if I overwrite System.Runtime.CompilerServices.Unsafe.dll with the binary from my release folder everything works.

Digging in even further and inspecting the installer version of CompilerServices.Unsafe I realize that the installer is grabbing the dotnet core version of the DLL.

I've isolated this down to a single console app with a fresh installer project and only adding the content and output to the installer.

Why is the installer insisting that the dependency is a dotnet core version?

大陸北方網友
  • 3,696
  • 3
  • 12
  • 37
JKoplo
  • 1,562
  • 1
  • 10
  • 13

1 Answers1

1

I'd like to find a real solution, but in the meantime I found some confirmation and a dirty workaround in this thread: https://developercommunity.visualstudio.com/content/problem/810090/visual-studio-installer-projects-extensions-incorr.html

Workaround option 1: In addition to adding the “Primary Output” of the project containing the package reference also add “Locally-Copied Items” for that project. This will result in the lib version of the assembly overwriting the ref version, giving you the behavior you want. However, you’ll also get a warning about the duplicate file being added, since as I said the lib version will be overwriting the ref version. This also could bring in additional files like xml doc files that should have no impact at runtime but may increase the size of the installer. These can also be individually excluded from the setup project.

JKoplo
  • 1,562
  • 1
  • 10
  • 13
  • Since you have a workaround, you could mark your answer. Thanks:) – Mr Qian Aug 31 '20 at 02:25
  • 1
    It's a really really bad workaround and it actually seems to only fix the issue on some builds after more testing. I don't think it's good enough to mark as an answer, but it might help someone in the future so I wanted to post it. – JKoplo Sep 01 '20 at 06:12