porting 32bit .net to 64 bit app

[viren.chaudhary2008]

I have just few questions. We are thinking of porting our 32 bit
application to 64 bit as we need to use more memory usage and want to
take advantage of 64 bit processor. Currently my applications which
has lot of webservices also is compiled in Visual studio 2003
using .net 1.1 To convert to 64 bit, i will be using visual studio
2005 and compile it in x64 platform. I have following questions

1. Do i have to build the application in 64 bit machine before
deploying it to 64 bit windows 2003 servers(which is our prod
servers)?

2. I have lot of third party Com object which i used it in our
application. We did created a wrapper over it using tlbimp.exe and
refering .Net wrapper in our projects. The question is underlying com
dlls are still 32 bit. will it work when we use it in 64 bit
application? do i have to create a wrapper again and if i have to,
has it to be don using tlbimp.exe 64 bit version? Because if i just
compile my application in 64 bit platform fin 32 bit machine and then
deploy to 64 bit servers, i do get error loading those com objects. As
of now we don't have 64 bit version of those dependent com dlls.Does
it mean we cannot port our app to 64 bit?



Any kind of help or articles regarding this would be of great help.

 

[Michael B. Trausch]

On Sat, 1 Nov 2008 09:29:48 -0700 (PDT)

I have just few questions. We are thinking of porting our 32 bit
application to 64 bit as we need to use more memory usage and want to
take advantage of 64 bit processor. Currently my applications which
has lot of webservices also is compiled in Visual studio 2003
using .net 1.1 To convert to 64 bit, i will be using visual studio
2005 and compile it in x64 platform. I have following questions

1. Do i have to build the application in 64 bit machine before
deploying it to 64 bit windows 2003 servers(which is our prod
servers)?

Managed code which runs entirely within the CLR is platform-independent
and processor-agnostic. That is to say, unless you're including native
code in your application software bundle written in an unmanaged
language such as C or C++ compiled to native binary, you can use a .NET
2.0 binary on any system that has an implementation of the CLR (whether
or not it has a JIT, though if the platform does not have a JIT the
code will run more slowly).

2. I have lot of third party Com object which i used it in our
application. We did created a wrapper over it using tlbimp.exe and
refering .Net wrapper in our projects. The question is underlying com
dlls are still 32 bit. will it work when we use it in 64 bit
application? do i have to create a wrapper again and if i have to,
has it to be don using tlbimp.exe 64 bit version? Because if i just
compile my application in 64 bit platform fin 32 bit machine and then
deploy to 64 bit servers, i do get error loading those com objects. As
of now we don't have 64 bit version of those dependent com dlls.Does
it mean we cannot port our app to 64 bit?

Someone who actually uses COM will be of more help here than I will.

If 64-bit Windows can load these 32-bit COM DLLs and they aren't
directly accessed by the application, then you should be able to use
them, though they will not receive any of the benefits of a 64-bit
system. If you have to access these DLLs directly, say via P/Invoke,
then you must:

* Run your managed code entirely in a 32-bit process (meaning that you
don't gain anything from being on a 64-bit machine, save for being
able to run more processes in active memory at the same time),
* Obtain both 32-bit and 64-bit versions of the DLLs and deploy the
appropriate ones with the application when it is deployed, or
* Reimplement the components in-house as managed code which exposes
the components to COM such that other applications can consume them.

You don't need to use a different wrapper if the wrapper uses P/Invoke
and you swap 32-bit/64-bit libraries, unless the data types change in
any way. That is, if the public interface provided by the DLL files is
identical on both platforms, you can P/Invoke the same way, using the
DLL name and the entrypoint name, just fine.

The .NET platform will, for a CLR binary marked platform-agnostic,
execute the binary under a version of the CLR for the current CPU. If
you _need_ to load 32-bit versions of these libraries, and those 32-bit
libraries are supported on 64-bit Windows via execution under the WoW
environment, then you need to target your assemblies for x86 so that
Windows will execute them in a WoW environment with a 32-bit address
space. Some reading material which discusses this is the book "CLR via
C#" in Chapter 1, "The CLR's Execution Model", by Jeffrey Richter and
published by Microsoft Press.

--- Mike