Add support for COMReference items on .NET Core

[AaronRobinsonMSFT]

Steps to reproduce

The following COM sample doesn't build from the dotnet command. It only builds from within Visual Studio.

Command line

dotnet build ExcelDemo.csproj

Expected behavior

The project should build

Actual behavior

There is a failure to find the ResolveComReferences task.

See dotnet/core#2104
See dotnet/samples#487

[dotMorten]

Any update on this? I'd like to be able to build with COM references using a locally-installed .NET Core SDK without putting a dependency on VS2019.

[AaronRobinsonMSFT]

@dotMorten Just to set expectations and I will let @rainersigwald have the final say, but I am doubtful including full COM build support outside MSBuild will happen in the near future. There are too many dependencies between COM and Windows to reconcile in a reasonable way and since one of the primary goals of .NET Core SDK is to be as platform agnostic as possible, this tight coupling violates that principle. As I mentioned, @rainersigwald can comment better on how much work this would be and when it might occur, but I would be very surprised if this occurred in the .NET 3.0 timeframe.

[dasMulli]

Another ask: https://github.com/dotnet/cli/issues/12129

I've heard this from a few other customers as well - e.g. creating WinForms Apps that interface with COM components supplied by hardware vendors.

While using VS is workable, I think it should not be necessary.

There are too many dependencies between COM and Windows to reconcile in a reasonable way and since one of the primary goals of .NET Core SDK is to be as platform agnostic as possible, this tight coupling violates that principle

There are already platform-specific cases of tight coupling to windows, e.g. the logic to embed resources (Icons) into built .exe files for 3.0 GUI apps (source).
Being platform-specific for platform-specific use cases is fine or at least better than not having it work at all.

So I'd say it is not urgent but somewhat important in the long run. I'd like to see this work in .NET 5 or 6 when more businesses start to port their desktop apps to core.

[dotMorten]

I just went out of my way to try and avoid a com reference I needed. It was a lot of work, but I did it because I'm realizing it's not just the library you build that requires vs2019, but it's contagious and will affect all downstream projects that reference that library.

[ghost]

