An UnresolvableAssemblyReference error in Microsoft.Toolkit.UWP.UI.Controls

[mandalorianbob]

Describe the bug

Whenever I build a 16299 UWP App referencing a 16299 UWP Library that's referencing Microsoft.Toolkit.UWP.UI.Controls in Release or in Debug w/ .NET Native, I get

MCG0023: MCG0023:UnresolvableAssemblyReference Unresolvable assembly reference 'Assembly(Name=Windows.Foundation.UniversalApiContract, Version=255.255.255.255, Culture=neutral, PublicKeyToken=null, ContentType=WindowsRuntime)' found. Please check the references in your build system. A reference is either missing or an assembly is missing an expected type.

• [ ] Is this bug a regression in the toolkit? If so, what toolkit version did you last see it work: Haven't used previous versions.

Steps to Reproduce

• [X ] Can this be reproduced in the Sample App? (Either in a sample as-is or with new XAML pasted in the editor.) If so, please provide custom XAML or steps to reproduce. If not, let us know why it can't be reproduced (e.g. more complex setup, environment, dependencies, etc...)

Steps to reproduce the behavior:

1. In newest Visual Studio (thus getting uwp package 6.2.10)
2. Create a new UWP App Project - set Target and Min to 16299.
3. Create a new UWP Library - set Target and Min to 16299. Add a nuget package pointing at Microsoft.Toolkit.Uwp.UI.Controls 6.1.1
4. Reference the Library from the UWP App Project
5. Check "Compile with .NET Native tool chain" in the UWP App Project.
6. Attempt to Build the App.

Expected behavior

Would prefer for it to build.

Environment

NuGet Package(s): 

Package Version(s): 

Windows 10 Build Number:
- [ ] Fall Creators Update (16299)
- [ ] April 2018 Update (17134)
- [ ] October 2018 Update (17763)
- [ ] May 2019 Update (18362)
- [X] May 2020 Update (19041)
- [ ] Insider Build (build number: )

App min and target version:
- [X] Fall Creators Update (16299)
- [ ] April 2018 Update (17134)
- [ ] October 2018 Update (17763)
- [ ] May 2019 Update (18362)
- [ ] May 2020 Update (19041)
- [ ] Insider Build (xxxxx)

Device form factor:
- [ ] Desktop
- [ ] Xbox
- [ ] Surface Hub
- [ ] IoT

Visual Studio 
- [ ] 2017 (version: )
- [X] 2019 (version: 16.7.7) 
- [ ] 2019 Preview (version: )

Additional context

This is a pretty severe blocking issue for me.

[ghost]

Hello mandalorianbob, thank you for opening an issue with us!

I have automatically added a "needs triage" label to help get things started. Our team will analyze and investigate the issue, and escalate it to the relevant team if possible. Other community members may also look into the issue and provide feedback 🙌

[Kyaa-dost]

@mandalorianbob Thanks for highlighting the issue. Will see if any dev can pick this up and investigate the root cause of this issue.

[michael-hawker]

@mandalorianbob have you reported through the Visual Studio reporting as well? We haven't heard of any similar reports elsewhere. A binlog could by helpful too.

@MichalS @TomMcDon seen anything like this before?

[mandalorianbob]

I did report it to the dotnet github, but since it only happens to your library I closed that one.

You can reproduce the behavior in 16.7.7. Here's a zip of the min repo. I'm going to try upgrading to 16.8 to see if it still happens. NetNativeMinRepo.zip

[michael-hawker]

@mandalorianbob thanks, let me know how 16.8 works; we've had issues building the toolkit for it, but hopefully consuming the toolkit works fine.

By reporting in Visual Studio, I meant using their 'report a problem' from the drop-down menu at the top-right of Visual Studio:

They can then direct to whichever teams need to be looped in as well (including any GitHub as well).

[mandalorianbob]

Alright. Unfortunately, upgrading to 16.8 didn't help.

I added the feedback here https://developercommunity2.visualstudio.com/t/unresolvableassemblyreference-in-windows-community/1252340

[michael-hawker]

Thanks @mandalorianbob, looks like they've directed it to an engineering team. If you haven't heard back by Monday, let me know, and we can start a thread with the .NET Native folks. In the meantime, we just shipped a new preview package, 7.0.0-preview4, would be curious if that exhibits the same problem for you. We haven't heard of any other folks having problems or seeing this on any of our systems, so going to be hard for us to track down.

