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
Currently for universal apps we build the project once for each RuntimeIdentifier,
and each time we end up building any referenced projects as well.
It's not necessary to build referenced (library) projects on a per-RID basis, because
the RID isn't taken into account.
So optimize this:
1. Build project references in the containing build, before the RID-specific build.
This is accomplished by adding a dependency on the ResolveReferences target (which
also needs the BuildOnlySettings target to run first in order to actually build
any referenced projects).
2. Set "BuildProjectReferences=false" when running the RID-specific build, so
that any project references aren't built.
3. Also change how we override the BuildDependsOn property: we now have special
logic for library projects, where we don't do any kind of app-building stuff,
we only deal with resources.
4. This required adding another target dependency for _UnpackLibraryResources:
it now depends on the BuildOnlySettings target as well (for the same reason as
in point 1).
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
The canonical property we use for the interpreter is `MtouchInterpreter` - and
the interpreter is enabled if `MtouchInterpreter` is set to any value (the
`MtouchInterpreter` value is used to select which assemblies to interpret, the
only way to completely disable the interpreter is to not set
`MtouchInterpreter` at all).
So fix a couple of cases of wrong comparison:
* Don't use `UseInterpreter` - which is used to compute a specific value for
`MtouchInterpreter` - because developers don't have to set `UseInterpreter`
to enable the interpreter, they can set `MtouchInterpreter` directly.
* Don't compare `MtouchInterpreter` with `true`: that only checks if the
assembly "true" is interpreted (which it rarely is).
Fixes https://github.com/dotnet/runtime/issues/96920.
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.
In theory we should define the default platform version if it's not specified
in the TFM, and this default should not change for a given .NET version:
* We release support for iOS 17.0 with .NET 8
* Apple releases iOS 18.0, we're still using .NET 8. This default continues to be iOS 17.0
* .NET 9 is shipped, and at this point we bump the default to iOS 18.0
Basically: this should be the last OS version of the platform in question when
the current major .NET version is first released to stable.
Ref: 8e6394406d/accepted/2020/net5/net5.md (os-versions)
However, this doesn't work well for Apple platforms: whenever Apple releases
new Xcode versions, our existing workloads might not be compatible with the
new Xcode. We'll of course ship updateds workload with support for the new
Xcode, but defaulting to an older target platform version would mean that
developers wouldn't get the new workload, they'd get the old one. This is
exacerbated by the fact that Apple aggressively auto-updates Xcode on
developers' machines: they might wake up one day to a broken build - the
obvious fix ("dotnet workload update") doesn't fix anything - even if we've
shipped updated workloads - because the default is to use the old one. They'd
have to manually specify the target platform version in the target platform to
get the updated workload ("net8.0-ios17.2" to use the iOS 17.2 workload
instead of "net8.0-ios", which would use the default (old/initial/17.0) .NET 8
workload) - and then update _again_ when the next Xcode comes around. At this
point the point of having a sane default value is totally out the window,
because everybody would have to specify (and continuously update) a platform
version in their project files to keep their projects building.
So we've made the decision that the default target platform version is always
the latest target platform version.
We're calling the _CreateAssetPackManifest target during the build for legacy
Xamarin apps, but somehow this seems to have been skipped over when
implementing .NET support.
The reason this has not showed up before is that it requires:
* OnDemand resources.
* An AdHoc provisioning profile (and a distribution certificate).
The last part makes it rather complicated to write a unit test, so this has
been verified manually.
Fixes https://github.com/xamarin/xamarin-macios/issues/19669.
This is useful to compute the path to the Mac's Xamarin SDK from Windows: we
can compute the relative path on Windows, and then just prepend the Mac's path
to .NET.
This is easier than maintaining four different template files, also there will
be significant changes in the WorkloadManifest.targets file with the upcoming
multi-targeting changes, so this makes those changes simpler.
Long versions are sometimes problematic on Windows, because of MAX_PATH
issues. Versions for release builds don't contain the pre-release part, and
are thus usually short, but pre-release versions (which include an arbitrarily
long branch name) can get too long for Windows. This is a complication when
testing a release pipeline/process: we have to use final versioning just for
testing. This isn't ideal, so we special-case branch names that start with
`release-test/rt/`:
* Example: `iOS 15.1.123-rt` (and nothing else). This makes these versions
exactly 3 characters longer than the release version, which is hopefully
enough to avoid MAX_PATH issues on Windows.
The main problem is that an app with unsigned executable code will fail any signing
verification, and the app won't install on device.
This is implemented by doing two changes:
1. Augment the FilterStaticFrameworks task to only filter out frameworks with
static libraries (and thus keeping everything that's not a static framework, even
if it's not even a framework).
2. Execute the FilterStaticFrameworks task to filter out static frameworks from
the entire list of files to bundle in the hot restart app bundle.
When migrating Xamarin projects to .NET projects, somewhat frequently people
will leave the MtouchArch/XamMacArch properties in their project files with
old values. This won't work, since we use RuntimeIdentifier(s) now to control
the target architecture, so remove support for MtouchArch/XamMacArch, and show
an error if we detect that they're set.
This will hopefully prevent some really confusing problems, especially in the IDEs.
Example: https://github.com/xamarin/xamarin-macios/issues/19258
Fixed an issue where the C# class name was coming in with `,
AssemblyName` tacked on the end.
Fixed an issue where a class that had an entry in the map didn't have a
`class_ptr` which was causing an NRE.
Fixed a predicate for deciding when to mark the assembly for save.
Note - for an as yet undetermined reason, the linker is not picking up
that I'm marking the assembly for save, which is why the `true` test
cases are commented out.
This fixes issue 16671 https://github.com/xamarin/xamarin-macios/issues/16671
The current logic doesn't work on Windows for some reason.
Also avoid extra slash in _StrippedAssemblyDirectory, because
DeviceSpecificIntermediateOutputPath already has a trailing slash.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1864985.
We couldn't do universal builds using NativeAOT, because .NET had a sanity
check that was a bit too eager and caused unnecessary build failures. We've
now been able to add an escape hatch to that sanity check, so let's use it.
This makes universal builds using NativeAOT work, so we can also enable/add
corresponding test variations in xharness.
Also ask the runtime to allow SelfContained without a RuntimeIdentifier (the
runtime has an overeager sanity check that doesn't apply to us, so we must
skip it). Fixes#19142.
Fixes https://github.com/xamarin/xamarin-macios/issues/19142.
Fixes https://github.com/xamarin/xamarin-macios/issues/19206.
ILLink doesn't handle library projects the way we need: the library is
automatically treated as a root assembly, with the entry point as the root.
This doesn't work, because library projects don't have an entry point.
In earlier versions of .NET (and Xamarin), we'd solved this by a custom linker
step that would manually root everything that needed to be rooted, but that
doesn't work anymore because we hit this sanity check in ILLink:
> ILLink : error IL1034: Root assembly 'MyExtension, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have entry point.
Technically this happens because the library project is configured as a root
assembly, where the entry point is the root point (and in that regards the
sanity check is rather sane).
The best solution would be if we could just treat the library assembly as any
other assembly, and manually root it in our custom linker steps - but the
custom linker step we have for this kind of rooting will only iterate over
types in assemblies that are already marked somehow, and that's not
necessarily the case for app extension projects - the end result is that the
entire app extension assembly is linked away.
A close runner-up as the second best solution is to provide the API that needs
to be rooted as an xml file to the linker. This works, but we currently don't
have the infrastructure in the code to generate this xml file before running
the linker (it would be a rather major undertaking). This work is tentatively
scheduled for .NET 9 (https://github.com/xamarin/xamarin-macios/issues/17693).
So I went for the third option: set RootMode="Library" for the library
assembly. I'm not sure exactly what that means ILLink will mark, but as long
as _anything_ is marked, our custom linker step will run. This seems like an
acceptable workaround until we can implement the previous solution.
Fixes https://github.com/xamarin/xamarin-macios/issues/19037.
We might actually support a newer OS version than the one we're building for,
if we're supporting a preview version in a stable release. In this case, we
need to make sure to load the correct sdk when we run into errors, so that we
show the correct error messages.
Fixes this test failure:
Xamarin.Tests.DotNetProjectTest.InvalidTargetPlatformVersion(MacCatalyst): Error message
Expected string length 92 but was 87. Strings differ at index 84.
Expected: "...ormVersion for MacCatalyst. Valid versions include:\n16.4\n17.0"
But was: "...ormVersion for MacCatalyst. Valid versions include:\n17.0"
* Fix boolean logic to determine whether .NET is enabled or not
* Update mlaunch to get a fix where we trim the project.
* Update the list of files that need to be signed from mlaunch.
If anything we're supposed to link with *.o files, not publish them, but
since we're currently not handling any *.o files, just explicitly remove them
from the build. This avoids a warning where ComputeBundleLocation would issue
a warning about not knowing what to do with them.
Contributes towards https://github.com/xamarin/xamarin-macios/issues/18629.
---------
Co-authored-by: Ivan Povazan <55002338+ivanpovazan@users.noreply.github.com>
Rolf Bjarne Kvinge
Haritha Mohan
Steve Hawley
Alex Soto
dustin-wojciechowski
Filip Navara
Ivan Povazan
Šimon Rozsíval