I'm having trouble with something that should be brain-dead simple.
I am writing a COM client in .NET that will eventually talk to an old-style C++ COM interface when the server code is written. In the meantime, I've written an unsigned WPF .NET application and implemented the same interface - same IID, different ProgID and CLSID - so I'll have a harness I can test with. In theory, all I will need to do is switch my reference from one namespace to another and change the concrete class on the new statement and everything else will remain the same. I'm envisioning that when I CoCreate the CLSID, it will bring up the application with its GUI and my client can do its calls OLE Automation-style from there and see the effects on the screen.
Only that's not what's happening. In Add References for my client application, I see the typelib for my test harness in the COM list, but it refuses to let me add the reference because it detects that it is a .NET type library and expects a .NET reference. If I reference it as a project or browse to it as an EXE, it apparently loads the EXE in-process as if it were a DLL and uses the COM classes without actually activating it out of process.
I figured anything I did with a .NET COM application would work similarly to a C++ COM application. I'm not sure what my options are at this point. Am I facing a hard limitation or are there [attributes] that affect this behavior? (It has admittedly been a couple of years since I did really seriously detailed COM interop and I have an uneasy feeling that this is something really simple that I've since forgotten.)
Lupestro
