Develop Reference

Visual Studio 2019 builds 32bit executable when configuration is 64bit

I am attempting to build an executable from a C# project in Visual Studio 2019. The project configuration is Debug - x64 and the target platform is set to x64 as well. I have double checked the settings in the Build Settings, the Configuration Manager
and in the .csproj file itself.
I have also checked that I am on a x64 machine (Windows 10 x64).
When starting the build, Visual Studio says
Build started: Project: MyProject, Configuration: Debug x64.
However, the executable created is 32 bit. I have checked the file and when attempting to debug, the debugger also shows a Win32 executable.
I have tried to clean the project multiple times, restarted Visual Studio and the computer, nothing changes. Another project that is contained in the same project map as the C# project, which is a C++ project that is used to build a .dll does build with x64. So I am assuming it is a problem specific to the one project. Is there some internal caching stuff going on that might cause this?
EDIT:
According to this https://superuser.com/questions/358434/how-to-check-if-a-binary-is-32-or-64-bit-on-windows, I am checking by opening my .exe file with notepad which shows me PE L = 32 bit.
Also, when running the executable from VS with the Start button an Debug - x64 configuration, this is the output:
'ProjMapping.exe' (Win32): Loaded 'D:\[...]\ProjMapping\bin\Debug\ProjMapping.exe'.
The project I am attempting to create a x64 executable from is ProjMapping
When I am clicking on Build, Rebuild or Start (on the top) I am getting the 32 bit executable created in the output directory.

Could not load file or assembly 'myApp.Web' or one of its dependencies. An attempt was made to load a program with an incorrect format

I have web application which works fine when I have configuration in Visual studio:
"Active solution configuration. Debug, platform x86."
When I publish application with release configuration(Any CPU), I get the following error on publish server:
Could not load file or assembly 'myApp.Web' or one of its dependencies. An attempt was made to load a program with an incorrect format.
If I change in visual studio to:
Active solution configuration, Release, platform x86.
and rebuild my application, I get the same error also on my computer.
If I change back to debug and rebuild, it works again.
I'm using Local IIS .
What could be wrong, I have tried every suggestion I have found but with no success?

Was having same problem. This problem comes out when you are using assemblies built for x86 or x64 explicitly. Make sure that all projects, especially if you are using native code somethere in satelite assemblies are set to be built for same platform in configuration manager.
update
It smells like your server and your build machine has different bitness. If you have same bitness set for debug and release and one is working while other is not it might be because of some settings miss in assembly publish process (release does not copy something or copies something wrong)

DLL load error in debug mode ,but release mode is ok

When I use the VS2008 to build my project, I use my own DLL. It works all right in release mode, but when I change it to debug mode, I get an error:
An unhandled exception of type 'System.DllNotFoundException' occurred in DDKWidget.exe
Additional information: Unable to load the DLL "DDKLibA.dll": The specified module could not be found.
The DDKWidget and DDKLibA.dll is my project excutable file and my self-created DLL.
I created my DLL in C++,but I use my it in my C# project, using [DllImport("DDKLibA.dll")].
My OS is Win7 64 bit.
My IDE is VS2008 SP1.
Did anyone encounter this before?
BTW, it was all ok some time ago, but recently, since I re-installed my OS, I started getting these errors. Can any one help me?

This sounds like a problem with 64-bit vs 32-bit mismatch. CLR applications by default get compiled for "AnyCPU" which means that they would automatically run as 64-bit processes on a 64-bit OS.
On the other hand, C++ dlls have to be compiled either for 32-bit or 64-bit and once compiled they stay that way.
You can force a C# app to run in 32-bit mode even under 64-bit OS but that setting can be changed independently for Debug and Release configurations.
My guess would be that your C++ dll is compiled as 32-bit and your Debug setting for your C# dll is also 32-bit but in the Release mode it is set to AnyCPU. That way it would runs as 64-bit process and will not be able to load the 32-bit C++ dll.

where in the filesystem is the dll located? Maybe you copied it to the same directory as your release exe, but forgot to do the same for the debug exe?

The only time I've seen this occur is when a dependent DLL is missing. For example, the release version of your assembly is dependent on foo.dll, but the debug version is dependent on foo-debug.dll. If foo-debug.dll is not installed on the target system, the debug version of your assembly can't be loaded.
I suggest you use a file monitoring utility such as FileMon to see which files the OS is attempting to load when your DLL is loaded.

BadImageFormatException when loading 32 bit DLL, target is x86

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

Could not load file or assembly 'xxx' or one of its dependencies. An attempt was made to load a program with an incorrect format

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.