This isn't very user friendly:
ILLink : unknown error IL7000: An error occurred while executing the custom linker steps. Please review the build log for more information.
ILLINK : error MT0073: Microsoft.iOS 18.0.8337 does not support a deployment target of 10.0 for iOS (the minimum is 11.0). Please select a newer deployment target in your project's Info.plist or change the SupportedOSPlatformVersion property in your project file.
ILLINK : error MT2301: The linker step 'Setup' failed during processing: Microsoft.iOS 18.0.8337 does not support a deployment target of 10.0 for iOS (the minimum is 11.0). Please select a newer deployment target in your project's Info.plist or change the SupportedOSPlatformVersion property in your project file.
[...]/packages/microsoft.net.illink.tasks/8.0.8/build/Microsoft.NET.ILLink.targets(87,5): error NETSDK1144: Optimizing assemblies for size failed. Optimization can be disabled by setting the PublishTrimmed property to false.
So improve this to only show a single error message:
The SupportedOSPlatformVersion value '10.0' in the project file is lower than the minimum value '11.0'.
Fixes https://github.com/xamarin/xamarin-macios/issues/21368.
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 74d83ca7e3).
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: https://github.com/xamarin/xamarin-android/pull/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.
The `SdkSupportedTargetPlatformVersion` item group is used for (at least) two things:
1. Generate the `_OR_GREATER` preprocessing symbols:
bfd2919bc4/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.BeforeCommon.targets (L230-L237)
2. Validate the TargetPlatformVersion:
bfd2919bc4/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.TargetFrameworkInference.targets (L233-L246)
The problem is that these two uses aren't equivalent.
Take for example the following scenario:
We release bindings for iOS 10, and a library developer takes advantage of the
bindings for the new iOS version, while at the same time supporting
multi-targeting to older platforms:
```csharp
#if IOS10_0_OR_GREATER
UseNewApi ();
#else
UseOldApi ();
#endif
```
Time passes, iOS 11 comes out, and we stop shipping bindings specifically for
iOS 10 (the APIs themselves would be included in the bindings for iOS 11). The
code above should continue to work, but iOS 10 is not a valid
TargetPlatformVersion anymore. However, with the current situation there's no
way to express this, because the moment we remove the "10.0" version from
SdkSupportedTargetPlatformVersion, the IOS10_0_OR_GREATER define isn't
generated anymore.
We discussed this in a meeting internally, and the suggestion that came up was
to use metadata to handle this situation, and we've decided to add the
"DefineConstantsOnly=true" metadata to items in
SdkSupportedTargetPlatformVersion that are "OS versions we support or have
supported", but not "OS versions we support as TargetPlatformVersion".
Note: we're adding this to .NET 8, but .NET will not understand the new
metadata until .NET 9, which means this won't be a breaking change until .NET
9.
In a different PR I'll add logic to warn if a project uses a
TargetPlatformVersion that is no longer valid (so that people will start
getting a warning in .NET 8 instead of getting surprised by a build error in
.NET 9).
Ref: https://github.com/dotnet/sdk/issues/38016
When passing -s to the csharp binary, the remaining arguments passed to the
script will be available in the global 'Args' variable.
This way makes it easier to consume arguments in the script, since we won't
have to call Environment.GetCommandLineArgs () and then manually skip the
arguments to the native executable (which would be: the path to mono, the path
to the csharp binary, and the '-s' argument if applicable).
In .NET the 4 platforms are 4 separate products, so it makes sense that each
Versions.plist only contains information for the corresponding platform.
This means we can share the same logic for all .NET platforms, instead of
having to special-case macOS.
It also decouples legacy logic from .NET logic, which makes it easier to
remove legacy logic when that time comes.
Create an MSBuild property for the minimum OS version
(`SupportedOSPlatformVersion`) we support for a given platform (named
`[platform]MinSupportedOSPlatformVersion`), and use it in most tests instead
of hardcoding the min OS version (which would otherwise have to be updated
every time we bump the min OS version).
Our min OS target versions are different between legacy Xamarin and .NET
(former supports earlier versions). The list of versions in the Versions.plist
contain all the versions supported by legacy Xamarin, but that's not correct
for .NET, so don't list any version in Version.plist that's lower than the
minimum OS version we support for a given platform.
Rolf Bjarne Kvinge