Click here to Skip to main content
12,446,146 members (22,709 online)
Rate this:
 
Please Sign up or sign in to vote.
See more: C# VB VB.NET
Dear Developer,
I Have 32 bit DLL, that i want to use in 64 bit machine.

Please help or guide me.

Thanks in Advance.

Regards,
Ravi Sharma
Posted 15-Jun-11 21:14pm
Updated 17-Jun-11 2:22am
v3
Rate this: bad
 
good
Please Sign up or sign in to vote.

Solution 2

All 64-bit platforms (there are two Intel instruction-set architectures, IA-64 (Itanium) and x86-64, see http://en.wikipedia.org/wiki/Itanium[^], http://en.wikipedia.org/wiki/X86-64[^]) work on the platform of WoW64, see http://en.wikipedia.org/wiki/WoW64[^].

All three instruction-set Intel architectures are incompatible, but a 32-application is compatible with both 64-bit instruction-set Intel architectures. The problem is: executable modules with different target architectures cannot be used in the same process. The solution with such projects using each other will build into assemblies, but they will crash during run-time.

Now, the delicate aspect is the target platform "Any CPU". As .NET code is JIT-compiled, such executable modules will be JIT-compiled during run-time due to the physical architecture they are loaded on. This is if all the projects were compiled "Any CPU". If not, the actual run-time will be defined by the entry assembly of the application. In case of conflict — see above.

Another problem is P/Invoke which can tie .NET assembly to a certain instruction-set architecture or, just the opposite, link it to a different architecture after moving to 64-bit platform while you require 32-bit version, simply because the DLL under the same names comes in 64-bits. Such problems are more difficult to detect. One good tool to help is Microsoft Dependency Walker, see http://en.wikipedia.org/wiki/Dependency_Walker[^], http://www.dependencywalker.com/[^]. You really need to know all your dependencies in unmanaged codes.

—SA
  Permalink  
v3
Comments
Kim Togo 16-Jun-11 16:30pm
   
Good answer. My 5.
SAKryukov 16-Jun-11 21:27pm
   
Thank you, Kim.
--SA
divesh12 16-Jun-11 16:33pm
   
nice
SAKryukov 17-Jun-11 3:26am
   
Thank you.
--SA
Espen Harlinn 16-Jun-11 17:19pm
   
Good effort, my 5 as usual :)
SAKryukov 16-Jun-11 21:27pm
   
Thank you, Espen.
--SA
jayantbramhankar 17-Jun-11 8:25am
   
Good anwser.
SAKryukov 17-Jun-11 13:34pm
   
Thank you.
--SA
thatraja 17-Jun-11 10:45am
   
Good bunch, 5!
SAKryukov 17-Jun-11 13:35pm
   
Thank you, Raja.
--SA
Rate this: bad
 
good
Please Sign up or sign in to vote.

Solution 3

If your dll is a native 32-bit dll - you could wrap it as a COM server.

Ed Strassberger has a very neat example on how call a 32-bit COM out of process server from a 64-bit client - he answers his own question in this posting:
64-bit client call to 32-bit COM/ATL server EXE fails[^]

Best regards
Espen Harlinn
  Permalink  
Comments
SAKryukov 17-Jun-11 3:14am
   
This is important point to know, my 5. (However, COM supposed to be a temporary work-around, a dead-end path.)
--SA
Espen Harlinn 17-Jun-11 12:51pm
   
Thank you, SAKryukov!
thatraja 17-Jun-11 10:45am
   
Nice fix link, 5!
Espen Harlinn 17-Jun-11 12:52pm
   
Thank you, thatraja!
Rate this: bad
 
good
Please Sign up or sign in to vote.

Solution 1

Hope this[^] might help you.

IIRC a reboot is required for it to take effect.

Have you done it.
  Permalink  
v2

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month


Advertise | Privacy | Mobile
Web01 | 2.8.160811.3 | Last Updated 17 Jun 2011
Copyright © CodeProject, 1999-2016
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100