We have been doing 32 bit builds while testing on 64 bit machines. In order to utilize the power of machines for our application, we are planning to make 64 bit builds for our C#/.NET 4.0 code base. We have never done it in the past and haven't tested it yet and although it looks pretty simple we would like to understand the following: What necessary steps do we need to take during this migration process? What issues if any can we expect during this migration? Frankly I'm unsure of any hiccups we may face? Stuff like our code referring underlying DLLs whose 32 bit versions have been referenced? Do we need to update all references? Again, we don't have much insight here so this specific question may be irrelevant. But we would like to find out about any issues that may hamper a smooth transitioning. We had all the functional testing on 32 bit. We may not have too much time to perform rigorous testing on 64 bit? Is it a safe ploy to rely on our 32 bit functional testing?

In simple cases, moving C# code from 32-bit to 64-bit is just a matter of changing the build settings. Safe C# code executes on 64-bit architectures the same way as it does on 32-bit. In practice, you can run into several issues. Here are some to look out for: Does your C# code contain unsafe code? Unsafe code can manipulate pointers, and so it may be written in a way that assumes 32-bit pointers. To find out whether your projects contain unsafe code, you can search your codebase for the "unsafe" keyword. Are you using P/Invoke? If you are using P/Invoke to call into native code, the CLR runtime will now be looking for a 64-bit DLL rather than a 32-bit one. If a 64-bit DLL is not found at runtime, you'll get an exception ("BadImageFormatException" or something like that) You can search your codebase for "DllImport" to see whether you are using P/Invoke. Do your projects contain brittle code? After you move your projects to 64-bit, you'll be using a different version of the Just-in-Time (JIT) compiler. The X64 JIT compiler performs some more aggressive optimizations compared to the X86 JIT. As a result, some incorrectly written (typically multi-threaded) code that happened to work in X86 may end up breaking on X64. Are you using certain features like marshaling, serialization and COM interop? Usages of all these features may need to be modified in the 64-bit build. Some of the keywords to search in your code include "Marshal", "StructLayout", "FieldOffset", "BinaryFormatter" and "Com". Also check out this white paper that further discusses migrating 32-bit managed code to 64-bit: http://msdn.microsoft.com/en-us/library/ms973190.aspx

c#64-bit

Aziz

Reputation: 534

Migrating From 32 to 64 bit Releases

We have been doing 32 bit builds while testing on 64 bit machines. In order to utilize the power of machines for our application, we are planning to make 64 bit builds for our C#/.NET 4.0 code base. We have never done it in the past and haven't tested it yet and although it looks pretty simple we would like to understand the following:

What necessary steps do we need to take during this migration process?
What issues if any can we expect during this migration? Frankly I'm unsure of any hiccups we may face? Stuff like our code referring underlying DLLs whose 32 bit versions have been referenced? Do we need to update all references? Again, we don't have much insight here so this specific question may be irrelevant. But we would like to find out about any issues that may hamper a smooth transitioning.
We had all the functional testing on 32 bit. We may not have too much time to perform rigorous testing on 64 bit? Is it a safe ploy to rely on our 32 bit functional testing?

Upvotes: 3

Answers (4)

Aendie

Reputation: 343

No, it is not a safe ploy to rely on 32-bit functional testing! Your question is good and relevant. I was surprised to find significant differences in functional behaviour in my 32-bit application that worked correctly. For more details, see What causes significant loss of FP precision when compiling for 64-bit? (Note: the negative rating is due to incorrect formatting, which I have changed)

Upvotes: 0

Ciaran Keating

Reputation: 2783

Yes, you'll need to make sure you have 64-bit versions of all DLLs that you reference. And no, it is absolutely not safe to rely on your 32-bit testing! (You knew that already, right?)

We ported our system to 64-bit a few years ago and were surprised by a few things:

in general the port was far easier than we had expected
the most difficult problems arose in the strangest of places, places we had supposed would be straightforward
subsequent builds have been trouble-free

