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..
This question is related to
.net
windows-services
x86
64-bit
x86-64
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.
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
:
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
<PropertyGroup>
<OutputType>Library</OutputType>
<TargetFramework>netcoreapp3.0</TargetFramework>
<RazorLangVersion>3.0</RazorLangVersion>
<UseWpf>True</UseWpf>
</PropertyGroup>
Remove bin
and obj
dirs, clean solution and rebuild.
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.
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.
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.
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.
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.
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.
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.
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 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
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
:
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
<PropertyGroup>
<OutputType>Library</OutputType>
<TargetFramework>netcoreapp3.0</TargetFramework>
<RazorLangVersion>3.0</RazorLangVersion>
<UseWpf>True</UseWpf>
</PropertyGroup>
Remove bin
and obj
dirs, clean solution and rebuild.
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.
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.
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.
I had this issue with a WinForms Project using VS 2015. My solution was:
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 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.
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).
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.
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.
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).
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.
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.
I had this issue with a WinForms Project using VS 2015. My solution was:
Source: Stackoverflow.com