microsoft / WindowsAppSDK

The Windows App SDK empowers all Windows desktop apps with modern Windows UI, APIs, and platform features, including back-compat support, shipped via NuGet.
https://docs.microsoft.com/windows/apps/windows-app-sdk/
MIT License
3.85k stars 323 forks source link

NETSDK1206 warning for .NET 8 #4597

Closed smaillet closed 1 month ago

smaillet commented 3 months ago

Describe the bug

When targeting .NET 8 I get the following waning:

C:\Program Files\dotnet\sdk\8.0.303\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(284,5): warning NETSDK1206: Found version-specific or distribution-specific runtime identifier(s): win10-arm64, win10-x64, win10-x86. Affected libraries: Microsoft.WindowsAppSDK. In .NET 8.0 and higher, assets for version-specific and distribution-specific runtime identifiers will not be found by default. See https://aka.ms/dotnet/rid-usage for details.

Only way to get around this is if the Windows App SDK is updated to support the new RID scheme for .NET. (Yeah, another one... [sigh...])

Steps to reproduce the bug

Expected behavior

No warning and library works properly with .NET 8

Screenshots

No response

NuGet package version

Windows App SDK 1.5.5: 1.5.240627000

Packaging type

Unpackaged

Windows version

Windows 10 version 22H2 (19045, 2022 Update)

IDE

Visual Studio 2022

Additional context

Microsoft official docs have a "workaround" that simply silences the warning - but that is a dangerous thing as it hides ALL other cases of this error and may not even be valid for this one. (One needs to test to be sure there isn't an issue with not locating assets and it isn't obvious what specific things testing should focus on.

whiskhub commented 3 months ago

Can reproduce with following steps:

Hint: This even occurs if you "hardcode" <RuntimeIdentifiers>win-x86;win-x64;win-arm64</RuntimeIdentifiers> without any target condition. There must be some reference to win10-* left in the Windows App SDK files itself.

whiskhub commented 2 months ago

This seems to be fixed in WinAppSDK 1.6 stable.