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.

[ericstj]

I took a look at this. Seems to be due to the old 5.0 packages not list Profile in their FrameworkList.xml data file.

Seems that the SDK started emitting this on the KnownFrameworkReference items it provides for locating targeting packs. Might be related to

sdk/src/Tasks/Microsoft.NET.Build.Tasks/CreateWindowsSdkKnownFrameworkReferences.cs

Line 109 in 2be64ff

CreateKnownFrameworkReference(windowsSdkPackageVersion, targetFrameworkVersion, targetPlatformVersion, profile: "Windows"),

but it looks like that attempts to address this? @dsplaisted might better be able to diagnose.

I was able to workaround it with

  <Target Name="_RemoveProfile" AfterTargets="AddWindowsSdkKnownFrameworkReferences">
    <!-- older Windows SDK packages didn't specify profile-->
    <ItemGroup>
      <KnownFrameworkReference>
        <Profile></Profile>
      </KnownFrameworkReference>
    </ItemGroup>
  </Target>

This workaround should probably be more carefully written to only apply to those older package versions of Microsoft.Windows.SDK.NET.Ref.* but hope this helps!

[ericstj]

And an alternate workaround for me was to add

  <ItemGroup>
    <FrameworkReference Include="Microsoft.Windows.SDK.NET.Ref" />
  </ItemGroup>

This works by using the non-profile framework name instead of the one with the profile that the SDK adds:

sdk/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Windows.props

Line 15 in 1b4e91b

<FrameworkReference Include="Microsoft.Windows.SDK.NET.Ref.Windows" IsImplicitlyDefined="true" Pack="false" PrivateAssets="All" />

[ericstj]

@marcpopMSFT - looks like this was a breaking change that shipped in the 9.0 SDK and can impact folks upgrading. Would be good to fix it.

[marcpopMSFT]

On the one hand, 5 is out of support and has been for a while now. On the other, we don't typically want to intentionally break things like this. I'll defer to @manodasanW and @Sergio0694 though as they own this scenario and CC @dsplaisted in case he has a better suggestion. Basically, if it's inexpensive, I think we can justify fixing it in 9.0.300 at least.