DCOM server and client both written in .NET

Question

I'm developing a DCOM server in .NET 4 (VS2010, C#). By itself, this is working fine.

Now, I also need to develop a .NET client for this DCOM server, but I am unable to add a reference to the TypeLib. Visual Studio will tell me the type library was exported from a .NET assembly and cannot be added as a reference.

Answers to this question suggests that I should be able to use TlbImp.exe to generate a wrapper assembly, but it will refuse to do so as well:

TlbImp : error TI1029 : Type library 'MyWrapper' was exported from a CLR assembly and cannot be re-imported as a CLR assembly.

I understand that from a purely .NET perspective, it may not make a lot of sense to use DCOM for this. However, the same server should also be accessible from non .NET applications.

I have tried converting my tlb to IDL and regenerating the tlb from that, but this does not fool Visual Studio.

Perhaps it is possible to modify the IDL slightly before regenerating, or is there some way to force the use of DCOM, even though both server and client are written in .NET?

Answer 1

I managed to get DCOM working, but I'm not certain if it can be done from a TypeLib. Modifying the IDL allowed me to import the type library, but it eventually failed during compilation (although this is treated as a warning by Visual Studio). It might still be possible to make even more modifications to the file, but I'm using a much easier solution.

All the interface definitions for the DCOM server were moved to a separate assembly, which is then referenced directly from the .NET client. This circumvents the importing problem.

Then, accessing the DCOM server is no different from what one might expect:

Guid clsId = new Guid("XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX");
Type type = Type.GetTypeFromCLSID(clsId);
IMyInterface comObject = (IMyInterface)Activator.CreateInstance(type);

Moving the interfaces to a separate assembly is not strictly necessary, but this minimizes the size of the shared assembly.