Using net5.0-windows10.* target framework results in typeconflicts.

[trympet]

Describe the bug

A clear and concise description of what the bug is.
Targeting a windows-specific TFM in .NET 5, results in type conflicts between the UWP APIs in Microsoft.Windows.SDk.Contracts and the .NET SDK.

The following errors are observed in Visual Studio:

Error	NETSDK1130	Referencing a Windows Metadata component directly when targeting .NETCoreApp,Version=v5.0 is not supported. Use the C#/WinRT projection tool (https://aka.ms/cswinrt) or a provided projection for this target

Error	CS0433	The type 'XmlDocument' exists in both 'Microsoft.Windows.SDK.NET, Version=10.0.17763.10, Culture=neutral, PublicKeyToken=31bf3856ad364e35' and 'Windows.Foundation.UniversalApiContract, Version=7.0.0.0, Culture=neutral, PublicKeyToken=null, ContentType=WindowsRuntime'

• Is this bug a regression in the toolkit? If so, what toolkit version did you last see it work:

Steps to Reproduce

• 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...)

1. Create a .NET class library project
2. Change the target framework moniker to net5.0-windows10.0.17763.0
3. Add a reference to Microsoft.Toolkit.Uwp.Notifications.
4. Reference any of the following types:
   Windows.UI.Notifications.TileNotification, Windows.Data.Xml.Dom.XmlDocument.
   Example:
5. Build project

Expected behavior

A successful build with no type conflicts or compiler errors.

Screenshots

If applicable, add screenshots to help explain your problem.

Environment

Any windows-specific TFM.
NuGet Package(s): Microsoft.Toolkit.Uwp.Notifications

Package Version(s): 7.0.0-preview4, 6.1.1

Runtime: 5.0.100
OS build: 10.0.19041

App min and target version:

• Fall Creators Update (16299)
• April 2018 Update (17134)
• October 2018 Update (17763)
• May 2019 Update (18362)
• May 2020 Update (19041)
• Insider Build (xxxxx)

Hello trympet, 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 🙌

[michael-hawker]

Thanks for filing an issue @trympet. This is a duplicate of #3565 and a current known issue (so going to close this as we'll use the other one for tracking). We haven't been able to update the Notifications package yet to support .NET 5 due to a change in .NET 5 which effects how the package is built in-general.

FYI @andrewleader. You may want to look at the .NET 5 specific build separate from the build issue effecting the native winmd compilation. They should be independent problems with independent solutions.

[andrewleader]

Notes for myself: One part of the puzzle is that we shouldn't be including the SDK Contracts NuGet dependency when app is targeting -windows. There might be a subsequent problem about calling Process.GetCurrentProcess() that I'm currently debugging, but the app at least compiled with that first change.

[andrewleader]

Notes for myself: With targeting net5.0-windows10.0.17763.0, things all seem to be working!

Here's the web of app support we want to have...

At a high level, ideally:

• Windows apps/libraries should include the Show() methods
  • UWP apps
  • WPF .NET Framework
  • WPF .NET Core
  • WPF .NET 5
  • Console .NET Framework app
  • Console .NET Core app
  • Console .NET 5 app
• ASP.NET apps should NOT include the Show() methods

App	Should include Show()	Resolved TFM
UWP	Yes	uap10.0
WPF .NET Framework	Yes	net461
WPF .NET Core	Yes	netcoreapp3.1
Console .NET Framework	Yes	net461
Console .NET Core	Yes	netcoreapp3.1
net5.0-windows10.0.17763.0	Yes	net5.0-windows10.0.17763
net5.0-windows10.0.18632.0	Yes	net5.0-windows10.0.17763
net5.0-windows10.0.19041.0	Yes	net5.0-windows10.0.17763
net5.0-windows	Ideally yes, can tell them to update their targets though?	Idk?
net5.0 (console app, cross-plat)	Ideally yes?	Idk

Types of .NET 5

• net5.0 - Base type, cross-plat, includes ASP.NET, similar to .NET Standard, can NOT use with WPF/WinForms apps (must include -windows)
• net5.0-windows - Allows you to use WPF/WinForms
• net5.0-android (and iOS) - Allows you to use Android/iOS APIs

Ways .NET 5 Windows app developers can consume WinRT APIs...

• Switch target to net5.0-windows10.0.17763.0
• Or install Microsoft.Windows.SDK.Contracts NuGet package

If there's a console dev using simply net5.0, we want them to be able to use our Show() APIs. Changing their TF might be painful if they have other build steps dependent on the TF. So, for net5.0 and net5.0-windows we could include the NuGet Contracts package so that they can call Show() without any other modifications. For net5.0-windows10.0.17763.0, we don't need to include the NuGet package. However, that means ASP.NET web projects would also receive the Show() API, and Linux console apps would have it too. Less friction, however more code gets deployed and methods that don't necessarily work are present.

Alternatively, we could ask devs to change their TFM's. Then, plain net5.0 console apps would only have the builder APIs. Plain net5.0 class libraries would only have builder APIs. net5.0 web servers would only have builder APIs. More friction (devs can't just install and go), however only relevant code gets deployed and no methods that don't work.

Considering behavior we've witnessed with devs following setup instructions, they don't like to read carefully. They jump to the code and try to drop it into their app. Asking them to install a NuGet package is already burdensome. Asking them to additionally change their TF seems especially burdensome (plus they might then ponder how this affects other things, how this affects their build process, etc).

[michael-hawker]

@andrewleader you may want to look at the SupportedOSPlatformAttribute and UnsupportedOSPlatformAttribute and see if those can help (not sure if there's something special for ASP specifically though). This was the most helpful doc I could find on the subject.

This would provide the developer with guidance if they're trying to call Show on a platform where it's not supported. But I'm not sure what values are supported.