Msbuild: 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.

[scyentyfyc]

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

[DMX-David-Cardinal]

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