BadImageFormatException x64 Issue

This error happened to me installing a .Net 4.5+ service to a 64-bit machine.

• The installer was set to x64
• The service project build platform was set to x64

Installation fails with a BadImageFormatException.

For me, the solution was to go to the service project properties, and change the build platform to "Any CPU", and also uncheck the "Prefer 32bit" checkbox that was checked by default (see also what does it mean).

I have finally figured this out – it has NOTHING to do with architecture, references or any other nonsense and everything to do with the installer itself. As this article explains – the Visual Studio Installer, by default, uses a 32 bit DLL and that is what causes the failures.

To overcome this problem, simply follow these steps:

1. Make sure that you go into the Properties ⇒ Build tab for every project and set the Target Platform to x64
2. Click on the name of your Installation project and then Properties and ensure that the Target Platform is x64
3. Build your solution – if the solution does not compile, right click and Unload Project and then Load Porject for those projects whose references fail.
4. Go here and download and install the 7.0 INstaller SDK
5. Go into the C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin folder and install Orca by double-clicking on the Orca.Msi file
6. Run Orca and open your project's MSI folder
7. Select the Binary table
8. Double click the cell [Binary Data] for the record InstallUtil
9. Make sure "Read binary from filename" is selected
10. Click the Browse button Browse to C:\Windows\Microsoft.NET\Framework64\v4.0.30319
11. Select InstallUtilLib.dll
12. Click the Open button and then the OK button

That is it - save your MSI file in Orca and then deploy it – the x64 installation should work without any further issues.

I just ran into this issue myself, in Visual Studio 2017, building an installer for an x64 version of an application that's been x86 for a long time.

I don't doubt that Ken's answer is definitive, but it occurred to me that as the Custom Actions are called by the installer, not by the installed application, there is no need, in my case at least, for the project containing the Custom Actions to have the same bitness as the rest of the application, as its classes are never instantiated by the application itself.

So I changed the platform for that project alone back to x86, and rebuilt the installer.

It all 'just worked'.

This depends, of course, on having Custom Actions that are completely isolated from the rest of the solution. Quite a relief not to have to use Orca however.