Assembly reference issue with .NET Core 3

[Tragetaschen]

Describe the bug

I have reduced my main project structure to this: https://github.com/Tragetaschen/async-action-reproduction.

lib1 has an unused reference to System.Device.Gpio 1.0.0, an extension method to make CancellationTokens awaitable and an example class using that extension method.

lib2 has the same example class referencing the extension method from lib1.

When building lib2, there are four errors:

C.cs(10,57,10,68): error CS0012: The type 'IAsyncAction' is defined in an assembly that is not referenced. You must add a reference to assembly 'Windows, Version=255.255.255.255, Culture=neutral, PublicKeyToken=null, ContentType=WindowsRuntime'.
C.cs(10,57,10,68): error CS0012: The type 'IAsyncActionWithProgress<>' is defined in an assembly that is not referenced. You must add a reference to assembly 'Windows, Version=255.255.255.255, Culture=neutral, PublicKeyToken=null, ContentType=WindowsRuntime'.
C.cs(10,57,10,68): error CS0012: The type 'IAsyncOperation<>' is defined in an assembly that is not referenced. You must add a reference to assembly 'Windows, Version=255.255.255.255, Culture=neutral, PublicKeyToken=null, ContentType=WindowsRuntime'.
C.cs(10,57,10,68): error CS0012: The type 'IAsyncOperationWithProgress<,>' is defined in an assembly that is not referenced. You must add a reference to assembly 'Windows, Version=255.255.255.255, Culture=neutral, PublicKeyToken=null, ContentType=WindowsRuntime'.

Steps to reproduce
dotnet build in lib2

Ways to fix it
When you remove the package reference to System.Device.Gpio in lib1, lib2 compiles correctly.
When you remove the using System; from lib2's C, lib2 compiles correctly.

Interestingly, IntelliSense doesn't "gray out" the unused using System;, so it looks like the package reference pulls in something unwanted that then interferes with the lib2 build. At the same time, adding a using System; to lib1's C is grayed out as unused.

In this reduced sample, the using in lib2 can be removed, but in my main project it's certainly necessary.

Versions used

.NET Core SDK (reflecting any global.json):
 Version:   3.0.100
 Commit:    04339c3a26

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.18362
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.0.100\

Host (useful for support):
  Version: 3.0.0
  Commit:  7d57652f33

.NET Core SDKs installed:
  2.1.700 [C:\Program Files\dotnet\sdk]
  2.1.701 [C:\Program Files\dotnet\sdk]
  2.1.800-preview-009677 [C:\Program Files\dotnet\sdk]
  2.1.800-preview-009696 [C:\Program Files\dotnet\sdk]
  2.1.800 [C:\Program Files\dotnet\sdk]
  2.1.801 [C:\Program Files\dotnet\sdk]
  2.1.802 [C:\Program Files\dotnet\sdk]
  2.2.300 [C:\Program Files\dotnet\sdk]
  2.2.301 [C:\Program Files\dotnet\sdk]
  2.2.400-preview-010195 [C:\Program Files\dotnet\sdk]
  2.2.400-preview-010219 [C:\Program Files\dotnet\sdk]
  2.2.400 [C:\Program Files\dotnet\sdk]
  2.2.401 [C:\Program Files\dotnet\sdk]
  2.2.402 [C:\Program Files\dotnet\sdk]
  3.0.100-preview7-012821 [C:\Program Files\dotnet\sdk]
  3.0.100-preview8-013656 [C:\Program Files\dotnet\sdk]
  3.0.100 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

[joperezr]

Hello @Tragetaschen thanks for logging your issue. It looks like you are hitting the same issue that people were hitting here: https://github.com/dotnet/corefx/issues/41403 which is still getting root caused but the apparent issue seems to be when System.Runtime.WindowsRuntime gets brought into the closure of your build, which will now require Windows.winmd. We are still investigating why is it that removing the using statement fixes this problem, but for the meantime, I would advise to keep that line commented out. This may very well be a compiler problem. We can keep this issue open tracking the external issue for now, and once we have more info I will add it here.

[Tragetaschen]

That's ok. I'll follow the corefx issue. No need for extra tracking

[Tragetaschen]

I have migrated my application to the recent .NET 5 Preview 8 bits including S.D.Gpio and this issue still exists.
If I'm reading dotnet/runtime#30996 (which is the mentioned former corefx bug) correctly, this is caused by the System.Runtime.WindowsRuntime package being referenced and S.D.Gpio does exactly that.
For the libraries, the solution was to remove that package from the compatibility package, but here, it's a direct dependency still.

[joperezr]

That is correct we are aware of this and we need to change the reference to use the new csWinRT package instead but we can't do that just yet as we need csWinRT to fix an issue with their package regarding their strong name signature. We have another issue tracking that and it will get done before vNext.

[joperezr]

FWIW this is the issue where we are tracking updating this: #1091. Since we are already tracking it with another issue I'll go ahead and close this as a dupe but @Tragetaschen feel free to reopen if you think it is necessary