Some examples of the unexpected and tricky problems...

Our system includes a Visual Studio project wizard. Visual Studio is 32-bit only, but our customers might still want to target 64-bit machines. So our x86 installer had to include our x64 assemblies. Normally that's OK - the installer spots that we're including x64 files in an x86 project, issues a warning, but continues. But one of these assemblies contains mixed managed/unmanaged code, and our installer couldn't handle that. (We were using the Visual Studio installer at the time, but we've grown up since then.) So we wrote a tool that hex-encodes the 64-bit DLL and writes it to a text file, include that file in the installer project, then have a custom installer step that reverses the encoding and restores the DLL.

Our project wizard relies on some COM DLLs, which must be registered in the 32-bit registry because Visual Studio is 32-bit. But on x64 our installer runs as 64-bit and so invokes the 64-bit regsvr32.exe, which registers the DLLs in the wrong place. So we wrote a 64-bit tool that registers the DLLs in the 32-bit registry.

It happens that our wizard needs to know where our product is installed. So our installer writes that info to the registry. But on x64 the installer runs as 64-bits and writes that info to the 64-bit registry, but our wizard runs in Visual Studio in 32-bits and so it can't read that part of the registry. So once again we had to write a special tool to let the installer write the info to both sides of the registry.

These issues may not sound so bad. After all, the solutions are quite tidy and very small. But consider this: Our system is mixed managed/unmanaged COM/C++ and C#, with third-party libraries such as Boost, Apache HTTPd and OpenSSL, all of which had to be recompiled. I had expected this to be the hard part, but it took only two days to port the relevant bits of code and get the project to compile. Then it took another whole week to understand and fix the problems I've described above. Having said that, I was still very pleasantly surprised that the entire port took only a week and a half.

A parting thought... You say you want to take advantage of the power of your 64-bit machines. What does that mean? In very rough terms, unless you need to access more than 2GB of RAM you won't realize any great benefit from running in 64-bits.

Upvotes: 6

Igor ostrovsky

Reputation: 7392

In simple cases, moving C# code from 32-bit to 64-bit is just a matter of changing the build settings. Safe C# code executes on 64-bit architectures the same way as it does on 32-bit.

In practice, you can run into several issues. Here are some to look out for:

Does your C# code contain unsafe code?

Unsafe code can manipulate pointers, and so it may be written in a way that assumes 32-bit pointers. To find out whether your projects contain unsafe code, you can search your codebase for the "unsafe" keyword.
Are you using P/Invoke?

If you are using P/Invoke to call into native code, the CLR runtime will now be looking for a 64-bit DLL rather than a 32-bit one. If a 64-bit DLL is not found at runtime, you'll get an exception ("BadImageFormatException" or something like that)

You can search your codebase for "DllImport" to see whether you are using P/Invoke.
Do your projects contain brittle code?

After you move your projects to 64-bit, you'll be using a different version of the Just-in-Time (JIT) compiler. The X64 JIT compiler performs some more aggressive optimizations compared to the X86 JIT. As a result, some incorrectly written (typically multi-threaded) code that happened to work in X86 may end up breaking on X64.
Are you using certain features like marshaling, serialization and COM interop?

Usages of all these features may need to be modified in the 64-bit build. Some of the keywords to search in your code include "Marshal", "StructLayout", "FieldOffset", "BinaryFormatter" and "Com".

Also check out this white paper that further discusses migrating 32-bit managed code to 64-bit: http://msdn.microsoft.com/en-us/library/ms973190.aspx

Upvotes: 14

zmbq

Reputation: 39023

If you're only using safe managed code, and no third-party DLLs, you should expect an easy enough migration.

You do want to test everything, though, because it's usually a good idea to test a product once it's gone such a major change. You might find some really weird incident that fails on 64 bit.

Upvotes: 0

Migrating From 32 to 64 bit Releases

Answers (4)

Related Questions