-1

Following the guidelines from Turn a simple C# DLL into a COM interop component, I've created a tiny C# COM server:

[ComVisible(true)]
[InterfaceType(ComInterfaceType.InterfaceIsDual)]
[Guid("410B8E64-27DB-40BD-8847-FC3A0E96147D")]
public interface IFactory
{
    int PlusOne(int i);
}

[ComVisible(true)]
[ClassInterface(ClassInterfaceType.None)]
[Guid("207FC3AB-0EFB-459A-B222-41E281F044F9")]
public class Factory : IFactory
{
    public int PlusOne(int i) => i + 1;
}

I've created as well a client C# project which just references this COM server. And here is the problem: COM reference is not working, in Dependencies->COM section it is marked with a yellow warning triangle without any further explanations, and types from the COM component are not available in the client code. These projects are published on github. Note, that COM server atomaticly registers itself (regasm) upon rebuild of the project. I'll appreciate any help. The answers like "you can reference your server as a .net assembly directly without need to use COM", are not acceptable, as this is just a test of a part of a bigger workflow which we need to establish.

Alex B.
  • 348
  • 2
  • 12
  • It looks like the reason is explained by a compiler warning, which I overlooked first, "Warning MSB3290 Failed to create the wrapper assembly for type library .... Type library 'x86TestComServer' was exported from a CLR assembly and cannot be re-imported as a CLR assembly." So, Microsoft explicitly prohibits that, even if I'm going to host ComServer on Com_Surrogate afterwards and not load it as inproc. – Alex B. Oct 13 '21 at 10:56
  • For referencing a .NET object, event if this .NET object is a COM object, you must reference the .NET object as a regular .NET reference, not as a COM reference. – Simon Mourier Oct 13 '21 at 18:15
  • Yes, I know that. This prevents running .Net COM server in COM surrogate process which is our goal, as the server must be 32-bit, while the client is 64 bit. – Alex B. Oct 19 '21 at 13:24
  • By the way, what's wrong with my post, why it was voted down? Clearly stated problem, with code example, no good explanation on the Internet... Strange. Would be nice to understand the reasoning of the one who "-"-ed. – Alex B. Oct 19 '21 at 13:34
  • 1
    There's no mention of out-of-process, surrogate, 32 vs 64bit, or anything like that in your question. You say you know you can't reference .NET from .NET, but that's what you're trying to do in your question, so you should explain what you're trying to do more precisely. PS: FWIW I didn't downvoted – Simon Mourier Oct 19 '21 at 13:56
  • @SimonMourier, what you say makes sense. I just wanted to be as concise as possible, as all this additional info (x86-x64 etc) does not change the essence of the problem. – Alex B. Oct 19 '21 at 14:27

1 Answers1

0

The reason for inactive reference was found after examining compiler warnings and it was in explicit prohibition for .Net client to reference .Net COM server. There is such a possibility, though, as described here: https://learn.microsoft.com/en-us/samples/dotnet/samples/out-of-process-com-server/

I've checked, and this really worked fine, and it became possible for a .Net client to reference a Server.Contract.tlb from the example. As a bonus, Microsoft added the possibility for .Net Core targeting COM server to be loaded into COM Surrogate or to be run as out-of-process (standalone exe). This works indeed just for netcoreapp3.1 server, as when I've changed target framework to net48, no DllServer.comhost.dll (containing, most probably, proxy/stub code) was autogenerated as it did for netcoreapp3.1, the project property <EnableComHosting>true</EnableComHosting> obviously didn't have any effect.

Alex B.
  • 348
  • 2
  • 12