Could not load file or assembly ... An attempt was made to load a program with an incorrect format (System.BadImageFormatException)

Question

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?

If you have a version history in the repository, could you check if there are some differences in the csproj files? — Steve, Jul 06 '12 at 22:22
@Steve: According to Mercurial, no changes other than adding references to new .cs files — BlueRaja - Danny Pflughoeft, Jul 06 '12 at 22:23
Do you get the same behaviour on another machine? Did anything else change on the machine (e.g. Windows update, dependency updates, etc.)? — Mike Parkhill, Jul 07 '12 at 00:44
This worked for me............ http://stackoverflow.com/a/9419522/191403 — Som, Mar 28 '13 at 14:49
As a sanity check, in the Solution Explorer click `Refresh`. This let me save and rebuild the solution. — ShooShoSha, Sep 06 '16 at 17:47
**Related post** - [Could not load file or assembly 'xxx' or one of its dependencies. An attempt was made to load a program with an incorrect format](https://stackoverflow.com/q/1648213/465053) **&** [Could not load file or assembly exception](https://stackoverflow.com/q/9419403/465053) — RBT, Apr 17 '18 at 06:22
Same problem. Looked everywhere for an answer. Had to step back and remove the problematic application then convert a previously backed up version as the original application. Thanks goodness I made it a habit to back up. — Vkl125, May 12 '20 at 06:59

score 813 · Accepted Answer · edited Mar 01 '23 at 16:40

813

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.

The APP is set to run on 64-bit but the DLL is running on 32 bit to mitigate this navigate to IIS >> Application pool >> Advanced settings >> Enable 32 bit applications then set to true.

edited Mar 01 '23 at 16:40

Paul Muia

11
3

answered Jul 07 '12 at 01:47

Icemanind

47,519
50
171
296

86

Do'h. I somehow completely missing "platform target" dropdown in `project-->properties-->build` - it was set for x86; setting it to "Any CPU" fixed this issue. I always thought that this setting was the same as the "platform target" dropdown in the configuration manager, but apparently it's not *(in fact, the "platform target" in configuration manager doesn't appear to do anything at all!)* – BlueRaja - Danny Pflughoeft Aug 03 '12 at 22:07
12

Also verify that the project isn't Any CPU with Prefer 32 bit checked. Project -> properties -> build – Reid Evans Nov 18 '13 at 18:34
35

PS: Another reason is "Enable 32-bit applications" being "false" in app pool settings. You need to restart IIS after setting it to true. – dvdmn Jun 25 '14 at 13:28
4

The worst that happened to me with this error was when VS decided to append `x86` in one of the dependent projects for no reason at all. If I haven't looked into SVN I would have never figured out why our MVC app fails to launch. – jahu Jul 22 '15 at 09:52
Just updated VS2015, version 14.0.25123.00 Update 2. This update was just released 5/10/16 (yesterday!). I found the Platform Target set to x64, which caused the error noted. Setting to "Any CPU" fixed it. – Michael D. O'Connor May 11 '16 at 04:54
3

Please set in IIS DefaultAppPool-> Enable 32-Bit Applications = True – Shantu Oct 12 '17 at 13:25
If you have a Console as your front end, make sure the "Prefer 32-bit" flag is unchecked. – Bertie May 07 '21 at 14:24
For me, i think while I was making modifications to my XML documentation target on that project ->build settings i must have scrolled the platform target to AMD64. Cost me another hour – Olaoluwa Jan 23 '22 at 18:43
It work for me, only uncheck prefer 32-bit and change platform target to x64. Thank you – Anton Nikolayevich Feb 11 '22 at 07:27
upvote upvote upvote – Bondolin Jun 07 '23 at 14:33

score 245 · Answer 2 · edited Oct 09 '19 at 17:08

245

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

edited Oct 09 '19 at 17:08

KyleMit

30,350
66
462
664

answered Dec 11 '13 at 17:00

Ali Adravi

21,707
9
87
85

2

Did I miss something? OP is talking about a _console app_ not IIS deployment: _"ProjectB is a console application, which depends on ProjectA"_ – Feb 03 '16 at 11:19
In my case, it was set to true and worked after setting it to false. Same error message. – planetregin Sep 20 '21 at 12:27

score 189 · Answer 3 · edited Nov 28 '19 at 05:27

189

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:

edited Nov 28 '19 at 05:27

Uwe Keim

39,551
56
175
291

answered Jun 06 '16 at 20:09

TTT

22,611
8
63
69

4

The opposite applies to, I had the 'Use 64 bit' ticked and needed to untick it... – cjb110 Mar 14 '17 at 08:21
1

Yup, I switched my web app to 64 bit to ensure I had the memory overhead, and then I needed to tick this option to get it to load after that. Thanks! – John Oct 23 '20 at 20:21
One word, Beauty!! – Jamshaid K. Sep 13 '21 at 10:09
That was it for me, it's easy to forget about this setting, once you're jumping into a fresh environment, it really feels like it should be either on by default or bound to the project target platform. Also easy to forget that if you're not using full IIS there is actually something to configure out there. – mikus Oct 12 '21 at 14:14

score 39 · Answer 4 · answered Apr 18 '13 at 16:23

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.

score 23 · Answer 5 · answered Jan 30 '17 at 22:01

23

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

answered Jan 30 '17 at 22:01

mkaj

3,421
1
31
23

1

Works like a charm for VS 2019 as well :) – el_nektarin Feb 05 '21 at 14:08

score 10 · Answer 6 · answered Dec 06 '13 at 16:31

10

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.

answered Dec 06 '13 at 16:31

fergal303

359
2
6

OP is talking about a console app not IIS – Feb 03 '16 at 11:20

score 10 · Answer 7 · answered Mar 02 '18 at 06:18

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)

