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

19

122

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..

Brighton answered 27/11, 2008 at 7:39 Comment(0)
B
16

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)

Brighton answered 27/11, 2008 at 7:39 Comment(3)
That link seems to be gone. Not too surprising though. 6 years ago.Planetstruck
Here it is at Archive.org web.archive.org/web/20100527204545/http://www.issociate.de/…Brighton
I wished it would have been better if they showed us what PATH they set.. I am struggling on this from past 2 hours...Pungent
E
166

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).

Elm answered 29/1, 2010 at 9:18 Comment(2)
I had same issue, when I start debugging according to what you said above, i found that Platform: was set as x86. When I changed it to Any CPU, it worked :)Ketubim
I have my windows installer with Custom actions. My setup needs to run on x64 system, so the Custom actions properties have to check the option "Run64Bit" in true. It solved my problem.Overboard
M
19

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

enter image description here

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

enter image description here

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

Update - For VS2019:

enter image description here

Musa answered 15/5, 2019 at 19:51 Comment(2)
This is the correct way to fix this error. That is, if you don't want to mess around with possibly hundreds of csproj files.Lazes
Thank you! Was trying to run tests and getting 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.Agape
B
16

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)

Brighton answered 27/11, 2008 at 7:39 Comment(3)
That link seems to be gone. Not too surprising though. 6 years ago.Planetstruck
Here it is at Archive.org web.archive.org/web/20100527204545/http://www.issociate.de/…Brighton
I wished it would have been better if they showed us what PATH they set.. I am struggling on this from past 2 hours...Pungent
C
11

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.

Contrive answered 5/7, 2013 at 7:35 Comment(2)
That was the scenario for me. Very helpfull answer.Osset
At least link the original answer: stackoverflow.com/revisions/5229405/1Disjunction
L
7

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.

Lubalubba answered 23/1, 2013 at 8:43 Comment(1)
I don't know what you mean by the 32-bit version but I tried the one here and it did not work either C:\Windows\Microsoft.NET\Framework\v2.0.50727Hodgkins
P
6

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
Phosphoric answered 31/12, 2018 at 8:21 Comment(0)
A
4

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.

Additional answered 15/8, 2018 at 6:49 Comment(3)
In my case, where I want a 64 bit build, one of the PropertyGroup nodes was missing the <PlatformTarget>x64</PlatformTarget> node, so presumably it was defaulting to 32 bit and throwing the bad image format error. Once I added this missing node to the property group the error disappeared.Ammonic
Trying this solution led to another problem for me, which was app.config's appSettings not being loaded during runtime despite that the config file was present in the output directory. however, after trying zar's approach (Processor Architecture for AnyCPU Projects) everything start working again.Lazes
Thank you for this, I had in the Property window it set to x86 but when I looked at the csproj file it was AnyCPU. Swapping it over to x86 solved my issueInadvertency
P
4

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
Pungent answered 28/12, 2020 at 18:14 Comment(0)
A
1

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.

Airsick answered 13/3, 2019 at 9:12 Comment(0)
B
0

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.

Bianchi answered 27/1, 2016 at 11:57 Comment(0)
F
0

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.

Fachanan answered 6/10, 2016 at 0:27 Comment(0)
C
0

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.

Cephalic answered 20/3, 2018 at 20:7 Comment(0)
K
0

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.

Kazantzakis answered 28/12, 2018 at 22:8 Comment(0)
B
0

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.

enter image description here

Bandoleer answered 18/1, 2019 at 19:50 Comment(0)
B
0

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.

Basseterre answered 10/5, 2019 at 16:13 Comment(0)
C
0

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.

    enter image description here

  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.

Chrysoprase answered 5/12, 2019 at 21:46 Comment(0)
G
0

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

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

Gregson answered 10/6, 2022 at 12:4 Comment(0)
D
0

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.

Dev answered 10/8, 2022 at 17:27 Comment(0)
M
0

I had such issue when dependency to PresentationFramework was missed in .csproj with the wix project in the same solution. This is in VS 2022.

Multiplier answered 27/3, 2023 at 14:6 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.