2

If I have a 32-bit application written in C#, what do I need to do to convert it 64-bit? I'm assuming its more complicated then simply changing the target machine to 64-bit in Visual Studio and recompiling.

Icemanind
  • 47,519
  • 50
  • 171
  • 296
  • The problem I'm running into is, my program uses an MS Access database and it doesn't seem to run in 64-bit mode. From what I understand from googling and such, Microsoft does not have a 64-bit version of their JET database drivers. Is there anyway around this? Perhaps making some kind of 64-bit wrapper that calls the 32-bit drivers or something? – Icemanind Oct 19 '09 at 18:54
  • 4
    Why would you care about running in a 64bit process if you're messing with an Access database? You don't need a GeForce to run Commander Keen, ffs. –  Oct 19 '09 at 18:58
  • 2
    Stop replicating the same comment on all the answers you get. You comment once, we can all see it, I promise. – dreadwail Oct 19 '09 at 19:12

7 Answers7

6

If you don’t use interop (COM, WinAPI) and don’t make assumptions about the size of pointers it’s a straightforward switch to the other platform. Even when using the latter you are probably fine, unless you use libraries that somewhere make above mentioned assumptions.

To quote the MSDN concerning System.IntPtr:

The IntPtr type is designed to be an integer whose size is platform-specific. That is, an instance of this type is expected to be 32-bits on 32-bit hardware and operating systems, and 64-bits on 64-bit hardware and operating systems.

– But the other .NET types are designed to have a fixed size, regardless of the platform.

Konrad Rudolph
  • 530,221
  • 131
  • 937
  • 1,214
  • The problem I'm running into is, my program uses an MS Access database and it doesn't seem to run in 64-bit mode. From what I understand from googling and such, Microsoft does not have a 64-bit version of their JET database drivers. Is there anyway around this? Perhaps making some kind of 64-bit wrapper that calls the 32-bit drivers or something? – Icemanind Oct 19 '09 at 18:53
4

Do you actually need it to be running in 64 bit or do you just want it to run on a 64 bit machine?

In the case of the latter you can set the C# project to target Win32, rather than AnyCPU. This means when you run it on a 64 bit machine it will run through WOW (32 bit "emulation") this has the advantage that the (unmanaged) JET driver will also run 32 bit. This should solve your problem.

Ade Miller
  • 13,575
  • 1
  • 42
  • 75
2

It depends what your application is doing. If it uses unmanaged APIs, P/Invoke and pointer arithmetics, it is quite possible that it won't work on a 64-bit platform without some modifications. Otherwise you it be OK, you don't even need to specify a platform, just target for Any CPU and it should work.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • The problem I'm running into is, my program uses an MS Access database and it doesn't seem to run in 64-bit mode. From what I understand from googling and such, Microsoft does not have a 64-bit version of their JET database drivers. Is there anyway around this? Perhaps making some kind of 64-bit wrapper that calls the 32-bit drivers or something? – Icemanind Oct 19 '09 at 18:53
2

On of my coworkers just ran into a problem with one of his personal projects. It turns out that Microsoft hasn't written Jet drivers for 64-bit and has no intention of doing so.

Which is odd, since Office 2010 will have a 64-bit version.

My advice to you is to set the projects properties to x86 (not Any CPU) and leave it there. Windows 64-bit can run 32-bit applications without problems, it's 16-bit applications they can't run.

Powerlord
  • 87,612
  • 17
  • 125
  • 175
1

How about doing as this question suggests? I've never done this before, I'll note.

Community
  • 1
  • 1
peacedog
  • 1,415
  • 20
  • 32
0

http://msdn.microsoft.com/en-us/library/ms241064.aspx

The other comments are good points. You also need to understand the changes with registry virtualization and the Wow64 node.

Adam Driscoll
  • 9,395
  • 9
  • 61
  • 104
  • Note that the keys affected in Windows Vista/Server 2008 are different than those affected in Windows 7/Server 2008 R2. See http://msdn.microsoft.com/en-us/library/aa384253(VS.85).aspx#redirected__shared__and_reflected_keys_under_wow64 – Powerlord Oct 19 '09 at 19:10
0

I'm assuming its more complicated then simply changing the target machine to 64-bit in Visual Studio and recompiling.

Maybe not. If you don't have any dependencies on outside libraries, that's all you have to do. What makes it more challenging beyond that is the deployment. You don't want to send a 64-bit binary to a 32-bit user. So, even better, choose the "Any CPU" option, and your app will automatically JIT compile as 64-bit on a 64-bit machine (with the 64-bit version of the framework installed) and 32-bit (x86) everywhere else.

But you have to be very sure you don't have any 32-bit dependencies.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794