3

I need to use a COM-DLL from an external company (so I have no source code) that only works with the compile-option CPU-Target x86.

But my program is a "Any CPU" program and I don't want to change this.

So I read and google a lot and found out that I need 2 processes that communicate with IPC and WCF.

The problem: WCF isn't available with the .Net Framework 2.0.

So what is the best and easiest way to do it without change CPU-Target from my main program?

Tim Siefert
  • 606
  • 2
  • 7
  • 13

3 Answers3

4

If you have a x86 target dll, be it a .Net assembly or a native dll then you must host this dll in a 32 bit process - in the case of .Net this means selecting the x86 platform, otherwise your dll wil fail to load on a 64 bit machine.

If you absolutely must have a 64 bit process when possible then your only real means of using this dll will be to create an external 32 bit process that "hosts" the dll and communicated with your main 64 bit process via IPC (interprocess communication). WCF is only 1 method of communicating between processes - its not available in .Net 2.0 however you can still use other methods such as .Net remoting.

See Interprocess communication for Windows in C# (.NET 2.0)

However all of this will be a pain to implement and maintain - unless you have a very good reason just compile your application with the x86 platform instead, at least until the external company release a 64 bit version.

Community
  • 1
  • 1
Justin
  • 84,773
  • 49
  • 224
  • 367
1

If you don't want to change your assembly to "x86" then you need to use some form of IPC, of which WCF is only one. Another option is to used Named Pipes to communicate between the two processes.

jcopenha
  • 3,935
  • 1
  • 17
  • 15
0

In the past I've always written a .NET wrapper for COM and C++ DLLs and placed it within it's own class library.

The wrapper can deal with all interop calls to the dll.

It also allows you to perform data conversion and error reporting that would be meaningful to both parties (your NET application and the COM DLL).

I would think that this should solve your problem.

EDIT

Actually I've thought further on this and the above process won't work. This is because the X86, x64 and Itanium target processors are so fundamentally different.

edited x64 is able to run x86 targetted code and so can Itanium (which used an emulator and now an extension EM64T)

There's more information here

What you may be able to do though is run your x86 dll within a separate process and implement some form of communication between them. I guess that this is why you mentioned WCF. I say this because x86 software should run on x64 system.

This would mean that your solution would have two executables one x86 and one AnyCPU, as an assembly can only be targetted at one CPU type.

ChrisBD
  • 9,104
  • 3
  • 22
  • 35
  • But than my wrapper must be compile with x86 and my main program with "anycpu". If now my program use a class e.g. "MyWrapper" (x86) and this class use mit 32bit COM-DLL. This not works. I became an Exception because mit "AnyCPU"-Program cant use the assembly from the WrapperProject. – Tim Siefert Feb 15 '12 at 12:09
  • Actually I've gone away and thought about this more. See my reply. – ChrisBD Feb 15 '12 at 14:04
  • 1
    Just to nit-pick, IA64 incorporates a decoder that "emulates" x86 instructions however **x64 is a proper extension of x86 that is still capable of running x86 code natively** (although not in the same process as x64 code under Windows) – Justin Feb 15 '12 at 14:14
  • Thank you Jason - I was confusing my Itanium 64 bit emulation with the X64. – ChrisBD Feb 15 '12 at 15:54