Search code examples
c#visual-studiouwpnugetc++-cx

UWP app tries to load packaged native .exe file as C# assembly

I have a nuget package with a native library and an .exe program (MinidumpWriter.exe), which is used for handling crashes. The library works by invoking the packaged exe by a given protocol (which is registered in Package.appxmanifest and specified during the initialization of the C# wrapper). This package is referenced from a UWP C++ library, where a C# wrapper class is implemented for the native library. This C++ UWP library is then used in C# XAML project.

This approach works on multiple other projects, but not one particular, which doesn't have anything different in its manifest, csproj or generated .appxrecipe in relation to MinidumpWriter.exe. In the problematic project the app fails to launch because it tries to load the native .exe file as a C# assembly and fails with exception

System.BadImageFormatException: 'Could not load file or assembly 'MinidumpWriter, Culture=neutral, PublicKeyToken=null'. The module was expected to contain an assembly manifest.'

More than that, any native .exe file in the app package is treated the same (which for sure doesn't happen in other C# UWP projects).

The exception occurs in XamlTypeInfo.g.cs: Exception

I'm using Visual Studio Community 2022 Version 17.8.3.

Things I've tried so far:

  • Moving the copying logic for .exe file from .targets file that's packaged in nuget to the .vcxproj file (thought that maybe explicitly specifying the .exe as content would help, but no - result is the same).
  • Changing SDK versions around.
  • Created a new C# UWP project, included the C++ UWP library described above, and registered the protocol in the manifest. For this new project everything works correctly. Upon comparing project files and manifests between this project and the problematic one, I found no difference.
Solution

  • After hours of searching for possible cause or similar cases of this bug, I decided to just do a VS version rollback from 17.8.3 to 17.5.5.

    This fixed the problem.

    If this was a bug, perhaps it's fixed in newer versions, but i can't afford spending hours updating, rebuilding the project and then rolling back again. That's how VS is, I guess.