.NET Forum / Languages / C# / October 2007
C# 64-bit DLL?
|
|
Thread rating:  |
George - 19 Oct 2007 10:23 GMT 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
Willy Denoyette [MVP] - 19 Oct 2007 11:08 GMT > Hello everyone, > [quoted text clipped - 4 lines] > want > to check the general rules, Check your Project Build Properties, the default Platform target option is set to *AnyCpu*, which mean that your DLL will run as a 64 bit when loaded in a 64 bit process and as 32 bit when loaded in a 32 bit process.
> 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? No, when building a DLL you better keep the default Platform as is ("AnyCpu"). When talking about an executable assembly things get a bit more complicated. If your application really needs the extended addressing range offered by 64bit Windows, then you have to build your exe as a 64 bit application (Platform = X64 or IA64 depending on the platform), such application cannot run on X86 anyway. However, if you don't need the extended addressing capability AND you don't need to run on IA64, then you better set the Platform to "X86". This way, your appplication runs as 32 bit on all Windows platforms (IA32 and X64).
> 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. You should have AnyCpu, X86, X64 and Itanium, what version of VS2005 are you running?
Willy.
George - 19 Oct 2007 14:34 GMT Thanks Willy,
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
> > Hello everyone, > > [quoted text clipped - 33 lines] > > Willy. Willy Denoyette [MVP] - 19 Oct 2007 20:52 GMT Yes AnyCpu is ok.
It's the main entry point of the managed assembly who determines which CLR version that gets loaded. So if you have native code dependencies, then your main assembly will need to specify the same bit-ness as the native DLL.
Managed exe 64 bit (x64) ---> Managed DLL (AnyCPU) --> Unmanaged code (X64) Managed exe 64 bit (IA64) ---> Managed DLL (AnyCPU) --> Unmanaged code (IA64) Managed exe 64 bit (x86) ---> Managed DLL (AnyCPU) --> Unmanaged code (X86) are all ok, other combinations are not.
Willy.
> Thanks Willy, > [quoted text clipped - 53 lines] >> >> Willy. George - 21 Oct 2007 08:41 GMT Hi Willy,
Can you help to describe what does your sign ---> mean the one of the sample please? I can understand more if I read some literal words. :-)
Like,
> Managed exe 64 bit (x64) ---> Managed DLL (AnyCPU) --> Unmanaged code > (X64) A further 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
> Yes AnyCpu is ok. > [quoted text clipped - 68 lines] > >> > >> Willy. Willy Denoyette [MVP] - 21 Oct 2007 10:00 GMT > Hi Willy, > [quoted text clipped - 6 lines] >> Managed exe 64 bit (x64) ---> Managed DLL (AnyCPU) --> Unmanaged code >> (X64) A managed 64bit exe loads (and runs) a managed code DLL (AnyCPU) which depends on an unmanaged 64bit DLL. Here you have a 64bit *native code library* dependency, that means that the main managed assembly must load the 64bit CLR, so it has to be compiled as X64 (or IA64).
> A further 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? In general you don't need separate builds. If your code depends on the extended addressing range offered by 64 bit Windows, you'll have to build for X64 (or IA64), building a 32bit version makes no sense here. If your code doesn't need the extended addressing range offered by 64 bit Windows, there is no need to build a 64bit version, unless it depends on 64 bit native code DLL's (including COM!).
Willy.
George - 21 Oct 2007 10:41 GMT Thanks for your 3 rules, Willy!
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 should be better? Thanks!
regards, George
> > Hi Willy, > > [quoted text clipped - 28 lines] > > Willy. Willy Denoyette [MVP] - 21 Oct 2007 16:10 GMT > Thanks for your 3 rules, Willy! > [quoted text clipped - 3 lines] > and > the DLL A dependes on a C# managed DLL B. Hmmm... In this scenario, you are exposing this DLL B as a COM server, that is, you are using COM interop to call from native into the managed code. This is a bit more complicated, as it involves registration in the COM catalog. Here, you need to make sure you register the DLL using the right version of Regasm.exe, don't know if VS2005 even cares about this when you specify register for COM interop. If you only want to expose the dll to 32bit clients, then you'll have to build the DLL as 'AnyCpu' or 'X86', AND register the DLL using regasm 32bit (in Framework\vxxxxxx directory). If you only want to expose the dll to 64bit clients, then you can build the DLL as 'AnyCpu' or 'X64', AND register the DLL using regasm 64bit (in Framework64\vxxxxxx directory). If you want to expose to both, 32 and 64 bit clients, then you need to build using "AnyCpu", AND you need to register twice, once using 32bit and once using the 64bit version of regasm.
Willy.
George - 21 Oct 2007 17:28 GMT Thanks Willy,
> Hmmm... In this scenario, you are exposing this DLL B as a COM server, that > is, you are using COM interop to call from native into the managed code. > This is a bit more complicated, as it involves registration in the COM > catalog. Cool! This is exactly what I am doing now.
From your reply, I think a lazy way is to build DLL B (managed C# DLL COM Server) as Any CPU since I do not expose or utilize any 64-bit function in the EXE, and DLL A. Is that all right?
regards, George
> > Thanks for your 3 rules, Willy! > > [quoted text clipped - 22 lines] > > Willy. Willy Denoyette [MVP] - 21 Oct 2007 17:39 GMT > Thanks Willy, > [quoted text clipped - 9 lines] > Server) as Any CPU since I do not expose or utilize any 64-bit function in > the EXE, and DLL A. Is that all right? Your executable (native code) is built as a 32 bit binary, so, you need to make sure that the COM server (C# dll here), is loaded with the 32bit CLR. This is accomplished by registering the DLL with the 32bit version of regasm.exe. The 32bit CLR can run "X86" and "AnyCpu" targets, but nothing else, so both are valid options. Willy.
George - 21 Oct 2007 17:49 GMT Hi Willy,
I am wondering what do you mean 32-bit regasm and 64-bit regasm? Currently I am using regasm from Visual Studio 2005 command line (development machine is 32-bit Windows XP Professional), by
regasm /codebase <DLL assembly name>
is it 32-bit regasm? Where to find the 64-bit regasm?
regards, George
> > Thanks Willy, > > [quoted text clipped - 17 lines] > Willy. > Willy Denoyette [MVP] - 21 Oct 2007 17:59 GMT > Hi Willy, > [quoted text clipped - 7 lines] > > is it 32-bit regasm? Where to find the 64-bit regasm? As you are running 32-bit Windows, you only have a 32-bit version of the framework installed. The 64 bit version of the tools come with the 64-bit version of the Framework, and this only on 64-bit windows (XP-64, W2K3-64 and Vista-64).
Willy.
George - 22 Oct 2007 08:14 GMT Thanks Willy,
I think I need to install Visual Studio 2005 on a 32-bit machine and on a 64-bit machine, so that I could have both. :-)
regards, George
> > Hi Willy, > > [quoted text clipped - 14 lines] > > Willy. Willy Denoyette [MVP] - 22 Oct 2007 10:31 GMT > Thanks Willy, > > I think I need to install Visual Studio 2005 on a 32-bit machine and on a > 64-bit machine, so that I could have both. :-) If you install VS2005 on a 64-bit OS, you'll have both 32 and 64-bit Frameworks installed, note that Vista-64 comes with both Frameworks installed.
Willy.
George - 22 Oct 2007 11:18 GMT Thanks for all of your help on this topic, Willy!
regards, George
> > Thanks Willy, > > [quoted text clipped - 6 lines] > > Willy.
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|