[dotnet] Add warning when the TargetPlatformVersion isn't supported #19901
Conversation
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. There was an somewhat related issue with the `SdkSupportedTargetPlatformVersion`, where we're now able to distinguish between old versions we no longer support and new versions that limits the valid values for TargetPlatformVersion (see 74d83ca). We've already taken advantage of this to properly annotate every version, even in .NET 8 (in a future service update), because the dotnet/sdk change required to understand the new annotations (and ignore old versions in the `SdkSupportedTargetPlatformVersion` item group) won't be shipped until .NET 9, so this won't be a breaking change in .NET 8. However, we'd still like to give customers a heads up that their project files need to change, so this PR adds a warning (that tells developers what to do), and then in .NET 9 we'll make the warning an error instead. 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.
💻 [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 |
📚 [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] Windows Integration Tests passed 💻✅ All Windows Integration Tests passed. Pipeline on Agent |
🚀 [CI Build] Test results 🚀Test results✅ All tests passed on VSTS: simulator tests. 🎉 All 166 tests passed 🎉 Tests counts✅ cecil: All 1 tests passed. Html Report (VSDrops) Download Pipeline on Agent |
Turns out this never really did what I assumed: dotnet/macios#19901
Turns out this never really did what I assumed: dotnet/macios#19901
Turns out this never really did what I assumed: dotnet/macios#19901
Turns out this never really did what I assumed: dotnet/macios#19901
5 participants
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.
There was an somewhat related issue with the
SdkSupportedTargetPlatformVersion,where we're now able to distinguish between old versions we no longer support and
new versions that limits the valid values for TargetPlatformVersion (see 74d83ca).
We've already taken advantage of this to properly annotate every version, even in
.NET 8 (in a future service update), because the dotnet/sdk change required to understand
the new annotations (and ignore old versions in the
SdkSupportedTargetPlatformVersionitem group) won't be shipped until .NET 9, so this won't be a breaking change in
.NET 8.
However, we'd still like to give customers a heads up that their project files need
to change, so this PR adds a warning (that tells developers what to do), and then
in .NET 9 we'll make the warning an error instead. 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.