0

Let me elaborate, before someone is thundering down on me with "Never reuse a COM interface!!!"

We implemented an COM interface on a program which is discontinued. We now actually buy a similar piece of software from a third party (so I can't change that!)

The COM interface is still used by many (third party) programs. Now I have to integrate the new piece of software with these programs (which I can't change because they are third party).

So I think I need a proxy: This proxy will reuse the COM interface so none of the third party programs will be able to tell they're not talking to the discontinued software. Inside the COM object, I'll 'translate' the commands and forward them to the new piece of software.

I'm using C# to build my proxy and I've used the tlbimp.exe to generate a DLL from the type library of the old program.

I'm referencing this generated DLL in my COM project where I provide a implementation for the given interface. Next, I register the output DLL from my project and use a old client to call the proxy.

It returns the error: Unable to cast object of type 'Lib.ApiClass' to type 'Lib.ApiClass'.

Why is that? Should I use a different approach?

Frank Kaaijk
  • 283
  • 1
  • 3
  • 11
  • _"Never **reuse** a COM interface!!!"_ - that's the _whole_ point of COM. I guess they never heard of _DirectX; MMC; Windows Shell_? – MickyD Mar 23 '15 at 14:38
  • Ah! Yes sorry! Reuse the same interface on a different component. I'm doing just that. I thought that was a no-no in COM. – Frank Kaaijk Mar 23 '15 at 15:00
  • No problem there. So do these other programs instantiate the COM object? Was the original a in-process or out-of-process COM server? Yes you could make a proxy or even overwrite the COM registration so the 'handler' is your server. Checkout OleView.exe to get the idea then do in code – MickyD Mar 23 '15 at 15:10
  • The original was an out-of-process COM server. I suppose that'll pose a problem now that I use a DLL? – Frank Kaaijk Mar 23 '15 at 22:02
  • It might be best to keep it out-of-process then. Check out some of the suggestions [here](http://stackoverflow.com/questions/446417/create-out-of-process-com-in-c-net). As well as _[How to develop an out-of-process COM component by using Visual C++, Visual C#, or Visual Basic .NET](https://support.microsoft.com/en-us/kb/977996)_. Note you'll probably need to take ownership of the CLASSIDs as well as the interfaces of the original. – MickyD Mar 23 '15 at 23:14
  • @Micky: Thank you for the 'How to...' article! I read it and decided against C#. Too much fuss, too little time to investigate. I've taken the C++ route and it's looking up. Specifically when I saw the effort required to get the component to be out-of-process using C# was putting me off. And on the DLL route I had issues when it came to implementing 'add/remove' for the delegates. – Frank Kaaijk Mar 24 '15 at 19:03
  • No problem. I agree with you there, COM in c++ is way easier and you have access to 20+ years of docko; samples; and wrappers from MFC to ATL. good luck! (actually it's only now that I notice you had the c++ tag on your question. Sorry about that) – MickyD Mar 24 '15 at 22:38

0 Answers0