If a project tried to use a .NET 6 project (say TargetFramework=net6.0-ios), then
we used to show these rather unhelpful errors:
error NETSDK1147: To build this project, the following workloads must be installed: wasm-tools-net6
error NETSDK1147: To install these workloads, run the following command: dotnet workload restore
The underlying problem is that we don't support .NET 6 anymore, so with this fix we now show:
error NETSDK1202: The workload 'net6.0-ios' is out of support and will not receive security updates in the future. Please refer to https://aka.ms/maui-support-policy for more information about the support policy.
which is much more helpful.
References:
* https://github.com/dotnet/sdk/pull/32426
* https://github.com/xamarin/xamarin-android/pull/8047
Fixes https://github.com/xamarin/xamarin-macios/issues/18790.
It'll never be called from the generated code from the managed static
registrar, so there's no need to register it as a potential callback from
native code.
This makes the linker able to remove the Runtime.GetGenericMethodFromToken
method (and a few other methods as well).
Contributes towards #10405.
Don't allow re-running just the Windows tests job, because the Mac that was
reserved for us isn't reserved anymore.
Instead all the jobs must be re-run.
Accomplish this by storing the current BuildId in a file on the Mac bot, and
then verifying that it's the expeted BuildId from the test step from Windows.
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).
Rolf Bjarne Kvinge
dotnet-maestro[bot]
Manuel de la Pena
Filip Navara
Haritha Mohan
Alex Soto