Runtime: Type Library Generation for .NET Core COM interop

[bclothier]

At the present, .NET Core does not support type library generation. However, we still can generate an arbitrary type library from an IDL file and compiling with MIDL. Would there be issues with using such .tlb file generated this way to describe a .NET Core DLL containing the COM types, assuming of course the description is correct?

[jeffschwMSFT]

@bclothier the current path for the scenario you describe is to use the .NET Framework 4.8 tlbimp to create the PIA. Or if you are using Visual Studio, you can use Embedded Interop Types with this registered tlb. Please let us know if you have any issue with this.

[bclothier]

@jeffschwMSFT you seem to be talking about importing COM types. I'm talking about exporting COM types. In a .NET FX assembly, that would have been done with either the regasm.exe or tlbexp.exe, assuming that the types within the assembly also have appropriate attributes decorated on the types.

My question deals with the fact that .NET Core no longer uses mscoree.dll to perform the marshaling of .NET types into COM. AIUI, the marshalling in .NET FX is possible because when we register the COM types, registry entries are made describing the category and additional entries to help the marshaler locate the assembly & type. If I'm not mistaken, none of that applies with the new COM marshaling model that .NET Core uses. What I'm asking is whether the new model is 100% compatible with specifications that a type library would expect from an implementation DLL because as I noted, we can build a type library without any implementation using the midl compiler. Whether it will work with the .NET Core DLL out of the box is what I want to know.

[jeffschwMSFT]

.NET Core also supports .NET COM servers (so the export scenario). If you build a .NET Core COM server, you can register via regsvr32 (similar to native COM). The tlbexp scenario should be possible. What is the scenario you are looking for when using the tlb?

cc @AaronRobinsonMSFT @jkoritzinsky

[bclothier]

I'm primarily interested in knowing whether it's safe to write a IDL file and compile the type library from the midl.exe compiler to describe the COM types within the .NET Core DLL or whether there would be limitations because I did not see that documented. The fact that one can use regsvr32 implies that it should be compatible with a type library built in this manner without using any .NET specific tools such as tlbexp.exe.

[jeffschwMSFT]

It is our expectation that this scenario should work, but there are complications and rough edges. The .NET Framework tlbexp loads the assembly and will produce the tlb. For the actual COM interface, this should be just fine. But you can imagine there are features/types introduced in .NET Core that .NET Framework may not be able to load.
We understand that a full .NET Core tlbexp story is not yet in place, so please do give it a try and provide us feedback. With that we can better prioritize the scenario.

[jkoritzinsky]

@bclothier as @jeffschwMSFT says, tlbexp will have some rough edges. However, manually writing an IDL file to describe COM types in your .NET Core DLL should work as long as it is accurate.

[bclothier]

Thanks! That's a great news.

Just as a FYI - we currently use a IDL file for our project to work around some limitations in the .NET FX's attributes, mainly the inability to mark types as restricted and to provide a more friendly names for the enumeration members as tlbexp/regasm's default is to name them EnumName_MemberName which is usually a mouthful and not really standard in classic VB's parlence.

[kgreed]

I am keen to learn how to create a TLB file. Is there any step by step guide? I asked also here