.NET 9 RC manifests were not updated to reference the .NET 8 iOS 18 / macOS 15 workloads

[filipnavara]

Apple platform

iOS, macOS, Mac Catalyst, tvOS

Framework version

net8.0-, net9.0-

Affected platform version

.NET 9 RC1

Description

Last week iOS workload on .NET 8 was updated to support iOS 18 / Xcode 16. The unfortunate consequence of that is that net8.0-ios now implicitly means net8.0-ios18.0 when you recompile with this version. The workload manifest for .NET 9 RC 1 was not updated though, so if you have both SDKs installed, then compiling with .NET 9 SDK means that net8.0-ios still means net8.0-ios17.5 and that the iOS 18 workloads are not used even if they are installed.

CommunityToolkit.Maui update was released last week. It was recompiled with the latest .NET 8 SDK at that time, so the NuGet was produced with net8.0-ios18.0 assets. Now if you try to use it with .NET 9 SDK installed it will fail to compile (NativeAOT) or run (MonoVM) because it will pick the net8.0 asset instead of the net8.0-ios18.0 asset since it only understands net8.0-ios17.5 and thus does a fallback...

Steps to Reproduce

1. Create app with net8.0-ios18.0 TFM.
2. Try to build the app with .NET 9 RC 1 SDK on the machine.

Did you find any workaround?

No response

Relevant log output

No response

[rolfbjarne]

This will be fixed with .NET 9 RC 2, which will contain Xcode 16 support as well.

Unfortunately the .NET 9 releases and not coordinated with .NET 8 service releases, so it's hard to make everything line up properly without breakages like this in between :/

Eventually I believe CommunityToolkit.Maui will switch to targeting a fixed OS versions (so they'll specifically build for net9.0-ios18.0, in which case this won't happen again next year with iOS 19).

[filipnavara]

I realize that it will be self-fixed with .NET 9 RC 2 release. There are few thing that worry me though.

Firstly, I had an understanding that the implicit SDK version is pinned with each version of .NET TFM, ie. every version of .NET 8 SDK would interpret net8.0-iosX.Y the same, where X.Y would be fixed for all servicing releases. This principle has been violated and I would appreciate an official stance and documentation on it.

Secondly, this broke pretty much everyone on our team since we all have .NET 9 RC SDKs installed, either explicitly or as a side effect of having side-by-side installation of Visual Studio Preview.

Thirdly, all our DevOps pipelines also immediately ingest the new .NET SDK and workload versions. This release happened out of the regular monthly schedule (second Tuesday of a month) which caused a two week delay until .NET 9 RC2 lands.

[filipnavara]

Also, note that I am explicitly not asking for update of .NET 9 workloads, just the manifest which points to .NET 8 workloads that were already released. It would be nice to make sure that this doesn’t happen in future since I already wasted a day on it.

[rolfbjarne]

Firstly, I had an understanding that the implicit SDK version is pinned with each version of .NET TFM, ie. every version of .NET 8 SDK would interpret net8.0-iosX.Y the same, where X.Y would be fixed for all servicing releases. This principle has been violated and I would appreciate an official stance and documentation on it.

Yes, this is a really ugly problem for us, because not upgrading means that everybody who got their Xcode auto-updated overnight is broken (and this happens to a lot of people every year).

An additional problem this year is that if you upgrade to macOS Sequoia, you'd be stuck, because macOS 15.4 doesn't work on Sequoia :/