The dotnet CLI doesn't support it. I'm currently investigating a workaround using MSBuild for VS 2019 without the IDE, which I finally got to work with the following in my tasks.json file, using msbuild instead of dotnet

    "tasks": [
        {
            "label": "build",
            "type": "shell",
            "command": "msbuild",
            "args": [
                "/property:GenerateFullPaths=true",
                "/t:build",
                "/consoleloggerparameters:NoSummary"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "presentation": {
                "reveal": "silent"
            },
            "problemMatcher": "$msCompile"
        }
    ]

And in the csproj file, in my case, I needed to force the platform target to x86

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <PlatformTarget>x86</PlatformTarget>
  </PropertyGroup>

[JensNordenbro]

Moving a big application from .NET FW4.8 to .NET5 seems very feasible; this is one of the few roadblocks.
Sure, long term nobody wants COM-references but since the genie is out of the bottle with winforms and wpf not being cross platform but still included in .NET Core, fixing this is just more of the same!
Any news on this @AaronRobinsonMSFT.

[AaronRobinsonMSFT]

Any news on this @AaronRobinsonMSFT.

@JensNordenbro Not that I am aware of. Since support exists by using the .NET Framework version of MSBuild, there hasn't been the strong need to add support in the .NET Core SDK. Is using the .NET Framework MSBuild not a workable solution for your scenario?

[JensNordenbro]

I guess I could build the interop-assemblies using netfw msbuild and then consume them in .net5.

There seems to be some suggestions on improved COM-scenarios on .NET5 https://github.com/dotnet/runtime/blob/master/docs/design/features/COM-activation.md
I guess if that journey is embarked upon this scenarion should be included.

[jamers99]

@dotMorten a pretty clean workaround would seem to be using dotnet msbuild instead.
https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-msbuild

Edit: this does not resolve the problem
Unfortunately, this didn't fix my problem. Gave the same error.

[nick-beer]

We're also running into this as we port our large .NET Framework application. We've really liked the simplicity of dotnet build on our top level solution - it would be nice to be able to maintain that simplicity.

[janschreier]

I also tripped over the issue of dotnet build not supporting interop (MSB4803). I had the problem when using EF core's
dotnet ef dbcontext scaffold

would be nice to see some elegant solution to being able to speak to office components with .net 5

[ghost]

Seems very counter-intuitive for me that .NET 5.0 does not support elements of .NET Framework.

Can we hope to see COMReferences supported in .NET 5.0? Or do we have to keep hacking our way around it to use MSBuild?

[JensNordenbro]

Also add support for easy regfreecom

[wagenheimer]

I'm using DOT NET 6 and I also tripped over the issue of dotnet build not supporting interop (MSB4803). I had the problem when using EF core's
dotnet ef dbcontext scaffold

[calvin-charles]

and why dotnet pack also fail when I have COMreference and I pass '--no-build' command argument? I am not trying to build here, just pack?

[quicoli]

I just faced this now in my .NET 6.0 WPF application. Some context: my application needs to list the installed Windows Updates, for that I referenced the WUApi.dll. It works, the build works in my VS. Building in Azure pipeline using dotnet CLI it fails as you all already know. My workaround (probably you all have done the same):

• Created a .NET 6.0 Library project and encapsulated the reference to WUApi.dll and its call. This project I build with a MSBuild action.
• Removed from my main WPF application all references to the COM lib and referenced the built .NET 6 library, not the project itself.

Like I said, it's a workaround, it's not beautiful however it doesn't brake my main pipeline anymore.

[snechaev]

@quicoli just as a side note: you can just use tlbimp from net framework to generate PIA (interop dll) which will be usable in net 6 project with simple : tlbimp C:\Windows\System32\wuapi.dll. So, you will not need to write any wrapping class library code by hands.
Additional reference dotnet/runtime#27698 (comment)
Anyway, I still hope that full-featured support of COM-scenarios will be added in net.

[quicoli]

Hi Sergey Yes, I did that 😊 Sent from Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Sergey Nechaev ***@***.***> Sent: Friday, March 10, 2023 2:53:01 PM To: dotnet/msbuild ***@***.***> Cc: Paulo Quicoli ***@***.***>; Mention ***@***.***> Subject: Re: [dotnet/msbuild] Add support for COMReference items on .NET Core (#3986) @quicoli<https://github.com/quicoli> just as a side note: you can just use tlbimp from net framework to generate PIA (interop dll) which will be usable in net 6 project with simple : tlbimp C:\Windows\System32\wuapi.dll. So, you will not need to write any wrapping class library code by hands. Additional reference dotnet/runtime#27698 (comment)<dotnet/runtime#27698 (comment)> Anyway, I still hope that full-featured support of COM-scenarios will be added in net. — Reply to this email directly, view it on GitHub<#3986 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB775D5THB2NGL6EE2QG6JTW3M543ANCNFSM4GINSBJA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[mika76]

Adding my support for this request. I have a really old dll I can't escape

[Blinchik91]

Same here, still not fixed

[xDaevax]

and why dotnet pack also fail when I have COMreference and I pass '--no-build' command argument? I am not trying to build here, just pack?

Exactly this.

Due to https://learn.microsoft.com/en-us/visualstudio/msbuild/resolvecomreference-task?view=vs-2022#msb4803-error,
I use msbuild to build the project in a CI pipeline and this works fine, but then I can't create a NuGet package on the next step of the pipeline because the --no-build option of dotnet pack seems to be ignored, and the build is re-run.

As a workaround, I have updated our process to do the following:

msbuild -t:pack -p:PackageVersion=0.0.0.0 -p:Configuration=release

[Dolotboy]

In one of my project in WPF with .NET 6.0 I installed the following NuGet https://www.nuget.org/packages/Microsoft.Office.Interop.Word
It didn't work because it wasn't supported by .NET Core, So I found a work around to pass it by COMReference to make it work. When I launch the application, everything seems to be working, but when I try "dotnet build" I get an error saying: "The task "ResolveComReference" is not supported on the .NET Core version of MSBuild. Please use the .NET Framework version of MSBuild."

Would be nice to be able to build COMReference in .NET Core, since WPF a more largely used frame then WinForms...