Develop Reference

Console App Platform always "Active(x86)"

If I go to project properties of a C# Console Application, its Platform is always set to Active(x86) where Platform target is x64, as shown in the img:
Can somebody tell what's the difference and how to create an app whose Platform is x64.

Microsoft made a couple of drastic design mistakes in VS2010, this is one of them. The Platform name for managed projects always used to be "AnyCPU". It is again in V2012 and up. But the default name in VS2010 is "x86".
That was a horrible choice, given that the Platform name is completely irrelevant to a managed project. Managed code runs on any platform, it is the Just-In-Time compiler that automatically converts the MSIL that the compiler generates to machine code. At runtime, not build time. So "AnyCPU" is a much more descriptive name, the jitter truly does make it run on "any cpu".
This momentary lapse of good thinking was induced by a significant change in the C++ project build model. VS2010 is the first version of Visual Studio where C and C++ projects are built with MSBuild instead of the custom build engine (VCBuild) used in previous versions. The Project selection is a Really Big deal for such projects, it selects the compiler that's used to compile the source code. Different cpus require different compilers because C++ code is directly translated into machine code.
So just ignore this, the name just doesn't matter. And above all, it has no effect at all on what the jitter does. Which requires a different setting if you want to force it to only generate 32-bit code. You found the setting that does that.

The platform refers to if you want to compile/build the project on x86 which is 32Bit architecture or x64 which is 64 Bit architecture. 64 bit app will run on 64 bit architecture, while 32 bit app can run on 64/32 Bit architecture,
regarding how to create an x64 app, you just choose x64 in your configuartion manager. refer to the following documnet for detailed explaination http://visualstudiohacks.com/articles/visual-studio-net-platform-target-explained/

Ok, Sorry in advance for the length of this answer but your question very neatly scratches on the surface of quite a lot of complexity.
Producing assemblies and native code
From the bottom up, Visual Studio/MSBuild do not produce the code that finally runs on machines that run your code. Instead they produce an assembly full of MSIL (MicroSoft Intermediary Language) which is translated at run time by CLR into native code for that machine. For assemblies that you use regularly the machine can also cache the native code in advance by using NGEN.
Every assembly can have a platform target. As Hans points out this doesn't actually do very much other than identify to the jitter what flavour your native code should be in. This indication is just a couple of bytes in the header of your assembly, and can actually be changed post-msbuild by using the corflags tool. Don't worry you don't need to ever use this. Normally during the build process, msbuild/VS will look at the platform target for each project and produce an assembly with the correct header.
Run time consumption of assemblies
Let's consider what happens when you now run your complied assembly. First, Windows identifies it as DotNet from its header and uses the CLR as a host environment for it. That environment will vary due to the version of DotNet, e.g. 2.0, 4.0, 4.5 etc and also for 32 or 64 bit. The environment will then start generating native runnable code from your MSIL assembly and start executing it.
Now all applications then call into other assemblies (at least System/mscorlib). The CLR will do its best to ensure that the correct version of these is loaded in. This can be from the their installed location (e.g. C:\Windows\Microsoft.Net\Framework...), the GAC (including NGEN versions), or from the applications current directory (see How the runtime locates assemblies). Sometimes this process will fail, because for example it can't find a required version of an assembly (i.e. can only find v1.0 when it needs v2.0) or it finds a 64bit when it needs a 32bit.
Producing applications
Back in Visual Studio there is something that most people miss. It's called configuration manager and its hidden on the bottom of the Solution Configurations dropdown in the Standard toolbar.
It basically provides us with a way to select the various flavours of attributes for all the assemblies we are building. For example here is a default Debug AnyCPU build.
At the top of the dialog there are two drops downs, the 2nd one lets you select the Active Platform.
But no-one knows about configuration manager
I assume the problem is most people don't know about this dialog and so instead if they want to create a 64bit build they will usually go into each project and change the AnyCPU build over to x64. In the past 10 yrs, I have never yet come across a code base that supports 64bit where somebody hasn't done this.
Also note, there is a special configuration that can appear called Mixed Platforms. It is supposed to handle a solution where you either have a native (e.g. C++) assembly as well as your DotNet, or when you are targetting multiple platforms such as Phone and Desktop. It can also get produced if you mix up your 32bit, 64but and AnyCPU etc.
Recommendations
Instead I recommend you do the following,
Go into configuration manager and remove all platform configurations that you aren't using. Ideally pare it back to just Debug and Release for AnyCPU. Use the Edit... on the drop downs then select and hit Remove.
Create a new Platform by selecting New... from the platform drop down. Copy it from AnyCPU.
Now for the fun bit, go through every project you have, and for each Platform ensure that it is building the correct Platform target.
And finally, Building
You can now build your codebase in one of three ways
Use the configuration manager to switch your active platform and press F5.
Use the Batch Build dialog (bottom of the Build Menu) to build the platforms you want to build.
Or use the devenv command line devenv.com myApp.sln /build "Debug|AnyCPU"

