5

I'm using Windows 7 and x64 cpu. Does it mean that I should always compile with "x64" option in Visual Studio? What about "dll", can I use x86 dll from x64 application? Probably there are other concerns?

riQQ
  • 9,878
  • 7
  • 49
  • 66
Oleg Vazhnev
  • 23,239
  • 54
  • 171
  • 305

4 Answers4

7

This article contains a brief overview of each option.

Here's a small quote:

The default setting, Any CPU, means that the assembly will run natively on the CPU is it currently running on. Meaning, it will run as 64-bit on a 64-bit machine and 32-bit on a 32-bit machine. If the assembly is called from a 64-bit application, it will perform as a 64-bit assembly and so on.

If the project is set to x86, this means the project is intended to run only as a 32-bit process. A 64-bit process will be unable to call into an assembly set as X86. Reasons to set your project as x86 include dependencies upon native DLLs that are only available in 32-bit or making native calls assuming 32-bit . Applications and assemblies marked for x86 can still run on 64-bit Windows. However they run under WOW64. Visual Studio itself runs under this emulation mode since it is a 32-bit application.

Setting the project to x64 will specify that the assembly must run under 64-bit Windows. Attempting to run the assembly on 32-bit Windows or call the assembly from a 32-bit process will result in a runtime error.

James Hill
  • 60,353
  • 20
  • 145
  • 161
  • How can one determine if DLLs are only available in 32-bit? Also, how can one tell if the program is making native calls assuming 32-bit? – Dan W Jul 10 '13 at 10:41
  • @DanW, I suggest posting a question. Asking a question like that in the comments won't get you very far. – James Hill Jul 10 '13 at 11:14
  • Just more convenient to have it here if others also come across this issue. Anyway, I think [this](http://stackoverflow.com/a/2418287/848344) will do the trick. – Dan W Jul 10 '13 at 11:34
5

Generally speaking, you should use AnyCpu all the time.

If you have specific reasons to expect compatibility problems with that, then you'll need to choose x86 or x64 as appropriate.

As noted in the comments, dll's built against specific architectures can require you to build your assembly a certain way. This will be something you'll want to do when you need to, not otherwise.

Andrew Barber
  • 39,603
  • 20
  • 94
  • 123
  • when I'm using AnyCpu application crash by some reason. x86 option works... probably this is because of used dll.. – Oleg Vazhnev Feb 09 '12 at 20:36
  • 1
    Yes, some `OleDb` and `ODBC` drivers, for instance, work only in x86 mode. – Olivier Jacot-Descombes Feb 09 '12 at 20:37
  • @javapowered Yes if your DLL is specifically x86 or x64 use the corresponding. For Example I was using an Oracle DB Access DLL that was x86 and I am required to then compile in the x86. – Brad Semrad Feb 09 '12 at 20:38
  • Agreed...seen architecture limitations with [Jet OLEDB](http://stackoverflow.com/questions/6954803/alternative-to-microsoft-jet-oledb-4-0-for-64-bit-access-on-mdb-file) – SliverNinja - MSFT Feb 09 '12 at 20:39
2

No... the machine you write your code on/compile/build your software (EXE, DLL...) does not have anything to do with the question which target (x86 / x64 / Any).

IF you want the result of the build to run anywhere you use either x86 or AnyCPU. If you want the result to run on x64 only then you use x64.

There are some cases where you must use x86 or x64 - that is when you use some (3rd-party?) component/library/DLL/ActiveX etc. in your project which is 32 Bit only (then x86) or only 64 Bit only (then x64).

Yahia
  • 69,653
  • 9
  • 115
  • 144
1

AnyCPU is what I generally recommend. You can see this issue discussed in depth at this SO post.

The only concern is that you cannot go backwards - you can't use an x64 assembly from a x86 application. AnyCPU alleviates this potential pitfall.

Community
  • 1
  • 1
SliverNinja - MSFT
  • 31,051
  • 11
  • 110
  • 173