You can see for yourself the havoc we had until we released Xcode 16 support (sorted by number of comments, it's 3rd on our all time list): #20802

Now, you could argue that we should still keep the original default for the lifetime of .NET X (so net8.0-ios17.0 for .NET 8), but you'd have to update that manually if you want to use a newer Xcode, which after a year pretty much everybody would have to do. At that time very few would be using the default, and the value of having a default is gone.

For these reasons we've decided to not follow what the rest of .NET does.

Also, note that I am explicitly not asking for update of .NET 9 workloads, just the manifest which points to .NET 8 workloads that were already released.

This command should get you the previous version:

dotnet workload install <workload id(s)> --version 8.0.402

I've also just added this to our release notes.

[filipnavara]

I understand the unfortunate situation that happened with Xcode / macOS Sequoia and so on. I'm not mad about the out of band update per se but it caused some unintended consequences and I would like to make sure that doesn't happen again.

Now, you could argue that we should still keep the original default for the lifetime of .NET X (so net8.0-ios17.0 for .NET 8), but you'd have to update that manually if you want to use a newer Xcode, which after a year pretty much everybody would have to do. At that time very few would be using the default, and the value of having a default is gone.

I am still arguing for that. or rather, any general solution that does any of the following:

• enforces stable inferred TFMs for libraries,
• enforces using netX.Y-iosV.W format of TFM for NuGet packed libraries, or,
• updates workload manifests for ALL supported .NET SDK versions to be consistent between each other (.NET 9 RC 1 is supported with go-live license)

The unintended consequence of bumping to net8.0-ios18.0 is not a problem for end user apps but it's absolutely a problem for libraries and NuGets. What happened here is that CommunityToolkit.Maui got the workload update in their CI pipeline and they released an updated NuGet. Without any intervention on their side the package now contains net8.0-ios18.0 assets (and ONLY those, not anything for net8.0-ios17.x). They don't require newer SDK functionality and it's managed only code that has no dependency on the new iOS SDK version. This is exacerbated by the fact that NuGet doesn't give any warning at all about using the net8.0 fallback asset instead of the net8.0-ios[TOONEW] one.

This command should get you the previous version:

That's too late. The problem is not the workload versions on our machines. The issue is that there are now NuGets in the wild that only contain net8.0-ios18.0 assets where they previously had net8.0-ios17.X assets. The ship has sailed on that and no amount of workload reverts on our machines will solve that.

We didn't notice the problem until 3 days later because our CI machines are configured to only install .NET 8 SDKs. They got the updated workloads and compiled just fine. Dependabot sent an alert about new CommunityToolkit.Maui NuGet version, it passed the CI and it got ingested.

It only failed on the dev machines today because most of our devs had the .NET 9 SDK installed. The .NET 8 SDK on the very same machines had the same workload updates as the CI machines. They are just not used unless you force .NET 8 SDK by global.json or similar approach.

[dalexsoto]

The unintended consequence of bumping to net8.0-ios18.0 is not a problem for end user apps but it's absolutely a problem for libraries and NuGets. What happened here is that CommunityToolkit.Maui got the workload update in their CI pipeline and they released an updated NuGet. Without any intervention on their side the package now contains net8.0-ios18.0 assets (and ONLY those, not anything for net8.0-ios17.x). They don't require newer SDK functionality and it's managed only code that has no dependency on the new iOS SDK version. This is exacerbated by the fact that NuGet doesn't give any warning at all about using the net8.0 fallback asset instead of the net8.0-ios[TOONEW] one.

Library authors probably need to be using net8.0-ios17.0 (instead of plain net8.0-ios) always in their TFMs and only bump to newer on .NET vNext ie. net9.0-18.0 so it is explicit and do not get broken by vNext workload update, I would prefer to pass the price to library authors to know how to do this than to every single app user knowing why they need the iOS version in their TFM to use a newer Xcode SDK.

[filipnavara]

I would prefer to pass the price to library authors to know how to do this

...and I am generally fine with that if there's some enforcement for this. The original netX.Y-os[V.W] design proposal had a bound V.W pair to the X.Y version number that doesn't change in servicing (AFAIK). If you break that assumption then you need to somehow tell the library authors that they need to do something else. There's no warning or other enforcement to use the long version for libraries, and so they unknowingly bump the TFM versions by just running the default CI pipeline and no explicit change.

[last-Programmer]

I had a crash using community toolkit with .net 9 rc when setting the statusbar color and style and i was getting the error Platform not supported. This explains the reason why i was getting the error. As workaround since i was uisng only this from community toolkit i copied the statusbar sources to my project.

[rolfbjarne]

I would prefer to pass the price to library authors to know how to do this

...and I am generally fine with that if there's some enforcement for this. The original netX.Y-os[V.W] design proposal had a bound V.W pair to the X.Y version number that doesn't change in servicing (AFAIK). If you break that assumption then you need to somehow tell the library authors that they need to do something else. There's no warning or other enforcement to use the long version for libraries, and so they unknowingly bump the TFM versions by just running the default CI pipeline and no explicit change.

I'm looking into whether we can have a different default between executable projects and library projects, I believe that would solve the problem you ran into.

[bijington]

As a maintainer of the Community Toolkit is there anything that we can do today in order to stop seeing this issue? This isn't actually the first time it has happened. It is great to finally know what the cause was and special thanks to @filipnavara for diagnosing it.

I have tried changing the TFM to net8.0-17.0 in this PR CommunityToolkit/Maui#2243 but that is failing to build making me question whether I am missing something

[filipnavara]

I have tried changing the TFM to net8.0-17.0

The proper name would be net8.0-ios17.0.

[bijington]

I have tried changing the TFM to net8.0-17.0

The proper name would be net8.0-ios17.0.

Sorry I mistyped in my previous comment I did use net8.0-ios17.0 --> https://github.com/CommunityToolkit/Maui/pull/2243/files