Why Required to chage X86 Platform in Visual Studio 2010

I am trying to use this article project in to my WindowsForm application.
I am using visual studio 2010.
You can download and run test application at above link.
My problem is when I use list of below DLLs in my project.
Interop.Office.dll
Interop.VBIDE.dll
Interop.Word.dll
I have to change project configuration settings.
Configuration Manager (open from Solution configuration combo box near Run button) => Platform => to x86.
Why we should have to change platform to x86?
If I change platform to x86? Will project run on 64bit machine?
Please help me..

It's because your C# program's memory model must match that of any unmanaged DLLs that you want to call. Because the Microsoft Office DLLs are 32-bits, so must your program be.
It will still run fine on a 64 bit machine, though!

You will change to x86 because you use platform depended dlls.
Yes, it will run as WOW64.

Application running only on pc with visual studio

I've a VS solution which contains two projects, one is c++ and other is GUI in c#. This c# project calls c++ project for calculations. When I'm running this on my machine its running fine in debug mode but when I'm trying to run it on machine without visual studio(debug build) its not able to get c++ dll, but if I build the solution in release mode and then try to run then it runs fine on both the machine. Can someone explain why is this happening ?

You are linking to the debug runtimes for the C++ project.
Either set it to release, or set the linker option to not use the debug runtime.

That is because Visual Studio ships with debug versions of the C runtime (msvcr100d for example) which are not present on machines without it.

Configure WPF client to run 64bit

We have some code that uses Entity Framework against a DB2 database.
When we try to use transaction scope, we get a message "The Under lying provider failed on Open".
We only get this error when to run from the WPF client.
We do not get this error when we run from a unit test.
The DB2 provider is 64bit
The difference that we have been able to find is that the unit test is configured as Any CPU, but the WPF project is configured as x86.
The problem is that the Visual Studion UI does not allow us to select anything other than x86 for the WPF project.
Is this a limitation of WPF projects? If not how do we configure a WPF project as Any CPU?

Perhaps you are confusing the Visual Studio C# Platform with the Platform target?
Each Visual Studio C# project can be built to one of several platforms. This allows you to use the same project to build to several hardware platforms like 32 and 64 bit Intel/AMD CPU or even a different CPU like Itanium.
However, when you create a new project it will by default only contain a single platform, and in your case you also want to build to only a single platform, i.e. x64. For new projects the platforms used by Visual Studio are these:
A library project (including a test project) will have the Any CPU platform.
An executable project (including a WPF project) will have the x86 platform.
What is slightly confusing is that these platforms are just names hinting at what is actually built. You control what is emitted by the compiler in the Build tab of the project settings. Here you can set the Platform target to values like Any CPU, x86 or x64.
You will have to set the Platform target to x64 in your WPF project.
To fully configure your platforms you will have to use the Configuration Manager which is on the menu Build -> Configuration Manager.

There is no such limitation. You can select target in Platform Target combobox on Build page of project properties

The only x86 I wasn't able to change was the Platform, which to be honest I have no Idea what it is. but as you can see I can select x64 as the Platform target, are you sure you don't have such option?

In the latest version of Visual Studio (at least 2019) in the project properties, in the build settings, there is an option for the platform target to prefer 32-bit.
You might want to uncheck it otherwise your app will run as x32 even on a x64 machine.

The solution to this problem is very simple.
We have copied copied 64 bit console PowerShell.exe to debug folder of the current VisualStudio Project and provided the same path (.\debug RR .\debug) to trigger the powershell script, and it works fine.

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