I have two projects, ProjectA and ProjectB. ProjectB is a console application, which depends on ProjectA. Yesterday, everything was working fine, but suddenly today when I run ProjectB I get this:
BadImageFormatException was unhandled:
Could not load file or assembly 'ProjectA, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Both are just regular projects, with no dependencies on any other non-.Net projects. Both are fully .Net - there is no native code, and no P/Invoke. I have other projects which depend on ProjectA and still work just fine.
Things I have tried:
Make sure both projects are set to "Any CPU," with the build checkbox checked. They are.
Make sure both projects are for the same Target Framework (.Net 4.0 Client Profile).
Under ProjectB --> References --> ProjectA --> Properties, make sure "Copy Local" is set to "True" _ (I verified that ProjectA.dll is being copied correctly)
Clean/Rebuild the solution. I even tried manually deleting the /bin and /obj folders in both projects.
Restart Visual Studio. Restart my computer.
Check out an entirely new copy of the repository.
But I still get the same error. I have no idea what I did to cause this, nor how to fix it. Any ideas?
I am pretty sure you're having a 32-bit / 64-bit conflict. It sounds like your main project might be set to 32-bit while the class its referencing is set to 64-bit. Try looking at this SO question and this one too. Between the two of them, you should be able to figure out your problem.
Might be you are facing the problem with your website after deploying on server.
Then you need to adjust your application pool to Enable 32-Bit Applications.
Steps
Open IIS Manager
Click on Application Pools
Select whatever application pool you are using
From right pane, click Advanced Settings...
Set Enable 32-Bit Applications to True
I just had this error message running IIS Express in Visual Studio 2015. In my case I needed to be running the 64 bit version of IIS Express:
Tools → Options → Projects and Solutions → Web Projects
Check the box
that says "Use the 64 bit version of IIS Express for web sites and
projects".
Screenshot:
I had this same problem. I had set Project A's "Platform Target" ("Project A"(Right Click)->Properties->Build->"Platform Target") to x86 but kept Project B's at "Any CPU". Setting Project B's to "x86" fixed this.
I had this problem running unit tests (xunit) in Visual Studio 2015 and came across the following fix:
Menu Bar -> Test -> Test Settings -> Default Processor Architecture -> X64
You may need to change the Appication Pool setting "Enable 32bit Applications" to TRUE in IIS7 if you have at least 1 32bit dll\exe in your project.
First of all I got this in VS2017 with an old project I needed to make a tiny change to and upraded all the projects to framework 4.7.
Several others have mentioned selecting Any CPU can fix this issue.
There's a couple places you need to do it, and it might not just be as simple as selecting from the dropdown. This fixed it for me:
1) You need to do it both here:
2) And also in Configuration Manager (right click on solution)
But what if it isn't there???
Then click New and choose these settings: (thanks #RckLN)
I had the same issue with multiple projects in the same solution, i ended up setting all of the target frameworks to .NET Framework 4 and x86 for the target CPU and it finally successfully compiled.
None of these solutions worked for me - but by deleting the contents of bin and obj folders everything was cool again.
The following solved the issue for me, uncheck 'Prefer
32-bit' :
For the newer version of visual studio (v16.10 for this answer), it can be fixed by manually changing the solution platform. For me it worked after changing from "Any CPU" to "x86".
Click on solutions platform dropdown, the one in which any CPU is appearing in image below.
Go to configuration manager.
Click on new and add platform x86 or x64 (32 or 64 bits) based on what is working for you.
Restart the project.
I also had this problem. As mention before the problem was related to a 32-bit / 64-bit conflict, but with the site hosted in Azure. To change the plattform in Azure App Service, go to Configuration -> General settings.
I got this when building a project via Visual Studio Online (VSTS) Build using Visual Studio Build Steps.
The solution was:
Delete the existing source folder
Explicitly set 'Any CPU' in the platform for all Visual Studio Builds including dependencies (see screenshot below).
Re-run the build
The Chilkat .NET 4.5 assembly requires the VC++ 2012 or 2013 runtime to be installed on any computer where your application runs. Most computers will already have it installed. Your development computer will have it because Visual Studio has been installed. However, if deploying to a computer where the required VC++ runtime is not available, the above error will occur:
Install all of the bellow packages
Visual C++ Redistributable Packages for Visual Studio 2013 - vcredist_x64
Visual C++ Redistributable Packages for Visual Studio 2013 - vcredist_x86
Visual C++ Redistributable Packages for Visual Studio 2012 - vcredist_x64
Visual C++ Redistributable Packages for Visual Studio 2012 - vcredist_x86
You might also see this issue if you're trying to package a 64bit project with an MSI installer in VS. ("The reason is because the native shim packaged with the .msi file is a 32-bit executable.")
See here for more details: http://blogs.msdn.com/b/heaths/archive/2006/02/01/64-bit-managed-custom-actions-with-visual-studio.aspx
In my case changing IIS Express Bitness from "Default" to "x86" helped.
All my projects had "x86" as the Platform target.
I encountered the same issue. It popped up out of the blue and that seemed strange to me.
In the Exception snapshot, for the FusionLog, I saw the following within its message:
... C:\Windows\Microsoft.NET\Framework64 ...
More about the fusion log: http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.110).aspx
All the projects had a Target CPU of AnyCPU. I changed the application project (the project that references all the other projects) to a Target CPU of x86. It now works.
Not sure how the Target CPU mix up occurred for no apparent reason, but it did.
I also face this problem in a project, after a few minutes i found the solution,
this problem is due to CPU configuration,
If you are using Visual Studio 2010 or VS 2013, just goto project 's properties and then select Compile from side bar and there will be 5 drop-down, 5th Drop-down will be Target CPU:, you should set it to x86 or x64 according to your requirements instead of Any CPU.
My problem was solved after changing it to x86.
This also can happen just by having multiple supported frameworks defined in the app.config file and, forcing the app to run in a different .NET framework other than the one mentioned first in the app.config file.
And also this fires when you have both of the mentioned frameworks available in your system.
As a workaround, bring up the target framework you are going to use for the debugging up in the app.config
ex: if you trying to run in .NET 4, config file should have something similar to this,
<supportedRuntime version="v4.0"/>
<supportedRuntime version="v2.0.50727"/>
In my project for C#, project property->[Build]->Platform target: Any CPU,
and uncheck the Prefer 32-bit to let compiler to choose automatically.
I also had this problem running unit tests by using ReSharper on Visual Studio 2017 and fixed it with following config:
Also you can change the ReSharper's run test setting:
https://resharper-support.jetbrains.com/hc/en-us/articles/207242715-How-to-run-MSTest-tests-using-x64-configuration
Shoot! I knew about this problem. I thought I was doing everything right until I accidentally saw 'x86' in the VS output window and that's when I got hold of the cause. Wasted a few mins on it today.
The configuration under 'Publish' window was set to 'x86'; whereas, everywhere else, it was 'x64'.
Please make sure it's in-sync across configuration manager, publish settings, solution configurations, and IIS settings (if that's your web server).
Also, please keep in mind - VS is a 32-bit app and IIS is 64 bit. 32-bit apps are disabled by default in IIS.
It can be a little funny, but I had the same problem with normal working code. I added StreamWriter and StreamReader and it gave that error.
The solution was I took that code into comment brackets then did debug and it started to work again
If you use LibreOffice from your program via cli .net integration like me, I got the same error. I use the older version of LibreOffice on the production environment on my PC I installed a newer version that was in conflict. Just uninstall LibreOffice. I found the solution here .NET CLI: Could not load file or assembly 'cli_cppuhelper'
In my case a dependency was missing in the dll that threw this exception. I checked with Dependency Walker, added the missing dll and the problem was resolved.
More specifically, I somehow corrupted my opencv_core340.dll by accidentally adding SVN keywords to it, and thus my dll could no longer use it. However I don't believe that the solution to this problem depends on whether the dll is corrupted or missing. I'm just adding this for the sake of giving complete information.
I have detected something different from the other answers. Reaching this exception in my project was the result of a corrupt compilation. Without making any changes, just forcing rebuild, it was fixed.
I had the same issue. Project B in my case was a .Net Core Class Library which has a Nuget "Microsoft.Management.Infrastructure" installed. The error was that i called my project B "MI". I changed the project name to something else and suddenly everything worked again.
Interesting as it goes, this can also happen if the folder path is long, which can cause build issues, oddly enough with this cryptic error message.
Just moving the folder up the path, solved the problem!
Are you trying to run your .exe file from the cmd? This was my mistake. Just run the .exe file by double clicking it. If it's a .NET Core SCD for Windows 8.1/Windows Server 2012 R2 x64.
In my case the error was System.BadImageFormatException: Could not load file or assembly 'vjslib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
It was solved by installing vjredist 64 from here.
I have a C# application that uses AutoItX for automation. This application works fine in my Windows 8.1 x64 environment compiled with Microsoft Visual Studio 2013 release 3.
I pushed a copy of the app code to a bitbucket repository and cloned it to a computer running Windows 7 x64. AutoItX version 3.14.2 was installed and the 32bit calls were selected. The application was compiled using Visual Studio 2013 release 4.
The app compiled fine, but the first use of the AutoIt functions resulted in an error:
An unhandled exception of type 'System.DllNotFoundException' occurred in AutoItX3.Assembly.dll
I tried the following steps. The app was tested after each of these steps
Attempted to register the .dll manually using regsrv32
regsrv32 "C:\Program Files (x86)\AutoIt3\AutoItX\AutoItX3.dll"
Uninstalled VisualStudio 2013 R4 and attempted to reinstall VisualStudio 2013 R3 {The installation of R3 failed because it required internet explorer version 10 and version 11 has already been installed on this computer} so R4 was reinstalled
Uninstalled AutoIt and reinstalled selecting the 64 bit library preference. Compiled the app with x64 Platform option
Uninstalled AutoIt and reinstalled using the 32 bit library preference
Compiled the app with the X86 Platform option
Manually copied AutoItX3.dll to the C:\windows\System32 directory
Manually copied AutoItX3_x64.dll to the c:\Windows\SysWOW64 directory. Compiled the app for x64 platform
Wiped computer clean and reinstalled windows 7, AutoIt (32 bit preference), Visual Studio 2013 R4
Installed AutoIt v14
Installed the beta version of AutoIt v15
Performed a Windows update - 213 updates (!) installed
Installed Internet Explorer v11
Performed a Windows update - 4 updates installed
Installed AutoIt version 3.10.2 that worked on the Windows 8 system
I would appreciate suggestions on what to try next. I'm probably missing something very basic, but I just can't find a solution
Manually copied AutoItX3.dll to the C:\windows\System32 directory
Manually copied AutoItX3_x64.dll to the c:\Windows\SysWOW64 directory. Compiled the app for x64 platform
That's the only thing you did wrong, you reversed the copies. There are no other DLLs you could be missing, the AutoItX3.dll and AutoItX3_x64.dll files themselves have no other dependencies that are not already available on any Windows machine. Just operating system DLLs, they've been around forever. Something you can see with Dumpbin.exe /imports.
And the exception message comes out of .NET, it is caused by a [DllImport] attribute. You can see the content of AutoItX3.Assembly.dll with a decompiler like ILSpy or Reflector. There is very little to it, only two DLLs are ever used. AutoItX3.dll for 32-bit code and AutoIt_x64.dll for 64-bit code.
Fairly tragic btw, otherwise a side-effect of ab/using the operating system directories for non-operating system DLLs. The only real way to make sense of why this is backwards is to know the history of Windows.
Back in the early days of Windows when it was still a 16-bit operating system (versions 1 through 3.11), c:\windows\system was the home directory for the operating system executables. Starting with NT 3.11 and Windows 95, the first 32-bit versions, that directory was renamed to c:\windows\system32. When the 64-bit version became available, Microsoft could not rename it to c:\windows\system64 anymore. Too many programs hard-coded the name of that directory in their source code. Breaking those programs would have been a good idea, just not a good strategy to get customers to move to the next version.
The 64-bit version has an emulator that can run 32-bit programs, it is called WOW64. "Windows on 64-bit Windows". The c:\windows\syswow64 directory is therefore the home directory of the 32-bit executables.
Exactly backwards from what the names would suggest. Just reverse the copies and that runtime error will disappear.
Generic advice applies:
The official way to get the loader to tell you about missing DLLs is to enable loader snaps. It is the most reliable way, albeit a bit clumsy.
Dependency Walker has not been maintained for a very long time and produces far too many false warnings. It also has a problem with .NET programs like this, it cannot see the dependency on AutoItX3.dll. You should still get something out of it when you use its Profile mode.
Process Monitor was always the best tool to troubleshoot missing DLLs. You'll see your program searching for the missing DLL, you can tell its name and the directories it looks in from the trace. Start near the bottom working backwards to avoid drowning in the data. I should however note that its been unreliable lately on the machine I use since ~Win81, the trace is just missing stuff I know should have been there. YMMV.
Such an issue can be caused by a missing DLL or a dependency of a missing DLL. I never got good results with Dependency Walker but I have successfully tracked down such issues with Process Monitor.
It should not be a 32/64 bit issue directly, since that would result in a BadImageFormatException instead.
You can debug missing DLL issues like this:
Start Process Monitor
Set a filter for your executable
Reproduce the issue (i.e. run your application)
Save the log in XML file format
Open the XML in Process Monitor Log Analyzer (Disclaimer: I'm the author of that free tool)
Check from top down which DLL is really missing. There may be some where the program can gracefully degrade, so not all of them are necessarily required.
Short solution
Copy and paste the AutoItX3.dll file to /bin/Debug or /bin/Release folder.
Project solution
What you can do is to put in the project's Post-build event command line:
copy /Y "$(SolutionDir)\packages\AutoItX.3.3.12.0\AutoItX3.dll" "$(ProjectDir)\bin\Debug"
copy /Y "$(SolutionDir)\packages\AutoItX.3.3.12.0\AutoItX3.dll" "$(ProjectDir)\bin\Release"
I have a DLL (FreeType) which is certainly 32-bit (header: IMAGE_FILE_MACHINE_I386).
I want to use it from C# code, using DllImport.
Target of my application is x86, IntPtr.Size is 4, process is 32-bit.
But I get BadImageFormatException (Exception from HRESULT: 0x8007000B). What can be wrong?
Of course I use 64-bit Windows 7.
From what I understand, an assembly specifically built for x86 and running in a 64-bit operating system can only load libraries built for x86 or a BadImageFormatException will be thrown. In a 64-bit OS, an assembly built for Any CPU or x64 will throw the same exception when trying to load an x86 library.
So, assuming nothing incredibly weird is going on, I would ensure that you've set your application to build as x86 by opening the project properties and clicking on the Build tab. Ensure 'Platform Target' is set as 'x86' and not Any CPU.
Alternatively, you could try to find a 64-bit version of the DLL for testing purposes.
Recompile the dll with the option "Any CPU" in Build -> Platform.
OK, seems like a false alert. It was not related to bitness, there was just other DLL missing that freetype depends on. However error messages could be more helpful.
Got the same error when calling a 64-bit C Dll from C#. I had to manually change C# Properties->Build->Platform target from Any Cpu to x64. Apparently Any Cpu is sometimes NoCpu.
Besides, for web-application needs resolve to run 32-Bit Applications in IIS 7. See http://www.fishofprey.com/2009/04/badimageformatexception-in-iis-70-on-64.html
I had a similar error.
I could solve it by adding the ucrtbase.dll or ucrtbased.dll for debug as well as the vcruntime140.dll or vcruntime140d.dll for debug into the directory of the executable.
I think the 140 depends on the version number of Visual Studio you are using.
ucrtbase.dll usually lies in C:\Windows\System32.
vcruntime140.dll lies in C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x86\vcruntime140.dll
You can find more information here: http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx
I suspect the common cause of this exception has changed in the 8 years since the question was first asked. On my setup using VS 2017 I found that unchecking "Prefer 32-bit" solved the issue:
Uncheck "Prefer 32-bit" in the Build options
This made my 64-bit DLL built from C++ load correctly. Conversely, checking this option should make 32-bit DLLs load correctly.
When you build a native application/DLL something with Visual Studio, it gains a dependency on the "redistributable" package for that version of Visual Studio. That contains DLLs like msvcr100.dll and msvcp100.dll (for various values of 100).
In my case, I had seen those DLLs in the target machine's Windows/system32 directory, so I thought all was well. It turns out that those DLLs were x64! I have no idea why a directory called system32 contains 64-bit DLLs. So I searched my Visual Studio 2010 directory for everything named msvc*.dll, and found x86 versions of msvcr100.dll and msvcp100.dll. I copied those to the target machine (in a place accessible from my program's path) and all was well.
I hope this helps someone else confronted with Microsoft's sheer madness.
you use Properties in C# project, and change "Platform target" to x64.
enter image description here
You can try check the option "Properties" -> "Build" -> "Allow unsafe code".
You have to look at the dependents of the DLL, since one of the dependents may use a 64 bit DLL which makes it incompatible with your project.
visual studio -> tools -> command line -> powershell
dumpbin /dependents your_dll_file.dll
and check these dll's and find out which one is actually not the same with your dll.
I had the same Exception in MS Visual C# Express 2010. I checked all build .dll and .exe files with Dependency Walker and MiTeC EXE Explorer, everything was build for 32bit!
In the end, it was the following line missing in my .csproj file:
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'MY_CONFIG|x86'">
...
<PlatformTarget>x86</PlatformTarget>
...
</PropertyGroup>
I don't know why it was missing ... I guess MS Visual C# Express 2010 is not bugfree ;)
I just checked out a revision from Subversion to a new folder. Opened the solution and I get this when run:
Could not load file or assembly 'xxxx' or one of its dependencies. An attempt was made to load a program with an incorrect format.
This is the same code I had checked in a while ago. Why now is it doing this? I now also see a Debug x86 instead of just Debug in that xxx project's bin folder. What is Debug x86 and why don't I just have Debug only like I used to in the bin folder?
Sounds like one part of the project is being built for x86-only while the rest is being built for any CPU/x64. This bit me, too. Are you running an x64 (or uh... IA64)?
Check the project properties and make sure everything is being built for "Any CPU". f you're in Visual Studio, you can check for everything by going to the "x86" or "Any CPU" menu (next to the "Debug"/"Release" menu) on the toolbar at the top of the screen and clicking "Configuration Manager..."
If you get this error while running the site in IIS 7+ on 64bit servers, you may have assemblies that are 32bit and your application pool will have the option "Enable 32-Bit Applications" set to False; Set this to true and restart the site to get it working.
I had this error when trying to use the dreadful Business Objects 4 for .Net SDK.
They ship five BusinessObjects*.dll files, but all of them are 64-bit.
To get my webpage to load, I needed to click on Tools\Options, then change this setting in VS2013:
inetmgr then come to Application pool->Advanced setting of your pool-> will have the option "Enable 32-Bit Applications" set to true;
and restart IIS.
check again.!
Make sure you verify your setting for "Prefer 32-bit". In my case Visual Studio 2012 had this setting checked by default. Trying to use anything from an external DLL failed until I unchecked "Prefer 32-bit".
The BadImageFormatException on an application running on IIS (not running from VS, since visual studio fixes the problem by using the build for "Any CPU") can be caused by the following:
The site is one a server that is x64 and the Application Pool's default setting for Enable 32-Bit Applications was False. and you have 32-bit assemblies
On the level of Visual Studio, the fix is:
Change the project setting "Target CPU" to "ANYCPU"
It's definitely an issue with some of the projects being built for x86 compatibility instead of any CPU. If I had to guess I would say that some of the references between your projects are probably referencing the dll's in some of the bin\debug folders instead of being project references.
When a project is compiled for x86 instead of 'Any CPU' the dll's go into the bin\x86\debug folder instead of bin\debug (which is probably where your references are looking).
But in any case, you should be using project references between your projects.
if while In visual studio with IIS express working and when published failed try this:
In my case It worked by going to project Properties and under Target Framework i selected .NET Framework 4. This is because i have moved to a new machine that had other higher .NET frameworks already installed and the project selected them by default.
See what target framework works for you.