Add multi-targeting support for our initial .NET 8 packs (for Xcode
15.0).
This means a library/binding project can do:
```xml
<TargetFrameworks>net8.0-ios17.0;net8.0-ios17.2</TargetFrameworks>
```
and the library will be built in two varieties: once using our iOS 17.0
bindings, and once using our iOS 17.2 bindings.
An app project can also do:
```xml
<TargetFramework>net8.0-ios17.0</TargetFramework>
```
to build with the iOS 17.0 bindings (which is typically not very useful,
since building with the latest iOS SDK is usually best).
This is the first step towards [multi-targeting support][1]. In order to
support multi-targeting, it must be possible to install several versions of
our packs simultaneously, and that also means that it becomes a lot easier to
visualize and work with the version we want to support if the packs were named
in a helpful way.
In particular, this PR changes the sdk, ref and runtime pack names to contain
the target framework + target platform version.
This will be the new names:
* iOS
* Microsoft.iOS.Sdk.net8.0_17.2
* Microsoft.iOS.Ref.net8.0_17.2
* Microsoft.iOS.Runtime.ios-arm64.net8.0_17.2
* Microsoft.iOS.Runtime.iossimulator-arm64.net8.0_17.2
* Microsoft.iOS.Runtime.iossimulator-x64.net8.0_17.2
* tvOS
* Microsoft.tvOS.Sdk.net8.0_17.2
* Microsoft.tvOS.Ref.net8.0_17.2
* Microsoft.tvOS.Runtime.ios-arm64.net8.0_17.2
* Microsoft.tvOS.Runtime.iossimulator-arm64.net8.0_17.2
* Microsoft.tvOS.Runtime.iossimulator-x64.net8.0_17.2
* Mac Catalyst
* Microsoft.MacCatalyst.Sdk.net8.0_17.2
* Microsoft.MacCatalyst.Ref.net8.0_17.2
* Microsoft.MacCatalyst.Runtime.maccatalyst-x64.net8.0_17.2
* Microsoft.MacCatalyst.Runtime.maccatalyst-arm64.net8.0_17.2
* macOS
* Microsoft.macOS.Sdk.net8.0_14.2
* Microsoft.macOS.Ref.net8.0_14.2
* Microsoft.macOS.Runtime.osx-x64.net8.0_14.2
* Microsoft.macOS.Runtime.osx-arm64.net8.0_14.2
There are two main benefits to renaming the packs:
* It becomes a lot easier to understand which versions we support when we
support multi-targeting. For example, say we want to support:
* net8.0-ios17.0
* net8.0-ios17.2
* net9.0-ios18.0
In this case we'd ship packs for `Microsoft.iOS.Sdk.net8.0_17.0`,
`Microsoft.iOS.Sdk.net8.0_17.2`, `Microsoft.iOS.Sdk.net9.0_18.0` (the
exact version number for each pack wouldn't be important).
If we didn't change the pack names, we'd need to track the exact versions
of the Microsoft.iOS.Sdk pack, mapping them to the correct target
framework + target platform version we want to support.
* It'll be possible to add maestro subscriptions between versions. Given the
previous example:
* net8.0-ios17.0
* net8.0-ios17.2
* net9.0-ios18.0
The branch producing `net9.0-ios8.0` could have a maestro subscription on
the branches producing `net7.0-ios17.0` and `net7.0-ios17.2`,
automatically bumping the versions whenever those branches have any
changes.
This would be rather annoying to keep track of and bump manually.
[1]: https://github.com/xamarin/xamarin-macios/blob/main/docs/multi-target-framework.md
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).
Context: https://dotnet.microsoft.com/platform/support/policy/maui
> A major version of .NET MAUI receives support for a minimum of 6
> months after a successor (the next major release) ships. For
> example, .NET MAUI 6.0 will be supported for 6 months after .NET
> MAUI 7.0 ships. Similarly, .NET MAUI 7.0 will receive support for 6
> months after .NET MAUI 8.0 ships.
By the time .NET 8 GA ships, .NET 6 MAUI projects will not be supported.
Remove .NET 6 support from our .NET 8 workloads.
A `Xamarin.Shared.Sdk.MultiTarget.targets` file has been added to update
the ref/runtime pack versions associated with the .NET 6 SDK. This file
will ship as part of the .NET 7 SDK but only be imported when using the
.NET 6 SDK. This should work around the need to add new and net7
versioned aliases of the `Ref` and `Runtime` packs. Adding this file to
`AfterMicrosoftNETSdkTargets` will ensure that it is imported last,
after all `KnownFrameworkReferences` that need updating are declared.
Backport of #15834
Co-authored-by: Peter Collins <pecolli@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Rolf Bjarne Kvinge
VS MobileTools Engineering Service 2
Peter Collins