-
Notifications
You must be signed in to change notification settings - Fork 549
[dotnet] Fix the supported target platform versions we support. #19778
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[dotnet] Fix the supported target platform versions we support. #19778
Conversation
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
We've used to ignore the target platform version (the "17.0" part in "net8.0-ios17.0") since our initial .NET relaese - customers could specify any valid OS version between the minimum and maximum versions, and we'd completely ignore the value [1]. The purpose of the target platform version is to specify which bindings to choose: "net8.0-ios17.0" would mean that the developer wants packages that have bindings for iOS 17.0 (and earlier iOS versions, but not later iOS versions). So saying "net8.0-ios11.0" would technically mean that the developer would want our bindings for iOS 11.0 (and earlier iOS versions, but not later iOS versions). The problem is that we don't ship any such thing... we shipped iOS 17.0 bindings in .NET 8, and that's it, you can't choose to build with something that does *not* have bindings for iOS 17.0. This will change with multi-targeting: we'll support *some* matrix of bindings. For instance, we might want to support the OS version we shipped initial support in any given .NET release + the latest OS version. For example, we might want to support both of these: * net8.0-ios17.0 * net8.0-ios17.2 This means that the target platform version (17.0/17.2) can't keep staying ignored. The proper way to do this is to change the `SdkSupportedTargetPlatformVersion` item group to only include target platform version we actually support, but the downside of this approach is that it will make existing projects fail to compile, if they happened to include an invalid target platform version. So I've added a compatibility mode for .NET 8, where we show a warning (and tell the developer what to do) instead of an error, and then in .NET 9 we'll make the warning an error instead. This is accomplished by still lying in the `SdkSupportedTargetPlatformVersion` item group in .NET 8, and detect the condition in our own logic and report the error. For .NET 9 we can remove this logic, makes ure `SdkSupportedTargetPlatformVersion` is correct, and then .NET itself will show the proper error. Side note: Android is also making an invalid target platform version an error in .NET 9: dotnet/android#8569. [1]: We'd ignore the value for executable projects. It did have an effect for library projects that were packed into NuGets: the target platform version would be stored in the NuGet.
be4aeff to
a38d4eb
Compare
💻 [CI Build] Tests on macOS M1 - Mac Ventura (13.0) passed 💻✅ All tests on macOS M1 - Mac Ventura (13.0) passed. Pipeline on Agent |
💻 [CI Build] Tests on macOS M1 - Mac Big Sur (11.5) passed 💻✅ All tests on macOS M1 - Mac Big Sur (11.5) passed. Pipeline on Agent |
💻 [CI Build] Windows Integration Tests passed 💻✅ All Windows Integration Tests passed. Pipeline on Agent |
📚 [PR Build] Artifacts 📚Packages generatedView packagesPipeline on Agent |
✅ API diff for current PR / commitLegacy Xamarin (No breaking changes)
NET (empty diffs)
✅ API diff vs stableLegacy Xamarin (No breaking changes).NET (No breaking changes)ℹ️ Generator diffGenerator Diff: vsdrops (html) vsdrops (raw diff) gist (raw diff) - Please review changes) Pipeline on Agent |
🚀 [CI Build] Test results 🚀Test results✅ All tests passed on VSTS: simulator tests. 🎉 All 235 tests passed 🎉 Tests counts✅ bcl: All 69 tests passed. Html Report (VSDrops) Download Pipeline on Agent |
FIXME: need to do something about the
*_OR_GREATERsymbols.We've used to ignore the target platform version (the "17.0" part in "net8.0-ios17.0")
since our initial .NET relaese - customers could specify any valid OS version between
the minimum and maximum versions, and we'd completely ignore the value [1].
The purpose of the target platform version is to specify which bindings to choose:
"net8.0-ios17.0" would mean that the developer wants packages that have bindings
for iOS 17.0 (and earlier iOS versions, but not later iOS versions).
So saying "net8.0-ios11.0" would technically mean that the developer would want our
bindings for iOS 11.0 (and earlier iOS versions, but not later iOS versions). The
problem is that we don't ship any such thing... we shipped iOS 17.0 bindings in .NET
8, and that's it, you can't choose to build with something that does not have bindings
for iOS 17.0.
This will change with multi-targeting: we'll support some matrix of bindings. For
instance, we might want to support the OS version we shipped initial support in any
given .NET release + the latest OS version.
For example, we might want to support both of these:
This means that the target platform version (17.0/17.2) can't keep staying ignored.
The proper way to do this is to change the
SdkSupportedTargetPlatformVersionitemgroup to only include target platform version we actually support, but the downside
of this approach is that it will make existing projects fail to compile, if they
happened to include an invalid target platform version.
So I've added a compatibility mode for .NET 8, where we show a warning (and tell
the developer what to do) instead of an error, and then in .NET 9 we'll make the
warning an error instead. This is accomplished by still lying in the
SdkSupportedTargetPlatformVersionitem group in .NET 8, and detect the condition in our own logic and report the error.
For .NET 9 we can remove this logic, makes ure
SdkSupportedTargetPlatformVersionis correct, and then .NET itself will show the proper error.
Side note: Android is also making an invalid target platform version an error in
.NET 9: dotnet/android#8569.
[1]: We'd ignore the value for executable projects. It did have an effect for library
projects that were packed into NuGets: the target platform version would be stored
in the NuGet.