Microsoft.Windows.SDK.NET.Ref package not referenced when targeting .NET 5.0 in .NET 9.0 RC.2 SDK

[addabis]

Description

A simple project targeting e.g. net5.0-windows10.0.17763.0 will fail to resolve UWP types like Windows.Devices.Power.Battery because Microsoft.Windows.SDK.NET.Ref references are not passed to C# compiler.

error CS0246: The type or namespace name 'Windows' could not be found (are you missing a using directive or an assembly reference?)
error CS0246: The type or namespace name 'Battery' could not be found (are you missing a using directive or an assembly reference?)

This was working in RC.1.

Changing the target framework version to net6.0-windows10.0.17763.0 resolves this problem.

.NET 5.0 is not supported, but is this intentional?

To Reproduce

1. Create any .NET project targeting net5.0-windows10.0.17763.0 or any other version of Win SDK as long as the target framework is net5.0.
2. Reference any UWP type like Windows.Devices.Power.Battery.
3. dotnet build with .NET 9.0 RC2 (I tried with the 6th November nightly build and the behavior was the same).

[Sergio0694]

I think this is intentional and due to the fact that the lowest TFM supported by the Windows SDK projections that are available for the .NET 9 SDK (see #41936) are for .NET 6. So on .NET 5 it's likely just not adding any references, because none would be compatible. Not to mention that .NET 5 is EOL, like you mentioned. Don't have permissions in this repo, but this should just be closed as by design 🙂

[addabis]

Thanks. I hit that when our end-to-end tests started to fail after moving to RC.2, but since it's EOL, we can remove .NET 5.0-specific tests.

What I find a bit strange is that values in WindowsSdkSupportedTargetPlatformVersions still specify MinimumNETVersion for 10.0.17763 as 5.0 (in .NET 5 version of the item).

This means that Microsoft.Windows.SDK.NET.Ref is resolved to 10.0.17763.26, which still targets .NET 5.0.

This is in src/Installer/redist-installer/targets/GenerateBundledVersions.targets immediately below changes of WindowsSdkSupportedTargetPlatformVersion.

I'd expect this use case to somehow fail instead of going through the build without any message and failing in the compiler.

[Sergio0694]

cc. @manodasanW, you'll probably have more context on those specific versions?
But yeah @addabis in general I'd just recommend not spending time on this and just moving to .NET 8 🙂

[manodasanW]

This sounds like maybe it is a variant of #43795, but instead of WindowsSdkPackageVersion being specified to an older version which we fixed for the RTM build in that PR, the default version for .NET 5 which is locked doesn't have profiles in the package. We might need to consider doing the same thing in the PR for those scenarios.

[addabis]

@Sergio0694 The purpose of these tests is to test that we are able to load the assembly both as metadata and for execution in a supported runtime version (now .NET 8 and .NET 9). It would be nice if this is fixed.

There's always a user somewhere who uses some obscure NuGet package which did not get it's target framework updated.