Click here to Skip to main content
15,851,387 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I have a C# application that I'd like to make 64-bit but I have a library dll that only works when I compile 32-bit.

Is there any other way than having two separate executables to achieve this?

I don't think it should matter, but for completeness the dll in question is Interop.MRTKTASKLib.dll.

The Exception message I get is "Retrieving the COM class factory for component with CLSID ... failed due to the following error: 80040154."


Not directly no.

There might be a workaround Accessing 32-bit DLLs from 64-bit code[^], but it comes with a lot of strings attached.

You might have to re-evaluate your reasons for wanting to convert to 64-bit.
Share this answer
Sergey Alexandrovich Kryukov 11-Oct-11 18:32pm    
Correct, my 5. In my solution, I credited your answer and added explanation on a bit more basic level, please see.
André Kraak 12-Oct-11 1:03am    
Thanks all who replied. Based on the answers, I thought if I looked long enough I'd find something that would allow me to connect easily.

I found it.

It involves the registry.

1. Locate your COM object GUID under the HKey_Classes_Root/Wow6432Node/CLSID

2. Once located add a new REG_SZ (string) Value. Name should be AppID and data should be the same COM object GUID you have just searched for

3. Add a new key under HKey_Classes_Root/Wow6432Node/AppID .The new key should be called the same as the com object GUID

4. Under the new key you just added, add a new REG_SZ (string) Value, and call it DllSurrogate. Leave the value empty

5. Create a new Key under HKey_Local_Machine/SoftwareClasses/AppID if it doesn't already exist. Again the new key should be called the same as the COM object's GUID. No values are necessary to be added under this key.
Share this answer
Member 12694392 14-Feb-17 23:43pm    
hi, i am facing relative problem. currently i am running my code in 64 bit operating system which is extracting data from a 32 bit dll. this is not happening.
pl need help thanx
The answer by André is correct. The fact is more basic: you cannot link DLLs targeted to different instruction-set achitectures in one process in any way, even dynamically loading an assembly during run-time and using Reflection. Moreover, the code may compile but crash during runtime. So, there is only one work-around: codes targeted to different instruction-set architectures compatible with machine architectures can only be run in different process. The conclusion is apparent here: the only way to collaborate is using Inter-Process Communications (IPC). If someone claims that some technology uses different architectures, such as COM, it means IPC is used under the hood.

Share this answer
Orcun Iyigun 11-Oct-11 18:48pm    
What if he modifies the project's platform to 'X86'? Won't this solves the issue? Or if he has access to change the DLL's target platform to X86? Am I missing something? Can you please explain?
Sergey Alexandrovich Kryukov 11-Oct-11 19:54pm    
Sure it will! This architecture is available on both 64-bit platforms via WoW64. The only problem is, I don't know if OP would need to re-implement any of the components and if this is affordable.
Orcun Iyigun 11-Oct-11 19:57pm    
Thanks for the answer.
ARBebopKid 11-Oct-11 19:20pm    
"If someone claims that some technology uses different architectures, such as COM, it means IPC is used under the hood."

Are you saying that COM uses IPC and should work from 32-bit or 64-bit?
Sergey Alexandrovich Kryukov 11-Oct-11 19:52pm    
Yes, there is a variant of COM-server (not "In-proc" server but as a separate process) which can use different architecture. With C#, you don't need all that; there is classical remoting and WCF. Self-hosted WCF is straightforward in implementation, can be quite light-weight and created good illusion of direct calls of API, but in fact this is a call of method of the proxy, with IPC transport under the hood. Good enough if you cannot afford making all of the code in one instruction-code architecture...

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

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900