C# 64-bit DLL?

[George2]

Hello everyone,


I am using C# to develop DLL using Visual Studio 2005 and .Net 2.0, and I have no idea of how to make my DLL work with applications on 64-bit platform. Above all, I do not utilize any new features in my DLL of 64-bit. So, I want to check the general rules,

1. For C#, is there a need to make two separate builds (32-bit and 64-bit) according to the application (32-bit or 64-bit) which uses the DLL? i.e. provide 64-bit application my 64-bit C# DLL, and provide 32-bit application runs on 64-bit platform my 32-bit DLL?

2. If we have to make two separate builds, how to do it in Visual Studio 2005? I only find a setting names for Any CPU in project --> properties.


thanks in advance,
George

[darwen]

Because .NET is JIT compiled, if you compile your dll as "Any CPU" it'll be run as 64 bit code on 64 bit machines and 32 bit code on 32 bit machines.

Bear in mind that the client application/and dll which references this also has to be built as "Any CPU".

You can add explicit x64 support to a build in the configuration manager (pull down the "Any CPU" combo box on the build toolbar and select "configuration manager").

Drop down the "Active Solution Platform" combo and select "New".

The default settings in the following dialog are fine : make sure the "create new project platforms" is checked.

Darwen.

[George2]

Thanks Darwen,


Because .NET is JIT compiled, if you compile your dll as "Any CPU" it'll be run as 64 bit code on 64 bit machines and 32 bit code on 32 bit machines.

Bear in mind that the client application/and dll which references this also has to be built as "Any CPU".

You can add explicit x64 support to a build in the configuration manager (pull down the "Any CPU" combo box on the build toolbar and select "configuration manager").

Drop down the "Active Solution Platform" combo and select "New".

The default settings in the following dialog are fine : make sure the "create new project platforms" is checked.

Darwen.

I have another DLL which reference this DLL, but the other DLL is native unmanaged native code (C++), and it is not .Net based. How to build the C# DLL in my case? Is *Any CPU* setting ok?


regards,
George

[darwen]

It should be... but the sizes of IntPtr will be different if you're interop-ing.

Just try it !

Darwen.

[Mutant_Fruit]

IntPtr will be the same size as a native pointer. Thats why you always represent a pointer type with an IntPtr in c#, as on both 64bit and 32bit systems, you can correctly represent the pointer without needing seperate compiles.

[darwen]

you can correctly represent the pointer without needing seperate compiles


I don't think this is true if you have a x64 .NET dll p/invoking into a 32-bit native dll, passing pointers through methods. On the .NET side IntPtr will be 8 bytes in size and on the native dll side void * will be 4 bytes in size.

I remember having this sort of trouble when my company upgraded its machines to 64 bit. We ended up doing a compile of everything for both 32-bit and 64-bit.

I've also had problems with a 32-bit .NET assembly being referenced by an "Any CPU" built .NET assembly on Windows 64 - NUnit in fact didn't seem to like mixing like this.

Darwen.

[Mutant_Fruit]

Well, thing is there is no X64 as opposed to X86 .NET dll.

For example, i could define a struct as follows:


struct MyStruct
{
IntPtr pointerToSomething;
}

On a 32bit system, that IntPtr will be 32 bit, on a 64bit system, that IntPtr will be 64bit. So that single dll can succesfully hold a pointer on both 32bit and 64bit platforms without needing a recompile.

There are other issues (such as the way long's change in size based on compiler and architecture) but as the guy is writing one of the C++ libs involved, he can just make sure to not expose any 'long' types in his API and he should be fine,

EDIT: It's possible i'm just not understanding something here. I know a bit about P/Invoking, but definitely not everything ;)

[darwen]

Well, thing is there is no X64 as opposed to X86 .NET dll


Not strictly true.

You can set the 'target' processor bitsite for an assembly using CorFlags.exe - seehere. ('http://msdn2.microsoft.com/en-us/library/ms164699(VS.80).aspx')

Also you can have builds of .NET assemblies targetted for x64 or x86 machines because of interop potential problems : see here. ('http://www.ddj.com/hpc-high-performance-computing/184405994')

Darwen.

[George2]

Thanks Mutant_Fruit,


Well, thing is there is no X64 as opposed to X86 .NET dll.

For example, i could define a struct as follows:


struct MyStruct
{
IntPtr pointerToSomething;
}

On a 32bit system, that IntPtr will be 32 bit, on a 64bit system, that IntPtr will be 64bit. So that single dll can succesfully hold a pointer on both 32bit and 64bit platforms without needing a recompile.

There are other issues (such as the way long's change in size based on compiler and architecture) but as the guy is writing one of the C++ libs involved, he can just make sure to not expose any 'long' types in his API and he should be fine,

EDIT: It's possible i'm just not understanding something here. I know a bit about P/Invoking, but definitely not everything ;)

Let us come back to the original question,

I am wondering why people need to make separate 32-bit or 64-bit builds, since Any CPU can fit into 32-bit/64-bit on demand. Could you give an example why we need to make separate 32-bit and 64-bit builds please?


regards,
George

[George2]

Thanks Darwen,


