PackageReference to embeddable interop package *references* the assembly instead of *linking* it

[AArnott]

Per Embed Interop Types with PackageReference and #2365, the recommended pattern for packages that carry embeddable interop assemblies is to construct the package in both lib\ and embed\ folders.

Details about Problem

dotnet.exe --version (if appropriate): 5.0.100-rc.2.20479.15

Detailed repro steps so we can see the same problem

Given a NuGet package that contains an interop assembly under both lib and embed folders, add a PackageReference to it from a .NET SDK style project.

EXPECT

I expect the C# compiler to be invoked with the interop assembly specified with a /link:interop.dll switch.

ACTUAL

The C# compiler is invoked with /reference:interop.dll.
This is the same behavior as if the package didn't use the embed pattern at all.

I do observe that the project.assets.json file does recognize the embed folder:

      "EnvDTE90/16.9.30626.11111-pre": {
        "type": "package",
        "dependencies": {
          "EnvDTE80": "16.9.30626.11111-pre"
        },
        "compile": {
          "lib/net45/EnvDTE90.dll": {}
        },
        "runtime": {
          "lib/net45/EnvDTE90.dll": {}
        },
        "embed": {
          "embed/net45/EnvDTE90.dll": {}
        }
      },

But msbuild still references the dll instead of linking in.

Other suggested things

Verbose Logs

See msbuild.binlog.

Sample Project

sdktest.zip

[nkolev92]

Hey @AArnott,

Unfortunately the consumption side of PackageReference + embed is not implemented in either SDK or legacy build targets.

Related issue:

• Consume NuGet /embed assets group for interop type assemblies from NuGet package dotnet/sdk#2732
• Consume NuGet /embed assets group for interop type assemblies from NuGet package dotnet/NuGet.BuildTasks#69

cc @aortiz-msft @JonDouglas

This was a feature completed in early 2019, #2365 in NuGet 5.0, but while the NuGet side was done, the SDK/project-system parts were not.

We need to have someone drive the partner side to completion.

[AArnott]

Thanks. Would that be someone on the nuget team that should drive this? It seems like a significant amount of work has already been done on the nuget team, but if it isn't seen through to completion, I'm afraid the spec and closed issue make it look like it should work when it doesn't.

I can perhaps help ping folks to look at those issues, but I certainly have no expertise with the nuget targets/tasks that would be required to get this to work on the consumption side.

[nkolev92]

Would that be someone on the nuget team that should drive this?

Yes, I think so. The feature is NuGet driven, even if we don't own the codepaths in question.

It seems like a significant amount of work has already been done on the nuget team, but if it isn't seen through to completion, I'm afraid the spec and closed issue make it look like it should work when it doesn't.

I agree, that's very unfortunate.

I'll bring this up at our next triage meeting(Thursday, 10/29) and add the outcome here.

[nkolev92]

It's on my plate now. I'm gonna try to complete over the next 2 sprints in time for 16.9.