score 6 · Answer 8 · answered Jan 02 '20 at 11:37

6

The following solved the issue for me, uncheck 'Prefer 32-bit' :

answered Jan 02 '20 at 11:37

Boomerang

782
2
11
20

score 5 · Answer 9 · answered Jun 01 '21 at 17:57

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.

score 5 · Answer 10 · answered Dec 07 '22 at 15:22

5

In my case changing IIS Express Bitness from "Default" to "x86" helped.

All my projects had "x86" as the Platform target.

answered Dec 07 '22 at 15:22

Alexander Puchkov

5,913
4
34
48

score 4 · Answer 11 · answered Aug 07 '13 at 01:24

4

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.

answered Aug 07 '13 at 01:24

Flood Techs

167
2

1

Worked in Release but failed in Debug. Set all to .Net Framework 4 (NOT Update 1) and Debug runs now. – DCastenholz Jan 20 '16 at 02:43

score 4 · Answer 12 · answered Jun 29 '17 at 04:55

4

None of these solutions worked for me - but by deleting the contents of bin and obj folders everything was cool again.

answered Jun 29 '17 at 04:55

saille

9,014
5
45
57

score 4 · Answer 13 · answered Nov 09 '21 at 10:22

4

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.

answered Nov 09 '21 at 10:22

JayPi

432
5
8

score 3 · Answer 14 · answered Sep 15 '17 at 10:50

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

score 3 · Answer 15 · answered Dec 11 '17 at 10:43

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

score 2 · Answer 16 · answered Oct 14 '15 at 16:31

2

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

answered Oct 14 '15 at 16:31

G88

21
2

1

Consider summarizing the linked article for benefit of future readers; in case the link goes dead. – Bond - Java Bond Oct 14 '15 at 16:42

score 2 · Answer 17 · answered Jan 03 '17 at 01:58

2

In my project for C#, project property->[Build]->Platform target: Any CPU, and uncheck the Prefer 32-bit to let compiler to choose automatically.

answered Jan 03 '17 at 01:58

bruce

1,286
11
14

score 1 · Answer 18 · answered Nov 08 '13 at 15:41

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.

score 1 · Answer 19 · answered Sep 11 '15 at 10:12

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.

score 1 · Answer 20 · answered Aug 30 '16 at 10:18

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"/>

score 1 · Answer 21 · answered Jan 31 '18 at 05:32

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

score 1 · Answer 22 · answered Mar 18 '19 at 03:37

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.

score 0 · Answer 23 · answered Oct 21 '15 at 18:55

0

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

answered Oct 21 '15 at 18:55

Hovhannes Babayan

378
4
12

score 0 · Answer 24 · answered Apr 17 '18 at 08:55

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'

score 0 · Answer 25 · answered Oct 31 '18 at 16:22

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.

score 0 · Answer 26 · answered Jan 30 '20 at 08:27

0

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.

answered Jan 30 '20 at 08:27

Acubo

120
6

score 0 · Answer 27 · answered Mar 24 '20 at 10:08

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.

score 0 · Answer 28 · answered Apr 08 '22 at 00:15

0

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!

answered Apr 08 '22 at 00:15

yoel halb

12,188
3
57
52

score -1 · Answer 29 · answered Mar 27 '18 at 07:29

-1

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.

answered Mar 27 '18 at 07:29

Tadej

553
7
16

score -1 · Answer 30 · answered Jul 28 '20 at 03:21

-1

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.

answered Jul 28 '20 at 03:21

jcs

611
2
9
22

score -2 · Answer 31 · answered Jan 31 '17 at 19:45

-2

My machine showed me a BIOS update and I wondered if that has something to do with the sudden popping-up of this error. And after I did the update, the error was resolved and the solution built fine.

answered Jan 31 '17 at 19:45

radkan

599
4
9

Could not load file or assembly ... An attempt was made to load a program with an incorrect format (System.BadImageFormatException)

31 Answers31

Steps

Linked

Related