[mandalorianbob]

Wait, so you aren't able to reproduce it with the min repro? I've had it fail both locally and on a build machine but if my coworkers can get it working maybe that's a potential workaround. I won't be able to check the preview bits till Monday, but I'll let you know.

[SvetBonev]

@mandalorianbob @michael-hawker

The issue is with the Microsoft.Toolkit.Uwp NuGet package. It targets Windows 10 version 10.0.16299, but it uses types that don't exist in that version of Windows, specifically, the RemoteSystemEnumerationCompletedEventArgs class. Per the documentation, it was introduced in 10.0.17134: https://docs.microsoft.com/en-us/uwp/api/windows.system.remotesystems.remotesystemenumerationcompletedeventargs?view=winrt-19041 However, it is being used here: https://github.com/windows-toolkit/WindowsCommunityToolkit/blob/9d90b624070e89f977c582fa304f289a23f9365a/Microsoft.Toolkit.Uwp/Helpers/RemoteDeviceHelper/RemoteDeviceHelper.cs

The NuGet package is incorrectly specifying that it is compatible with 10.0.16299:

.nuget\packages\microsoft.toolkit.uwp\6.1.1>dir /s/b .nuget\packages\microsoft.toolkit.uwp\6.1.1.nupkg.metadata .nuget\packages\microsoft.toolkit.uwp\6.1.1.signature.p7s .nuget\packages\microsoft.toolkit.uwp\6.1.1\lib .nuget\packages\microsoft.toolkit.uwp\6.1.1\microsoft.toolkit.uwp.6.1.1.nupkg .nuget\packages\microsoft.toolkit.uwp\6.1.1\microsoft.toolkit.uwp.6.1.1.nupkg.sha512 .nuget\packages\microsoft.toolkit.uwp\6.1.1\microsoft.toolkit.uwp.nuspec .nuget\packages\microsoft.toolkit.uwp\6.1.1\lib\uap10.0.16299 .nuget\packages\microsoft.toolkit.uwp\6.1.1\lib\uap10.0.16299\Microsoft.Toolkit.Uwp.dll .nuget\packages\microsoft.toolkit.uwp\6.1.1\lib\uap10.0.16299\Microsoft.Toolkit.Uwp.pdb .nuget\packages\microsoft.toolkit.uwp\6.1.1\lib\uap10.0.16299\Microsoft.Toolkit.Uwp.pri .nuget\packages\microsoft.toolkit.uwp\6.1.1\lib\uap10.0.16299\Microsoft.Toolkit.Uwp.xml

Depending on your application requirements, a potential workaround is to switch your application Target Platform version to 10.0.17134 or higher. If this is not an option, perhaps downgrading the Toolkit packages to the point before the abovementioned SDK type is used would work.

[mandalorianbob]

@michael-hawker So it looks like this problem still exists in 7.0 - can that helper be put behind an API flag?

[michael-hawker]

Thanks @SvetBonev for the detailed breakdown. That looks like a good culprit. Though surprised if it's not being used that it'd be a problem (even though we forgot a guard).

We probably missed this as we had upped the min of our sample app for gaze helpers a while back. Surprised it wasn't caught sooner, I was able to see the issue in the min repo @mandalorianbob after I installed the 16299 SDK.

However, we did update our min version to now be #3440, this shipped in 7.0.0-preview3 (and our most recent 4 as well of course).

Of course if you tried to build targeting 16299 with the new 7.0.0 package you should have gotten a different error, you need to target 17663 as the min.

@mandalorianbob can you confirm if you're unblocked now by using the new package and/or bumping your min target version? Thanks!

[mandalorianbob]

I can't bump my min target version.

I'll try switching to version 5.0 and seeing if that works.

[michael-hawker]

@mandalorianbob why can't you bump your min target version? If you look at our referenced issue, the majority of the market has moved off of 16299 and it's no longer in support.

[mandalorianbob]

Well the short answer is: I'm not in charge haha. But I'll forward the referenced data because it's come up recently.

Switching to 5.0 did work, and I'm unblocked.

Thanks!

[michael-hawker]

Going to close this issue now as it should be resolved moving forward in 7.0.0 with our updated mintarget.