0

I have a WCF Service and a library, both being compiled for x64. The library has some NuGet packages which "appear" to be 32-bit. I get a System.BadImageFormatException when I try to run or publish the WCF Service but, oddly, I don't get any warnings about mismatching architectures.

The full text of the error: Additional information: Could not load file or assembly 'Library' or one of its dependencies. An attempt was made to load a program with an incorrect format.

As a test, I created a separate console application, added a reference to the library, made the architectures for both the console application and the library x64, and ran the console application. Same error.

The WCF Service application will be hosted in IIS and is being debugged with the WCF Test Client.

The NuGet packages I am using are these:

  • CsvHelper (Josh Close), v2.16.3
  • Newtonsoft.Json (James Newton-King), v9.0.1

I need to be able to run the service and library in 64-bit mode since I'm work with very large datasets, and need the extra RAM. My questions are

  • Is my problem that the NuGet packages are not compiled for x64?
  • How can I get this WCF service to run in this setup?
wizard07KSU
  • 754
  • 6
  • 14

1 Answers1

1

My problem was multi-part:

  1. I did have to re-compile the libraries that I was using for x64. They had been compiled for Any CPU, which the runtime environment didn't like after loading an explicit x64 assembly.
  2. DLL Hell
  3. IIS was running in 32-bit mode.

First Issue:

I downloaded the source for the two libraries from GitHub and rebuilt for x64. I added conditional compilation to the assembly references in the project files to facilitate switching back and forth between x64 and x86:

<Reference Include="CsvHelper" Condition="'$(Platform)' == 'x86'">
  <HintPath>..\..\..\libraries\x86\CsvHelper\CsvHelper.dll</HintPath>
</Reference>
<Reference Include="CsvHelper" Condition="'$(Platform)' == 'x64'">
  <HintPath>..\..\..\libraries\x64\CsvHelper\CsvHelper.dll</HintPath>
</Reference>

To verify that my assemblies were actually x64, I found this answer very useful. The utility can be run from the Visual Studio Developer Command Prompt.

Second Issue:

Since I'm dealing with a large code base (42 projects), I had to do a complete clean to get rid of a x86 assembly that was getting copied around from ... somewhere. Cleaning through Visual Studio didn't help; I had to clean my Git repository to get rid of all old DLLs. Cleaning will only help this if your bin and obj folders are ignored by Git.

Third Issue:

I (eventually) found this post (closing and reopening your project/solution/Visual Studio is also necessary after this step). This setting can also be accessed as indicated here. After updating this setting, I had to restart IIS. Instructions for that are available on MSDN. I will add that it might be helpful to first start a separate command prompt with elevated privileges before executing that command, otherwise the command prompt opened by the run window flashes into and out of existence too quickly to see what appeared in it.

Community
  • 1
  • 1
wizard07KSU
  • 754
  • 6
  • 14