I am not using IntPtr and let us discuss the original question. ;)

Not strictly true.

You can set the 'target' processor bitsite for an assembly using CorFlags.exe - seehere. ('http://msdn2.microsoft.com/en-us/library/ms164699(VS.80).aspx')

Also you can have builds of .NET assemblies targetted for x64 or x86 machines because of interop potential problems : see here. ('http://www.ddj.com/hpc-high-performance-computing/184405994')

Darwen.

I think if Any CPU settings can fit into both 32-bit and 64-bit on demand, why do we still need to make separate builds for 32-bit and 64-bit? Could you give an example please?


regards,
George

[Mutant_Fruit]

In most use cases, there's no need to make 64bit versus 32bit builds. I've just written an updated version of libgphoto2-sharp which interoperates with libgphoto2 on both 64bit and 32bit platforms with the one c# dll.

Like i said before, i don't know everything there is to know about native interop, but i know my binding will run fine on both 64bit linux, 32bit linux, 64bit macos, 32bit macos and 32bit windows.

The only reason why you might possible need two builds is if you run Windows 64bit. A .NET application using IntPtr's (pretty much required if you want a cross-platform P/Invoke call) cannot actually P/Invoke a 32bit library on windows64 as an IntPtr will be 64bit, whereas the native 32bit app will expect a 32bit IntPtr. Of course, this may already be not-allowed under Win64 (i can't test it), so it may be a non-issue. It's quite possible that if you were running the 64bit .NET framework, it wouldn't allow you touch a 32bit dll:

Although 32-bit applications can be run transparently, the mixing of the two types of code within the same process is not allowed. A 64-bit application cannot link against a 32-bit library (DLL) and similarly a 32-bit application cannot link against a 64-bit library. This may lead to the need for library developers to provide both 32- and 64-bit binary versions of their libraries
source: http://en.wikipedia.org/wiki/Windows_XP_Professional_x64_Edition#Compatibility_with_32-bit_applications

Actually, one situation where you'd *need* to make a 64bit build would be if you *needed* to be able to access more ram than a 32bit system would allow you to.

Also, if you're not using IntPtr, good luck to you interoping on both 32bit and 64bit platforms with one binary....

[George2]

Thanks Mutant_Fruit,


Seems from your point of view, all the reason why we need a separate 32-bitr and 64-bit build is because of we use some special things of 64-bit. But my application does not utilize any 64-bit special things, and I describe my situation in details below,

In most use cases, there's no need to make 64bit versus 32bit builds. I've just written an updated version of libgphoto2-sharp which interoperates with libgphoto2 on both 64bit and 32bit platforms with the one c# dll.

Like i said before, i don't know everything there is to know about native interop, but i know my binding will run fine on both 64bit linux, 32bit linux, 64bit macos, 32bit macos and 32bit windows.

The only reason why you might possible need two builds is if you run Windows 64bit. A .NET application using IntPtr's (pretty much required if you want a cross-platform P/Invoke call) cannot actually P/Invoke a 32bit library on windows64 as an IntPtr will be 64bit, whereas the native 32bit app will expect a 32bit IntPtr. Of course, this may already be not-allowed under Win64 (i can't test it), so it may be a non-issue. It's quite possible that if you were running the 64bit .NET framework, it wouldn't allow you touch a 32bit dll:


source: http://en.wikipedia.org/wiki/Windows_XP_Professional_x64_Edition#Compatibility_with_32-bit_applications

Actually, one situation where you'd *need* to make a 64bit build would be if you *needed* to be able to access more ram than a 32bit system would allow you to.

Also, if you're not using IntPtr, good luck to you interoping on both 32bit and 64bit platforms with one binary....



For my situation, the exe is native unmanaged 32-bit application, which runs on 64-bit x64 platform. The exe depends on a native unmanaged C++ DLL A, and the DLL A dependes on a C# managed DLL B.

Sorry for the complex relationship, and it is because of some legacy
application compatibility.

In my situation, I think I have to build the DLL A into 32-bit. But how
about the DLL B? Do I have to build it into x86-32bit or I can keep it to Any
CPU?

I have tried build DLL B as Any CPU works, but I do not know whether it is
most correct to make it Any CPU, or other configurations (separate 32-bit or 64-bit) should be better? Thanks!


regards,
George

[Mutant_Fruit]

I'm not sure if you can do what you're asking at all. A 32bit dll can't reference a 64bit dll (and vice versa) on windows 64. So there's no point in asking how C# handles this because it can't happen.

[George2]

Thanks Mutant_Fruit,


I'm not sure if you can do what you're asking at all. A 32bit dll can't reference a 64bit dll (and vice versa) on windows 64. So there's no point in asking how C# handles this because it can't happen.

My situation/choices are,

1. on Windows 64-bit machine, 32-bit application (dependent on ) --> 32 bit native unmanaged DLL --> Any CPU C# managed DLL;

2. on Windows 64-bit machine, 32-bit application (dependent on ) --> 32 bit native unmanaged DLL --> x86 32-bit C# managed DLL;

Are they both workable? Which is the best one or there are better solutions?


regards,
George