dotnet
Change the default Windows SDK version
The default versions for SDKs have generally followed newer SDKs for that OS.
Here's the current version that is picked if no explicit version is specified:
| .NET version | Android | iOS | Mac Catalyst | macOS | tvOS | Tizen | Windows |
|---|---|---|---|---|---|---|---|
| .NET 8 | 34.0 | 17.2 | 17.2 | 14.2 | 17.1 | 10.0 | 7.0 |
| .NET 9 | 35.0 | 18.0 | 18.0 | 15.0 | 10.0 | 7.0 |
As you can see, everything but Android has pretty much been kept up to date, except the big stand-out: Windows.
If you target net9.0-windows you don't get access to any of the new SDKs that ships in Win10 and beyond. Instead you have to use these crazy SDK numbers like net9.0-windows10.0.19041.0 to get access to any basic Windows APIs.
Considering Windows 7 ended support over 5 years ago, Windows 8.1 over two years ago and Windows 10 is running on its last few months of support, it should be time to upgrade the default target SDK.
Is your feature request related to a problem? Please describe.
When building a default Windows app, like WPF, you get net9.0-windows with no default access to basic Windows SDK APIs. It also means several other nuget packages that you pull in that rely on these SDKs won't be used, and will often just fall back to the netstandard2.0 assemblies.
It also makes it oddly stand out when multi-targeting, like for instance in a new .NET MAUI app you'll see this:
<TargetFrameworks>net9.0-android;net9.0-ios;net9.0-maccatalyst;net9.0-windows10.0.19041.0</TargetFrameworks>
where android, ios and maccatalyst all give you access to very recent SDKs by default, Windows have this odd extra version attached to it. It's very inconsistent.
Describe the solution you'd like
net10.0-windows should at the very least be equivalent to net10.0-windows10.0.19041.0, but considering Win10 is out of support by the time .NET 10 ships, I would make more sense to just target the latest Win11 SDK version, and in the templates set the SupportedOSPlatformVersion to something lower like 19041 to at least keep some backwards compatibility.
The idea makes sense to me (we had a case just yesterday of someone else also hitting this). I think a good approach would be to have -windows just map to the minimum Windows SDK projections that we ship (eg. right now that'd be 17763). Those are published together with CsWinRT, and the .NET SDK has built-in support for both of those (we hardcode the exact list of supported SDK projections and their package versions in each .NET SDK update), so that'd also make it easier to bump that as needed, as older version slip out of support. It could just become part of the regular versioning for the Windows targeting pack.
cc. @manodasanW thoughts?
@Sergio0694 Why is Windows going for minimum, but other TFMs going for recent/maximum SDKs? I'd see more benefit in referencing a much later SDK, so if you for instance reference the WinAppSDK you get access to the new AI APIs, since those aren't included in the lower SDK versions in the nuget. I'd expect when I bump to the latest .NET Version, (like the upcoming .net 10) I get access to the new and shiny SDKs too.
as older version slip out of support
Just stating the obvious that most of them are out of support by the time .NET 10 ships.
Agree with @dotMorten that most SDK users expect the simple thing to be floating/up to date/etc when it comes to RIDs. If you need some lower baseline then it's on you to declare that in your projects.
The main issue with that approach is that it can cause issues for MSIX packaging, because it will set the default minimum target framework, which in turn influences what versions of Windows you can actually install the app at all. Given that currently -windows isn't really usable at all, as it targets Windows 7, to me making it target the baseline for UAP seems like a nice improvement 🙂
because it will set the default minimum target framework
This is also an "issue" on iOS and Android, but it isn't really an issue because the templates always set the minimum supported version anyway. Something that the templates ought to do regardless, because people blindly update the SDK version not realizing they are dropping min-versions when not set explicitly.
it can cause issues for MSIX packaging
This seems like a separate issue you need to address (perhaps by doing what I just suggested). Also consider most developers don't care about MSIX and shouldn't suffer because of it.
All the WinRT stuffs are really something additional to ship. How could WinForms/WPF applications say "I need Win32 only" and explicitly exclude them?
They'd just use the normal net8.0 TFM, and possibly set SupportedOSPlatformVersion. The whole point of -windows is just to pull in CsWinRT and the Windows SDK projections (which are purely WinRT APIs).
No, -windows also pulls in WinForms/WPF SDK. They can't be used in net8.0 TFM, ~unless explicitly bring in the FrameworkReference.~ Building support also requires the target files from -windows TFM.
You're right, I was thinking about the defaults. All the Windows SDK projections are always enabled when using -windows10.0.XXXXX.0, and you can't opt-out. Whereas enabling WPF, WindowsForms, or UWP XAML references, is opt-in via their respective properties.
I'm not sure if I 100% understood the conversation above. It sounded like having it default to 7 is too early, as it's out of support. So is updating it to the latest released version appropriate?
Having it always imply the minimum supported SDK we ship in the Windows SDK framework package seems reasonable to me, and it would not have any of the concerns with respect to minimum/target SDK in MSIX scenarios. To me it seems like it'd strictly be a net improvement over the current behavior, which is targeting an EOL version. This would just bump it to the nearest supported one.
Ah, ok. Lowest supported version. Is someone on tap for doing that? Trying to figure out how to triage this 🙂
Why should windows be different from the others and default to lowest when others default to highest at time of shipping? This issue is in part about consistence in the .net eco system.
Having it lowest would for instance mean the windows app sdk wouldn’t include many of the newer APIs for instance.
"the windows app sdk wouldn’t include many of the newer APIs for instance"
Why? WindowsAppSDK will keep shipping with its own minimum target SDK, like it does today, which is entirely independent from what the .NET SDK sets as default when no explicit OS version is specified. And templates would keep making sure to explicitly set it to match the version of WindowsAppSDK they're referencing. This change wouldn't result in any observable behavior change in any of those scenarios.
Unlike other platforms, WinRT isn't necessary to make an application on Windows. How would users opt-out it if causing troubles in tooling?
WindowsAppSDK will keep shipping with its own minimum target SDK, like it does today
You must target windows10.0.22621.0 if you want access to all the APIs. Take the latest 1.8experimental release, if you compare the APIs in the 17763 folder to the 22621 folder, a huge amount of APIs are added in that version that you won't be able to access with the older target.
I get that, but I don't see how that's in any way related to this proposal. You can keep having the explicit target TFM in your WindowsAppSDK, same as today, and the templates will also keep doing exactly that. The idea with this change should simply be to shift up the minimum default SDK to a supported one. Nothing else will change. If you have an explicit TFM set, nothing changes for you either. Basically there's no change for any WindowsAppSDK project at all.
