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?
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.
User contributions licensed under CC BY-SA 3.0