3

I have a C++ DLL that exposes stuff via COM. I want to convert it to C++/CLI that exposes a managed interface. Ideally I just add CLI and convert interfaces one by one. So far I haven't succeeded in anything, so I'm looking for a specific strategy.

More detail: A long time ago, I created an app using COM to communicate back and forth between C# and C++. I'm sick of COM, and the registration and the hoop jumping needed on the C++ side.

I want to use C++/CLI, and get the whole thing working as managed code with the occasional call from C++/CLI to native libraries I'm using.

Can anyone suggest a gentle migration path, such that I can have both CLI and COM going, and convert things over class by class testing as I go? Or something like that.

To be clear: I currently have native C++ code defining and implementing COM interfaces. I have C# code using COM attributes to export classes. All this stuff gets registered for COM interop, and there are calls in both directions. I hope to switch the C++ to CLI and switch to managed classes in C++ rather than COM classes.

Question updated for Ramhound: Anyway, I'm running into brick walls. Turning on /clr on a C++ dll gives me link errors from other stuff trying to connect to that C++ code. (Unreadable ATL/COM messages of the sort that drive me away from C++)

Alan Baljeu
  • 2,383
  • 4
  • 25
  • 40
  • Update your question. Your comment makes no sense. – Security Hound Feb 13 '12 at 19:26
  • 1
    There's nothing like "ideally" or "switching" for what you want to accomplish. It may be a lot of work. I understand this does not answer your question, but if COM registration is the main issue, you could switch to Registration-free COM: http://msdn.microsoft.com/en-us/library/ms973913.aspx – Simon Mourier Feb 17 '12 at 17:35
  • Thanks for your input, Simon. I was beginning to suspect that might be the case. I'll check that out. – Alan Baljeu Feb 17 '12 at 18:29
  • I haven't found a good answer to this question. I found the Reg-Free COM to be flaky, and I want to get away from that sort of problem, into code that just works. Consequently, though it's a lot of work, I'm porting over to strict C#. – Alan Baljeu Mar 01 '12 at 16:26

2 Answers2

2

You may want to read through this, as it provides some different approaches and considerations involved: http://msdn.microsoft.com/en-us/magazine/dd315414.aspx

Here is a simple example of how to use interop in C++/CLI, where you could define a method or two and add more as you go: https://learn.microsoft.com/en-us/archive/blogs/borisj/interop-101-part-1

E-rich
  • 9,243
  • 11
  • 48
  • 79
David
  • 89
  • 3
  • Thank you. The first link is very informative, and gives good considerations. In our case, performance is critical and the interop is basically passing access to C# objects. The data is recieved from C# via COM; new objects are created by calling back through COM; and when the C++ function ends, all this COM stuff is dropped. Now how can we introduce C++CLI? – Alan Baljeu Feb 16 '12 at 14:02
-1

please follow this

http://msdn.microsoft.com/en-us/magazine/cc163494.aspx

use tlimp to generate a COM unmanaged DLL to a managed DLL

is pretty simple!!!

cealex
  • 1
  • 2
    Sorry that doesn't answer the question. I already *have* a program that generates a managed interop DLL to connect to unmanaged COM. I *want* to stop using COM entirely, and use C++/CLI instead. – Alan Baljeu Feb 14 '12 at 14:54