运行含CLR封装C++代码的C#控制台应用遇格式错误求助

Let’s break down this System.BadImageFormatException—it almost always boils down to architecture mismatches between your C++ engine, CLR wrapper, and C# project, even if you think you’ve set everything to x86. Here’s a step-by-step checklist to fix this:

1. Verify the CLR Wrapper’s Actual Output Architecture #

Even if you’ve set the project to Debug x86, double-check these settings in your CLR wrapper project properties:

• Go to Build > Platform target and ensure it’s explicitly set to x86 (not "Any CPU").
• Open Build > Advanced and confirm the Target CPU is x86.
• To be 100% sure, use the dumpbin tool to inspect the wrapper DLL:

  dumpbin /headers Clrcs.dll
  

  Look for the machine field—you should see x86 (14C); if it says x64 (8664), your wrapper is compiling to 64-bit despite the settings.

2. Confirm Your C++ Engine DLL’s Architecture #

You mentioned the engine works in a C++ console app, but was that console app also built for x86? Use the same dumpbin command on your engine DLL to confirm it’s 32-bit. If the engine is x64 and your wrapper/C# project are x86 (or vice versa), this mismatch will trigger the exception immediately.

3. Force .NET Core to Run in 32-bit Mode #

.NET Core has a habit of auto-selecting the architecture based on your system, even if you set the project to x86. Fix this by:

• In your C# project properties, go to Build > Runtime identifier and set it to win-x86 (this locks the output to 32-bit).
• When running locally, use the command line instead of double-clicking the EXE:

  dotnet run --runtime win-x86
  

• If you’re publishing, make sure to select win-x86 as the target runtime to avoid mixed-architecture outputs.

4. Ensure All Required DLLs Are in the Output Directory #

Your C# EXE needs both the CLR wrapper DLL and the underlying C++ engine DLL (plus any SFML/OpenGL dependencies) in its output folder (e.g., bin/Debug/netX/win-x86):

• In your CLR wrapper project, set the wrapper DLL’s Copy to Output Directory property to Copy always.
• For the C++ engine DLL and SFML libraries, add them as references to your C# project (or manually copy them) and set their Copy to Output Directory to Copy if newer.

5. Check .NET Version Compatibility #

Make sure your CLR wrapper and C# project target the same .NET Core version (e.g., both .NET Core 3.1 or both .NET 6). Mismatched versions can lead to unexpected loading errors, even if architecture is correct.

6. Debug the Module Load Process #

Instead of double-clicking the EXE, run your C# project in Visual Studio Debug mode. Open the Modules window (Debug > Windows > Modules) to see exactly which DLLs are being loaded. Look for:

• Any DLL marked as x64 in the Platform column—this is the culprit.
• Missing DLLs (they’ll show up with a warning icon), which might indicate you’re missing a dependency like SFML’s 32-bit runtime libraries.

A quick note specific to your SFML/OpenGL engine: Ensure you’re using the 32-bit versions of SFML’s binaries (both the runtime DLLs and import libraries). Even a single 64-bit SFML dependency will break the 32-bit loading chain.

内容的提问来源于stack exchange，提问作者Marian Baňas