New .NET 5 Windows TFM’s explained

Andrew Leader
2 min readDec 10, 2020

--

If you’re writing a WPF app and want to use .NET 5 plus access the Windows 10 WinRT APIs (like geolocation, etc), there’s a new way of accessing the APIs!

Previously, you would reference the Microsoft.Windows.SDK.Contracts NuGet package to gain access to the WinRT APIs.

With .NET 5, all you have to do is include your target Windows version in your target framework within your .csproj.

<Project Sdk="Microsoft.NET.Sdk">  <PropertyGroup>    <OutputType>WinExe</OutputType>    <TargetFramework>net5.0-windows10.0.19041.0</TargetFramework>    <UseWPF>true</UseWPF>  </PropertyGroup>

The version specified in your target framework is the target version of the Windows APIs. This is NOT the minimum version of Windows. With the above, even people still running the very first version of Windows 10 can install my app.

So, if you need some newer APIs, you can still use them while still supporting older versions. At runtime, you’ll need to use ApiInformation to check whether the APIs are present.

List of Target Frameworks

I couldn’t find a list of target frameworks anywhere, so here they are…

  • net5.0-windows10.0.17763.0
  • net5.0-windows10.0.18362.0
  • net5.0-windows10.0.19041.0

Building NuGet packages

What if you want to distribute a NuGet package that uses the Windows SDKs?

The TFM sorta acts as a “min version”, although NuGet will allow you to install higher versions into your app too.

Here’s what happens depending on the TFM used in your NuGet package…

net5.0-windows10.0.17763 packages can be installed by…

  • net5.0-windows10.0.17763.0 apps
  • net5.0-windows10.0.18362.0 apps
  • net5.0-windows10.0.19041.0 apps

net5.0-windows10.0.19041 packages can be installed by…

  • net5.0-windows10.0.17763.0 apps (supposedly a warning appears but I didn’t see it)
  • net5.0-windows10.0.18362.0 apps (supposedly a warning appears but I didn’t see it)
  • net5.0-windows10.0.19041.0 apps

However, if you have multiple targets in your package, targeting a version too high might result in a different version being picked. For example, if we have this NuGet package…

What happens when we install it on a net5.0-windows10.0.17763.0 app? You’d think it’d pick the net5.0-windows10.0.19041 bundle… however, NuGet decides a “better fit” would be .NET Core 3.1.

How to build a NuGet package that supports the most apps?

What if you want to build a NuGet package that, itself, targets the 19041 SDK, however you still want it to be able to be used by apps that are still only targeting 17763?

Seems like you’re supposed to be able to use <SupportedOSPlatformVersion> as spec’d here, however it doesn’t work.

--

--

Andrew Leader

Program manager on Windows Dev Platform, dev of Power Planner, rock climbing/hiking/skiing enthusiast, mountain rescue