views:

239

answers:

2

We have a windows service that uses dlls produced from a bunch of different .NET projects. One of those projects has a dependency on a dll that was compiled on 32 bit machine.

We have just moved the windows service to a 64 bit machine. By default .NET projects try to run as 64 bit assembly (because they are being run on a 64 bit machine). However, I can force individual projects to run as 32 bit assembly by specifying the Platform Target as 'x86' rather than 'Any CPU'.

My question is: do all the .NET projects need to be forced to run as a 32 bit assembly? Can 32 bit assembly and 64 bit assemblies be run together?

A: 

If there is no unsafe code and/or references on the unmanaged dlls you can safely compile everything with the target Any CPU.

The result of compilation is then CPU agnostic - the resulting IL is JIT - compiled by the CLR on the target machine, whatever the machine will be.

If the box is a 64 bit box it will be compiled to the by the 64 bit CLR to the 64 bit instruction set and will be happily run in the native 64 bit mode

mfeingold
One of the references is to a third party dll that seems to work fine on a 32 bit machine, but is tossing errors on 64 bit machine. (i.e. I can't recompile that Dll, and I can't guarantee it was compiled with the target 'Any CPU') Basically the solution works fines on a 32 bit machine, but on a 64 bit machine apachefop.net tosses the error "Could not load file or assembly 'apachefop.netAn attempt was made to load a program with an incorrect format.", and I'm wondering if I have to convert individual projects (the one with the dependency) or if I have to convert every project in the solution.
Daniel
+1  A: 

I think as long as you're not using native modules or anything, you're probably fine, though you can still have bugs in your code if you assume the size of a pointer, etc., anywhere.

"If you have 100% type safe managed code then you really can just copy it to the 64-bit platform and run it successfully under the 64-bit CLR."

http://www.hanselman.com/blog/CommentView.aspx?guid=4099df2d-ef01-4f70-a7f7-829eabc36afc

Tim Sylvester