CODEWITHSUNDEEP
c#c++visual-studio-2012windows-7-x64
Abhishek
Abhishek

Reputation: 2945

Changing from 32 bit to 64 bit

My solution in Visual Studio 2012 has three projects. A WinForms project and two VC++ projects (Libraries). Initially all the development was done on a Windows 7 Professional 32 Bit. But recently, my system was updated to Windows 7 Professional 64 Bit.

My application builds and runs successfully with Active Solution Platform set to AnyCPU. But when the application launches and I perform some action which makes a call to the underlying VC++ Library, the application crashes with a FileNotFoundException for the dll.

So should I change the Active Solution Platform to x64? Or is it fine to leave it as it is.

I have tried to change the Active Solution Platform to x64. But the dll doesnot build. I get a error LNK2019: unresolved external symbol

I have never used a 64-bit before. What should I do to make my application build?

The symbols that are not being found are present in the third VC++ project which is a static library.

The WinForms depends on the dll and the dll depends on the static lib.

Update:

When the Build Configuration is set to AnyCPU, I get a System.BadImageFormatException. Under additional information, it says could not load file or assembly dll_name,..... Attempt was made to load a program with an incorrect format.

Upvotes: 0

Views: 12681

Answers (1)

Harry Johnston
Harry Johnston

Reputation: 36318

The AnyCPU platform choice builds CPU-independent .NET code. This means it will run as x86 code on 32-bit Windows but as x64 code on 64-bit Windows.

Visual C++ doesn't have any equivalent to AnyCPU. Those projects must either be 32-bit or 64-bit. Presumably, your solution is configured to build them as 32-bit DLLs when AnyCPU is selected. This means that on a 64-bit machine, the .NET code will be running as 64-bit but the DLLs will still be 32-bit, and since a 64-bit process can't load a 32-bit DLL, it won't work.

You can fix this either by setting the Active Solution Platform to x64 or by setting it to x86. Unless you have a specific reason why you want the code to run as x64 (e.g., it requires the larger address space, or it does not perform well on a 32-bit platform) it is usually simpler to choose x86, because that will work on both 32-bit and 64-bit Windows, and does not require any modification to existing code originally developed for 32-bit Windows.

It is also possible to build both 32-bit and 64-bit DLLs within a single solution, and have the .NET code load whichever is appropriate at runtime. However, this is more complicated.

Upvotes: 2

Related Questions