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'm getting a weird compilation error and I'm just utterly baffled by it.
When I compile my project, I get this:
The type 'SpatialReference' is defined in an assembly that is not
referenced. You must add a reference to assembly 'Esri.ArcGISRuntime,
Version=10.2.7.0, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86'.
That's not the weird part though. I only get this when I have "Optimize Code" unchecked in the C# project settings for the application.
When I check the "Optimize Code" checkbox, it compiles just fine, and the application runs as expected.
The type 'SpatialReference' is not being used in the application at all, and that particular type is wrapped up in another assembly referenced by the application, and as far as I can see the type is not leaking out from the wrapper code.
Other applications that use this same wrapper assembly will compile with no issues, regardless of the Optimize Code state, and the wrapper assembly has been in use for almost 5 years without issue.
Has anyone else ran into this problem? If so, how'd you fix it?
Just for reference, these applications are WinForms applications. And I'm using Visual Studio 2019 Enterprise, v16.8.1
Update 2020-11-22
After uninstalling 16.8 from our build machine (which was affected by this) and putting 16.7.7 back on, it compiles just fine. This is starting to look like a problem with v16.8.x.
I should note the following:
The projects are windows forms applications running under .NET 4.7.2
My personal work machine with 16.8 fails to build, the build machine for our CI with 16.8 fails, but my coworker's machine with 16.7.7 works.
This only affects 1 project out of 10 projects, all of which use the same wrapper API and the same functionality, and no changes have been made to the wrapper in ages. Why it fails with just one and not the others is unknown.
I've been through the csproj file (using a text editor) for the failing project with a fine tooth comb and I have not seen anything out of the ordinary.
Please firstly try to clear the NuGet cache and then reinstall NuGet packages, if you installed some NuGet packages for example Esri.ArcGISRuntime.
For clearing NuGet cache, please go to Tools > Options > NuGet Package Manager > General > Package Restore > select “Allow NuGet to download missing packages” and “Automatically check for missing packages during build in Visual Studio” > then click Clear All NuGet Cache(s) button.
For reinstalling NuGet packages, please go to Tools > NuGet Package Manager > Package Manager Console > in Package Manager Console enter Update-Package -reinstall to reinstall the NuGet packages.
After that, please restart VS and rebuild your project, check if this issue disappears. If this issue still persists, please try following steps to troubleshoot:
1). Please close every VS instances and go to your solution folder, then rename(or delete) the hidden .vs, bin and obj folders, after that launch VS and rebuild your solution.
2). Please go to this path: C:\Users\Administrator\AppData\Local\Microsoft\VisualStudio\16.0_XXXXand rename(or delete) every folders named “ComponentModelCache”.
3). Please disable any third-party extensions temporarily from Extensions > Manage Extensions > Installed > Disable and test again.
4). Please kindly try to repair Visual Studio 2019 from Visual Studio Installer > VS 2019 > More > Repair.
I am getting the error: "Could not find SDK "Microsoft.VCLibs, Version=14.0" whenever I attempt to build the default "Blank App (Universal Windows)" app.
I know I have compiled UWP apps before, and is potentially a consequence of recently trying the VS2019 preview (now removed)
I've tried uninstalling/reinstalling VS2019, VS2017, even installed 2015 and the blank UWP apps in each all come up with the same error.
I've tried uninstalling/reinstalling/repairing Windows 10 SDK's.
I've tried various versions of the Microsoft.NETCore.UniversalWindowsPlatform to no avail. (The default is v6.2.10).
Can anyone explain how I can logically chase this error? I'm assuming that it is failing to build the UniversalWindowsPlatform nuget - is this correct? What is supposed to be installing the vclibs extension? How can I see what is preventing it from being installed?
No amount of repairing/installing VS2019, VS2017 or even VS2015, adding or removing options, (re)installing SDKs, (re)installing Visual C++ Runtime libraries made any difference.
what did eventually work was installing VS2019 on a new PC and then copying its entire "C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs directory across.
If installing VS2019 installs this directory, I'm not sure why it doesn't fix it as part of reinstalling and/or repairing it!! An opportunity for improvement in VS2019 repair perhaps?
Big thankyou to #NicoZhu-MSFT for all of your help!!
Getting the following error 'The target "MainResourceGeneration" does not exist in the project' on Any project I try to build with Visual Studio. Cannot run debugger, cannot build/rebuild solution or projects.
Backing up a bit:
I had VS2012 and VS2017 (always used 2017) installed.
Got an error that pointed me to the Microsoft.Common.CurrentVersion.targets file. I mistakenly edited this file thinking it was part of my project.
Started getting the aforementioned build error on all my projects. Including simple, brand new, unaltered C# .NET framework console app.
Also had the same error on VS2012...
Tried VS2017 repair.
Tried VS2017 uninstall/reinstall.
Tried uninstall VS2017/2012, manually delete visual studio program files folders, reinstall 2017.
Still have the problem. Brand new fresh VS2017 install and not even a new console app will build.
Build output just shows this...
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2789,7): error MSB4057: The target "MainResourcesGeneration" does not exist in the project.
Visual Studio Build Error: The target “MainResourceGeneration” does not exist in the project
Since this issue still occurs on a new console app, it seems that the Visual Studio installation file is corrupted. You can try to following steps to clean up the Visual Studio and reinstall it:
See if you have this file on your machine:
"%programfiles(x86)%\Microsoft Visual
Studio\Installer\resources\app\layout\InstallCleanup.exe"
Start an admin command prompt
Right-click on cmd.exe and select Run AsAdministrator
If so, please launch it from an admin command prompt with a -full
param
InstallCleanup.exe -full
If not, please manually delete the "%programfiles(x86)%\Microsoft
Visual Studio\Installer” folder
Verify that your initial install location for VS is removed. If it
is not, delete it manually.
Relaunch the newly downloaded vs_enterprise.exe (or
vs_professional.exe or vs_community.exe…)
Allow the first step to install the installer Once the installer
comes up and you can see workload choices (.net desktop and the
like), close it
Go launch the same InstallCleanup.exe to clean up old build of VS
Then relaunch vs_enterprise.exe and install VS
Please let me know if it works for you.
I tried several further steps like manually deleting Visual Studio related folders in my Users and ProgramData directories, and repairing .NET framework. None of those changes worked. Still had the same issue.
As a last resort I fully uninstalled .NET Framework (4.7.1) and grabbed the latest version (4.7.2) from https://www.microsoft.com/net/download/dotnet-framework-runtime. I no longer received the error and could then build my projects again.
I do not know or understand the root cause, but a full uninstall/reinstall of .NET framework fixed it...
I tried building a C# project in Visual Studio (VS) Code in Ubuntu Linux, but the default build (F5 Debug) always runs the command "dotnet build". This in turn does not work because within my csproj file (Project.csproj), I'm using the following setting:
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
This in turn tries to build every csproj file in the directory (which I only want to build one) and it also fails to build each one on .NETFramework v4.5, producing the following error:
/usr/share/dotnet/sdk/2.0.2/Microsoft.Common.CurrentVersion.targets(1122,5): error MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.5" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of referenceassemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
I've found a workaround by downloading and installing Mono, then NuGet, then using this command from Mono in the VS Code TERMINAL window:
jbrumbaugh#jbrumbaugh-VirtualBox:~/Dropbox/.../Project$ msbuild Project.csproj
This command successfully creates a working EXE within the bin/debug folder.
My problem is I cannot actually use the VS Code debugger to hit breakpoints and step through code. Is there a way I can modify the settings within VS Code or some csproj file to successfully reroute the .NET framework to that used by Mono, or substitute the default debug build command with one that I specify?
You can configure what the F5 command does in a few different ways.
The easiest way is to modify the pre-launch task. This is found in the file "${workspaceFolder}/.vscode/tasks.json. By default, the F5 command runs the task labeled build, which by default is set to run dotnet build. You can customize the task by editing the command and args fields. See https://code.visualstudio.com/docs/editor/tasks for more info.
Another thing you could do is remap what F5 does. By default it runs the workbench.action.debug.start command. You can remap this by going to the menu File > Preferences > Keyboard Shortcuts. See https://code.visualstudio.com/docs/getstarted/keybindings for more info.