Runtime: COMImport in .NETCore

[ericstj]

What is the plan for supporting COM import in .NETCore?

Currently we support all the attributes necessary for the COM interop scenario and it seems to work at runtime, but not the tools.

Here's what I've found:

1. TypeLibConverter type is not implemented/exposed.
2. TLBImp does not have a .NETCore version (though you can use the deskstop generated assemblies in .NETCore, or even disassemble those and reassemble on .NETCore).
3. ResolveComReference doesn't work on .NETCore when building with dotnet.exe but does work when building with msbuild.exe:
4. error MSB4062: The "Microsoft.Build.Tasks.ResolveComReference" task could not be loaded from the assembly Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
5. Add COM Reference from the IDE doesn't show up when project is targeting 'netcoreapp'.

I've seen a handful of folks hit 1 & 2 so far and are working around it by hacking up a build process with the desktop tools, but we could do better.

/cc @jeffschwMSFT

[jeffschwMSFT]

We are working through this scenario and will have a plan for .NET Core 3.0.

cc @AaronRobinsonMSFT

[0xd4d]

Also type equivalence is disabled in .NET Core but supported by .NET Framework. Will that be supported?

[jeffschwMSFT]

Just this morning @AaronRobinsonMSFT and I were talking about. Do you have a particular scenario in mind?

[0xd4d]

I don't need it but thought I'd mention it since it's COM related.

If you don't have access to the source code of some DLL that has embedded interop types it could make porting to .NET Core 3.0 more difficult. I don't know if this is common though.

[AaronRobinsonMSFT]

cc @richlander

[hmartinez82]

Glad to hear that @jeffschwMSFT . Manually adding tlbimp'ed DLLs to my core app works.
Is there a plan to support nuget packages that only contain tlbimp'ed DLLs or TLBs ? Right now I keep getting error NU1202 even when those DLLs are in \lib\netstandard2.0\ folder tree. That would go hand in hand with issue 2 above.

[jeffschwMSFT]

Nuget distribution is on our list of things to consider.

[ericstj]

@hernancmartinez that should work today, these DLLs aren't really any different from regular .NET dlls from NuGet's perspective. Can you share your package with me?

[weltkante]

Anything to share yet for the plans on TypeLibConverter? I know the C++ implementation has been removed from coreclr when cleaning up unused desktop features. Are you considering bringing back the code into coreclr, or as a separate tool/library, or as some new implementation, or not bringing it back at all?

I'm interested here because I've previously made attempts on a C# port of the typelib generation code so it can run over System.Reflection.Metadata without having to load the assembly into the CLR, but unfortunately I didn't get into a usable state because the C++ code did a lot of poking around in CLR/JIT runtime data structures I'm not familiar with.

[AaronRobinsonMSFT]

@weltkante This is a question I am actively working on. See dotnet/coreclr#21265 for part of this work.

At the moment our feeling is that TypeLibConverter will not be brought to .NET Core. This is relatively easy to defend in the TlbImp case since using the .NET Framework TlbImp will create a PIA that is usable in .NET Core - if you know of a scenario where the .NET Framework TlbImp doesn't work, please share!

The TlbExp story is far more complicated. The fact that TlbExp was built into the .NET Framework runtime - whereas TlbImp was pure C# - makes a solution much more difficult and costly. The plan of record is rather simple and it goes like this... community driven 😄 If this is really important our expectation is that the community will make a lot of noise and at that point we will look at what can be done. This isn't a very satisfying answer for developers that own scenarios where there is a need and if that number is small it may never get realized - at least in the official .NET project. This basically comes down to cost and the cost to resurrect TlbExp is very high which is why we are saying "not supported" right now, but that can change.

[weltkante]

Thanks for the answer 👍

I prefer to have TLB generation externally and not baked into coreclr, so its fine with me that the code is not coming back. However TLBs still are an important requirement for porting to .NET Core 3 because we need them for cross thread/cross process calls. If there's not going to be an official version I'll probably take another look at my porting project and put it on github so people can try help to figure out the parts I don't know, if there is any interest.

As far as TlbImp is concerned I've never used it, I only use official PIAs (Office and VS) or 3rd party projects (SharpDX) and for everything else I prefer manually typing in the interface definitions. There's a lot of room for variations and I prefer to have control over how the interface looks like, when to use IntPtr and PreserveSig etc.

[danmosemsft]

@AaronRobinsonMSFT @jeffschwMSFT is there anything here to track in CoreFX? Sounds like this is all already underway and tracked by you?

[AaronRobinsonMSFT]

@danmosemsft and @ericstj Basically all of these questions have 3.0 answers.

(1) is those APIs aren't supported in .NET Core and we will need a very strong reason to implement them.

(2) is somewhat related to (1), but the guidance is planned to be - "Use TlbImp from .NET Framework". We are waiting to hear of a case where it doesn't work.

(3) This has been mitigated with https://github.com/Microsoft/msbuild/pull/3987

(4) Filed at https://github.com/dotnet/project-system/issues/4355

Unless there is strong pushback with these answers, this issue can be closed.

[danmosemsft]

Thanks @AaronRobinsonMSFT

[hmartinez82]

@AaronRobinsonMSFT @ericstj I tried again, but as of right now, I can't get "Use TlbImp from .NET Framework" to work.

We have a pure C++ IDL project, compiled with v141, that creates TLBs and as a post build event we call tlbimp, version 4.6.1055.0, to create the DLLs.

We later create a nuget package that contains only the DLLs under \lib\netstandard1.2.
This package correctly installs in a .Net Framework 4.5.2 project, but fails to install in a .Net Core 2.1 or 3.0 project with error NU1202.

As previously mentioned, copying these DLLs by hand and adding them as reference does work in the .Net Core projects.

[AaronRobinsonMSFT]

@hernancmartinez Just for clarification using TlbImp produces DLLs that are usable in .NET Core, but the issue being faced is consumption in a NuGet package right?

[ericstj]

.NETCore2.1 and .NETCore3.0 are both compatible with netstandard1.2: you should not be seeing NU1202.

[hmartinez82]

@AaronRobinsonMSFT Correct, this is only a problem with the nuget package. I'm going to ask permission to send the nuget. Since it's just public TLBs I don't think it will be a problem. This is the nuspec file:

<?xml version="1.0"?>
<package>
  <metadata>
     ...
  </metadata>
  <files>
    <file src="bin\x64\Release\AEControllerCOMLib.dll" target="lib\netstandard1.2\x64\AEControllerCOMLib.dll" />
    <file src="bin\Win32\Release\AEControllerCOMLib.dll" target="lib\netstandard1.2\x86\AEControllerCOMLib.dll" />
  </files>
</package>

[hmartinez82]

After some more tinkering I found out the issue! The DLLs must not be in \lib\netstandard1.2\{arch}, but in \lib\netstandard1.2 instead ! Surprisingly the former installs in .Net Framework projects without issues.

[clairernovotny]

If you have x86/x64 specific binaries, then the way to include both is to use the runtimes node:

\runtimes\win-x86\lib\netstandard1.2\foo.dll and
\runtimes\win-x64\lib\netstandard1.2\foo.dll

Note that this only works for PackageReference usage and not with packages.config.

[ericstj]

And you also must provide a reference assembly under lib or ref for those to be exposed to the compiler if you need to expose those types publicly to consumers.