System.BadImageFormatException: Could not load file or assembly (from installutil.exe)

Some more detail for completeness in case it helps someone...

Note that the most common reason for this exception these days is attempting to load a 32 bit-specific (/platform:x86) DLL into a process that is 64 bit or vice versa (viz. load a 64 bit-specific (/platform:x64) DLL into a process that is 32 bit). If your platform is non-specific (/platform:AnyCpu), this won't arise (assuming no referenced dependencies are of the wrong bitness).

In other words, running:

%windir%\Microsoft.NET\Framework\v2.0.50727\installutil.exe

or:

%windir%\Microsoft.NET\Framework64\v2.0.50727\installutil.exe

will not work (substitute in other framework versions: v1.1.4322 (32-bit only, so this issue doesn't arise) and v4.0.30319 as desired in the above).

Obviously, as covered in the other answer, one will also need the .NET version number of the installutil you are running to be >= (preferably =) that of the EXE/DLL file you are running the installer of.

Finally, note that in Visual Studio 2010, the tooling will default to generating x86 binaries (rather than Any CPU as previously).

Complete details of System.BadImageFormatException (saying the only cause is mismatched bittedness is really a gross oversimplification!).

Another reason for a BadImageFormatException under an x64 installer is that in Visual Studio 2010, the default .vdproj Install Project type generates a 32-bit InstallUtilLib shim, even on an x64 system (Search for "64-bit managed custom actions throw a System.BadImageFormatException exception" on the page).

Make sure the newest Framework (the one you compiled your app with) is first in the PATH. That solved the problem for me. (Found on a forum)

The key is to set match processor settings for the project which are at two places.

And also make sure the architecture settings is same in Test menu >> Test Settings >> Default Processor Architecture >> as show below.

This is for VS2013 but maybe same for other versions too.

Update - For VS2019:

I had this issue with a WinForms Project using VS 2015. My solution was:

1. right click the Project
2. select properties
3. check "Prefer 32-bit"
4. Platform target: Any CPU

After trying all the mentioned solutions I found the PlatformTarget somehow added to AnyCPU configuration in my project .csproj.

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>bin\Release\</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <PlatformTarget>x64</PlatformTarget>
</PropertyGroup>

Removing the line worked for me.

In my case I used Framework64 like below

cd\
cd "C:\Windows\Microsoft.NET\Framework64\v4.0.30319"
installutil.exe "C:\XXX\Bin\ABC.exe"
pause

I have faced this issue today. In my case, my application's (had a reference to a 64-bit dll) platform target was set to AnyCPU but Prefer 32-bit check box under platform target section was ticked by default. This was the problem and worked all fine after un-checking Prefer 32-bit option.

Summarizing, both the Build and Project\Build\Platform has to be set to x64 in order to successfully install 64 bit service on 64 bit system.

In the case of having this message in live tests, but not in unit tests, it's because selected assemblies are copied on the fly to $(SolutionDir)\.vs\$(SolutionName)\lut\0\0\x64\Debug\. But sometime few assemblies can be not selected, eg., VC++ dlls in case of interop c++/c# projects.

Post-build xcopy won't correct the problem, because the copied file will be erased by the live test engine.

The only workaround to date (28 dec 2018), is to avoid Live tests, and do everything in unit tests with the attribute [TestCategory("SkipWhenLiveUnitTesting")] applied to the test class or the test method.

This bug is seen in any Visual Studio 2017 up to 15.9.4, and needs to be addressed by the Visual Studio team.

Target build x64 Target Server Hosting IIS 64 Bit

Right Click appPool hosting running the website/web application and set the enable 32 bit application = false.

We found a different solution to a problem with the same symptom:

We saw this error when we updated the project from .net 4.7.1 to 4.7.2.

The problem was that even though we were not referencing System.Net.Http any more in the project, it was listed in the dependentAssembily section of our web.config. Removing this and any other unused assembly references from the web.config solved the problem.

The problem is that every System.BadImageFormatException: Could not load file or assembly including the ones not associated with installutil.exe at all point to this very thread.

1. If your issue is related to WindowsBase or PresentationFramework dlls and you got analyzers installed make sure to either have them installed for all of the projects in your solution or for none of them.

   

2. Reference the entire framework in .csproj file of your library rather than just the two dlls:

   <Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
   
     <PropertyGroup>
       <OutputType>Library</OutputType>
       <TargetFramework>netcoreapp3.0</TargetFramework>
       <RazorLangVersion>3.0</RazorLangVersion>
       <UseWpf>True</UseWpf>
     </PropertyGroup>
   

3. Remove bin and obj dirs, clean solution and rebuild.

I used the PowerShell command line which solved the issue for me!

https://docs.microsoft.com/en-us/dotnet/framework/windows-services/how-to-install-and-uninstall-services

I found that the size of InstallUtil.exe = 0 KB in C:\Windows\Microsoft.NET\Framework\v4.0.30319 directory. I replaced InstallUtil.exe from another server and I could install the service.