Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / C# / October 2007

Tip: Looking for answers? Try searching our database.

C# 64-bit DLL?

Thread view: 
Enable EMail Alerts  Start New Thread
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 Magazines

Get 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 ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.