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
14  11019 
"George" <Ge****@discussions.microsoft.comwrote in message
news:D9**********************************@microsof t.com...
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,
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.
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
"Willy Denoyette [MVP]" wrote:
"George" <Ge****@discussions.microsoft.comwrote in message
news:D9**********************************@microsof t.com...
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,
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.
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.
"George" <Ge****@discussions.microsoft.comwrote in message
news:1B**********************************@microsof t.com...
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
"Willy Denoyette [MVP]" wrote:
>"George" <Ge****@discussions.microsoft.comwrote in message
news:D9**********************************@microso ft.com...
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,
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.
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
"Willy Denoyette [MVP]" wrote:
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.
"George" <Ge****@discussions.microsoft.comwrote in message
news:1B**********************************@microsof t.com...
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
"Willy Denoyette [MVP]" wrote:
"George" <Ge****@discussions.microsoft.comwrote in message
news:D9**********************************@microsof t.com...
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,
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" <Ge****@discussions.microsoft.comwrote in message
news:BF**********************************@microsof t.com...
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 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.
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
"Willy Denoyette [MVP]" wrote:
"George" <Ge****@discussions.microsoft.comwrote in message
news:BF**********************************@microsof t.com...
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 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" <Ge****@discussions.microsoft.comwrote in message
news:12**********************************@microsof t.com...
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.
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.
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
"Willy Denoyette [MVP]" wrote:
"George" <Ge****@discussions.microsoft.comwrote in message
news:12**********************************@microsof t.com...
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.
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" <Ge****@discussions.microsoft.comwrote in message
news:6F**********************************@microsof t.com...
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?
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.
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
"Willy Denoyette [MVP]" wrote:
"George" <Ge****@discussions.microsoft.comwrote in message
news:6F**********************************@microsof t.com...
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?
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" <Ge****@discussions.microsoft.comwrote in message
news:8B**********************************@microsof t.com...
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?
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.
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
"Willy Denoyette [MVP]" wrote:
"George" <Ge****@discussions.microsoft.comwrote in message
news:8B**********************************@microsof t.com...
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?
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" <Ge****@discussions.microsoft.comwrote in message
news:2E**********************************@microsof t.com...
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.
Thanks for all of your help on this topic, Willy!
regards,
George
"Willy Denoyette [MVP]" wrote:
"George" <Ge****@discussions.microsoft.comwrote in message
news:2E**********************************@microsof t.com...
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.
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Marc Poinot |
last post by:
Did anybody use numarray on a 64 bits platform ? (e.g. SGI/Irix)
The package works on our 64 bits platforms... using 32 bits mode,
but not using 64 mode. Big crash in _ufunc... Is there a flag to...
|
by: Hugo |
last post by:
I have a dual boot machine, runs Win XP pro and Win XP Pro 64, XP boots from
C and XP 64 boots from D.
They both have VS 2005 Beta 2 installed.
I have a webapp developed in Win XP (32) which...
|
by: Odd Bjørn Andersen |
last post by:
I was asked to install db2 udb workgroup edition (version 7.2) 64-bits on
AIX. But I cannot find that we have a CD with that software. Only Enterprise
Edition.
Is it correct that you have to...
|
by: Dave Vandervies |
last post by:
I just fixed a bug that some of the correctness pedants around here may
find useful as ammunition.
The problem was that some code would, very occasionally, die with a
segmentation violation...
|
by: Hugo |
last post by:
I have a dual boot machine, runs Win XP pro and Win XP Pro 64, Win XP boots
from C and Win XP 64 boot from D.
They both have VS 2005 Beta 2 installed.
I have a webapp developed in Win XP (32)...
| | |
by: some one |
last post by:
I have kind of wired problem, I using httpwebrequest to post form data to
server , in the GetResponse stage a WebException occurred, after tracing the
actual error that occurs on the server, I...
|
by: mel_apiso |
last post by:
Hi,
we have an AIX 5.3 OS, and we purchased DB2 UDB version 8 Workgroup
Edition.
We want to install 64 bits version, but the source CD's that we have
say:
WORKGROUP SERVER EDITION
Version...
|
by: Mary Lei |
last post by:
Does anyone know the link to obtain the
tarball for db2 8.1 for solaris running
on AMD 64 bit ?
This is the entire db2 installation
on a new system that does not have db2.
Thanks.
|
by: krunalb |
last post by:
Hi,
I am trying to shift unsigned long long value by 64 bits and this is
what i get
#include <stdio.h>
int main()
{
unsigned short shiftby= 64;
|
by: =?Utf-8?B?UGF1bCBQaGlsbGlwcw==?= |
last post by:
I have read many things about this but I haven't got a clear vision on what
to do if anything about this.
I have a system that tries to find holes in my web site. One of the things
it has...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| | |
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
