I am trying to install a Windows service using InstallUtil.exe and am getting the error message
System.BadImageFormatException: Could not load file or assembly '{xxx.exe}' or one of its dependencies. An attempt was made to load a program with an incorrect format.
What gives?
EDIT: (Not by OP) Full message extracted from dup getting way more hits [for googleability]:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319>InstallUtil.exe C:\xxx.exe Microsoft (R) .NET Framework Installation utility Version 4.0.30319.1 Copyright (c) Microsoft Corporation. All rights reserved. Exception occurred while initializing the installation: System.BadImageFormatException: Could not load file or assembly 'file:///C:\xxx.exe' or one of its dependencies. An attempt was made to load a program with an incorrect format..
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.
https://i.stack.imgur.com/4Jk8k.png
And also make sure the architecture settings is same in Test menu >> Test Settings >> Default Processor Architecture >> as show below.
https://i.stack.imgur.com/z5v3C.png
This is for VS2013 but maybe same for other versions too.
Update - For VS2019:
https://i.stack.imgur.com/ZYf5f.png
BadImageFormatException
on IBM.Data.DB2.Core
. Turned out that my new laptop and new VS2022 install was set to use x86 for testing of AnyCPU Projects. Switching it to x64 fixed the issue.
I think you are using the 64-bit version of the tool to install a 32-bit application. I've also faced this issue today and used this Framework path to cater .
C:\Windows\Microsoft.NET\Framework\v4.0.30319
and it should install your 32-bit application just fine.
OK, this is the problem I had, and, what fixed it, seems very relevant to the above.
I am using Visual Studio 2010 Express. I wrote a test service that didn't really do anything. It was just practice for the real thing later.
I wrote the service and tried to install it using installutil.exe
and got the following error:
System.BadImageFormatException: Could not load file or assembly '{filename.exe}' or one of its dependencies. An attempt was made to load a program with an incorrect format.
So far the same as the original author.
Ruben's observation above about the 32 bit output of Visual Studio 2010 was the saviour here.
I used the 64-bit version of the installutil.exe
and sure enough, the output of the Visual Studio 2010 build was 32-bit. Just to add a little extra value here, you can find the 32-bit version of the latest .NET framework and the associated installutil.exe
in the C:\Windows\Microsoft.NET\framework folder. Using this version of the installutil.exe
fixed my problem; the service installed without a hitch!
I hope this helps someone else out there.
I had this issue with a WinForms Project using VS 2015. My solution was:
right click the Project select properties check "Prefer 32-bit" 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.
Processor Architecture for AnyCPU Projects
) everything start working again.
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.
I had the same issue. I using the standard command for execution. It was calling the X64 ro run against X86 tests. I needed to specify the X86 and not the X64 version of the nunit-runner.
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.
My issue was different. This occurred after an unexpected shutdown of my windows 7 machine. I performed a clean solution and it ran as expected.
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.
https://i.stack.imgur.com/CTs3s.png
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.
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. Reference the entire framework in .csproj file of your library rather than just the two dlls:
I used the PowerShell command line which solved the issue for me!
Success story sharing