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
Two changes:
1. Fix the tests by not using the Configuration.SourceRoot property. There is a bug in that code that returns diff paths in some bots.
2. Use Assert.Multiple for better error formatting.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Split the re-enabling of the macOS bot for the Windows tests to its own job,
so that we can stop running the tests job even if the reservation job failed.
---------
Co-authored-by: Alex Soto <alex@alexsoto.me>
By default, the build will just continue if a remote connection couldn't be
established. For tests that require a remote connection, this often results in
weird errors later on in the build, so improve this by immediately verifying
that we were able to establish a remote connection and telling the developer
where to look for more information.
---------
Co-authored-by: Alex Soto <alex@alexsoto.me>
#### Background
While cyclic assembly references are unusual they are supported by the runtime and encountered in practice. In our project we use a version of Xamarin.Forms retargeted for a modern .NET (as a stopgap solution before an update to full MAUI stack). Xamarin.Forms historically come with such an assembly cycle: `Xamarin.Forms.Core.dll` -> `Xamarin.Forms.Platform.dll` -> `Xamarin.Forms.Platform.iOS.dll` -> `Xamarin.Forms.Core.dll`. This is produced by first compiling `Xamarin.Forms.Core.dll` against a dummy `Xamarin.Forms.Platform.dll` (`netstandard2.0` assembly). Then the Platform assemblies are built, and finally forwarder versions of `Xamarin.Forms.Platform.dll` are created for each platform. This is all packaged into NuGets in such a way that each TFM gets the same `Xamarin.Forms.Core.dll` but a different set of `Xamarin.Forms.Platform.dll` and `Xamarin.Forms.Platform.<platform>.dll` assemblies.
#### Problem
With current workloads each incremental rebuild fails with:
```
/usr/local/share/dotnet/packs/Microsoft.iOS.Sdk/16.4.7125/targets/Xamarin.Shared.Sdk.targets(1047,3): error : Encountered an assembly reference cycle related to the assembly obj/Debug/net7.0-ios/iossimulator-arm64/linked/Xamarin.Forms.Core.dll
```
#### Solution
The PR updates the algorithm in `AOTCompile` to detect cycles using [Tarjan's algorithm](https://en.wikipedia.org/wiki/Tarjan%27s_strongly_connected_components_algorithm) for finding [strongly connected components](https://en.wikipedia.org/wiki/Strongly_connected_component) in a graph. When a cycle is detect any assembly in the cycle is considered up-to-date only if all the assemblies in the cycle are up-to-date.
With this change the project does incremental rebuilds correctly. I verified in the build output that the assembly cycle is considered up-to-date, and that any changes to the application assemblies still return `false` from the up-to-date check and get rebuilt.
---------
Co-authored-by: Filip Navara <filip.navara@gmail.com>
Sometimes we have flaky tests, now that we have the tests splitted,
doing a rerun is not expensive and will allow our CI builds to be
greener.
The template now checks if we are on CI and add the new rerun paramter
(this was added in 2021).
This avoids the Mono.Cecil dependency, and also MetadataLoadContext is both
faster and better maintained.
A temporary downside is that all the reference assemblies will have to be
copied to the remote Mac for remote builds, but this will be fixed in a future
change where we'll execute this task mostly locally on Windows, and we'll
only copy the unpacked resources to the Mac.
Apparently, in earlier versions of iOS, returning an empty dictionary from
UITextView.TypingAttributes would crash, so we added a workaround where we'd
return null instead of an empty dictionary.
However, I can't reproduce any such crashes anymore, and this workaround is
causing other problems, so remove it.
But do this in a backwards compatible way (just in case the removal ends up
crashing apps after all):
* Add a new TypingAttributes2 binding with the behavior we want (a better name
wouldn't be unwelcome!)
* Mark the existing TypingAttributes as obsolete, pointing to
TypingAttributes2.
* Make the TypingAttributes property behave as we want in XAMCORE_5_0, and at
that point mark TypingAttributes2 as obsolete and point back to
TypingAttributes.
* Remove TypingAttributes2 in XAMCORE_6_0.
Note: the presnippet attribute to avoid the crash was introduced in 2013:
5adb7c8608,
and our current minimum iOS version (iOS 11), was launched in 2017, so most
likely (aka hopefully) the crash was fixed in an iOS version earlier than the
earliest we support.
Fixes https://github.com/xamarin/xamarin-macios/issues/12709.
* Enable nullability and fix the resulting issues.
* Convert to XamarinTask (instead of XaxmarinToolTask): this allows us to run multiple
'scntool' invocations in parallel.
* Use 'xcrun' to call 'scntool' instead of computing the path [1].
* Fix bug in the Cancel method: it shouldn't call base.Execute.
* Change the targets logic to match the pattern of other resource-related targets.
* This makes it easier to understand the code, since understanding one resource-related target works for the other ones too.
* Not using the CollectBundleResources task means computing LogicalName in the ScnTool task directly.
[1]: https://github.com/xamarin/xamarin-macios/issues/11172#issuecomment-816324118
* Enable nullability and fix any issues.
* Improve error reporting by:
* Not bailing out when the first error is encountered, keep processing in
case we can be produce and find more problems to report.
* Show a better error message by including the path of the problematic
file in the error message.
Due to indentation changes, this PR migth be easier to review by [hiding
whitespace changes](https://github.com/xamarin/xamarin-macios/pull/19998/files?w=1).
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).
There are testing versions of the XVS' packages in some feeds with version
99.**, but we don't want to reference those by accident, so make sure we
reference the exact version of the XVS NuGet packages.
This has caused bugs multiple times in the past, the reference below is just
the latest one.
Ref: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1950696/?view=edit
APIScan is slow (as per their own documentation). To ensure that the
extra check does not slow our CI we create a matrix that will run
APIScan in each of the platforms to later be uploaded to TSA via a
funnel job.
Rolf Bjarne Kvinge
dotnet-maestro[bot]
Manuel de la Pena
Filip Navara
Haritha Mohan
Alex Soto