This PR brings all the changes from the new Metal APIs. During the
review pay special attention to the changes done in the Protocols in
order to add tvOS support.
The main problem we have had doing this PR is that tvOS was not done on
time before the NET branching, that left us with a lot of memebers that
were NOT added in tvOS that are abstract on dotnet, which has left use
in a pickle.
Lets use the following code as an example.
Code found before this commit:
```csharp
[Mac (11, 0), iOS (14, 0), NoTV]
[MacCatalyst (14, 0)]
#if NET
[Abstract]
#endif
[Export ("accelerationStructureCommandEncoder")]
IMTLAccelerationStructureCommandEncoder CreateAccelerationStructureCommandEncoder ();
```
A naive approach would be to add just the tvOS suppor as follows:
```csharp
[Mac (11, 0), iOS (14, 0), TV (16,0)]
[MacCatalyst (14, 0)]
#if NET
[Abstract]
#endif
[Export ("accelerationStructureCommandEncoder")]
IMTLAccelerationStructureCommandEncoder CreateAccelerationStructureCommandEncoder ();
```
The above change represents and API braking change on the donet tvOS dll
because it adds a new Abstrtact members, so this is no an acceptable
solution.
There is a second naive approach we can take which is as follows:
```csharp
[Mac (11, 0), iOS (14, 0), TV (16,0)]
[MacCatalyst (14, 0)]
#if NET &!TVOS
[Abstract]
#endif
[Export ("accelerationStructureCommandEncoder")]
IMTLAccelerationStructureCommandEncoder CreateAccelerationStructureCommandEncoder ();
```
Yet again, the naive approach has an issue with it. In this case, all
the extension methods that are generated for tvOS (something the
generator writes when methods are not abstract) will be decorated with
availability attributes for all the other platforms, which is incorrect
and will make developers life worse.
That leaves us with the following approach:
```csharp
#if NET
#if !TVOS
[Mac (11, 0), iOS (14, 0), NoTV, MacCatalyst (14, 0)]
[Abstract]
#else
[NoMac, NoiOS, TV (16,0), NoMacCatalyst]
#endif
#else
[Mac (11, 0), iOS (14, 0), TV (16,0), MacCatalyst (14, 0)]
#endif
[Export ("accelerationStructureCommandEncoder")]
IMTLAccelerationStructureCommandEncoder CreateAccelerationStructureCommandEncoder ();
```
With the above change, we do not add an abstract method in tvOS and we
only add the tvOS abailabity attribute to the extension methods, and use
NoiOS etc for all the other platforms.
The change had to be done to ALL methods that added tvOS support. The
good news are that our cecil tests and our introspection tests catch the
two naive approaces :)
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Haritha Mohan <harithamohan@microsoft.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
Looking into a intro failure on iOS: Selector not found for
HealthKit.HKHealthStore : workoutSessionMirroringStartHandler in
System.Action`1[HealthKit.HKWorkoutSession]
get_WorkoutSessionMirroringStartHandler() on HealthKit.HKHealthStore
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Alex Soto <alex@soto.dev>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
It's possible to create a provisioning profile for Mac Catalyst that
doesn't allow dylibs in the app. It seems a significant number of people run
into this problem when publishing their apps, so avoid it by linking Mono and
Xamarin statically by default instead.
The downside is that build time might increase a little bit.
An upside however is that the app size might decrease somewhat.
Fixes https://github.com/xamarin/xamarin-macios/issues/14686.
The issue relies in the fact that this code path was not executed when
using classic because in the classic version of the SDK we added the
availavility attrs both in the property, the getters and the setters.
With dotnet, we only add the attr in the property.
The code uses the GetProperty method which does not return
internal/private properties which means that some of those properties
are not correctly skipped when on dotnet. This was discovered while
working on xcode 15.
* Move all the RunAsync logic to the TestRuntime class, instead of having some
in TestRuntime and some in AppDelegate.
* Create a unified Task-based implementation for all platforms, optionally showing
a UI on the platforms where we can do that.
* Remove all the overloads that took a DateTime timeout, and instead only use a
TimeSpan timeout. This simplified some of the code.
* The new Task-based implementation will capture any exceptions (and rethrow most
of them) from the tasks we're waiting for, so no need to do that in each RunAsync
caller. This simplifies the testing code a lot for some tests.
* Add a new TryRunAsync method that will return (instead of rethrowing) any exceptions.
This simplifies some of the testing code (which verifies the correct exception,
or ignores the test in case of some exceptions).
* The new Task-based implementation will bubble up any NUnit exceptions, which
means that the tasks we're waiting for can call NUnit's Assert and the right thing
happens (in particular Assert.Ignore will actually ignore the test).
Change all null checking expressions to use 'is null' and 'is not null'
instead of '== null' and '!= null'.
This was mostly done with sed, so code can probably be improved in many
other ways with manual inspection, but that will come over time.
Also add code to the autoformat script to automatically fix these issues in the future.
It fails to update:
Coherency updates failed for the following dependencies:
Unable to update Microsoft.NET.Workload.Emscripten.net7.Manifest-7.0.100 to have coherency with Microsoft.NETCore.App.Ref: https://github.com/dotnet/runtime @ db7ca5d87eb3cd83bbc77487eb97dec07f74abf8 does not contain dependency Microsoft.NET.Workload.Emscripten.net7.Manifest-7.0.100
- Add the dependency to https://github.com/dotnet/runtime.
- Pin the dependenency.
- Remove the CoherentParentDependency attribute.
Once removed, bumping the .NET 8 dependency works again, so do that.
Fixes these test failures (which only happen on the bots):
[FAIL] AddressBook.InitConstants .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABGroupProperty .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABGroupProperty' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABGroupProperty..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABPersonPropertyId .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABPersonPropertyId' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABPersonPropertyId..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABPersonAddressKey .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABPersonAddressKey' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABPersonAddressKey..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABPersonDateLabel .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABPersonDateLabel' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABPersonDateLabel..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABPersonKindId .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABPersonKindId' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABPersonKindId..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABPersonPhoneLabel .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABPersonPhoneLabel' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABPersonPhoneLabel..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABPersonInstantMessageService .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABPersonInstantMessageService' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABPersonInstantMessageService..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABPersonInstantMessageKey .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABPersonInstantMessageKey' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABPersonInstantMessageKey..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABPersonUrlLabel .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABPersonUrlLabel' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABPersonUrlLabel..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABPersonRelatedNamesLabel .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABPersonRelatedNamesLabel' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABPersonRelatedNamesLabel..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABLabel .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABLabel' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABLabel..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABSourcePropertyId .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABSourcePropertyId' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABSourcePropertyId..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
There's not a finite list if measurement units, apps can create their own, so
we have to allow weakly typed measurement units (the normal property is bound
using a strong enum to NSRulerViewUnits).
Fixes https://github.com/xamarin/xamarin-macios/issues/17742.
We'll soon build and run tests on Windows, and some tests use these response files,
so it makes building these tests on Windows easier if we don't have to re-create
the response files (our generation logic is all written in make, which is not the
easiest on Windows).
Added Ventura machines to macTestConfigurations within both the
build-ci-pipeline and the build-pr-pipelines.
---------
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Additionally remove a lot of 64-bit-specific configurations
(Debug64/Release64) as well, and just make the default configurations
(Debug/Release) be 64-bit.
Unify a lot of code related to how to load test assemblies.
This resulted in adding a couple of test assemblies to monotouch-test when executed on macOS (this was a bug), and this also required adapting some of those tests to work correctly on macOS.
Manuel de la Pena
Rolf Bjarne Kvinge
TJ Lambert
Haritha Mohan
GitHub Actions Autoformatter
Alex Soto
Alex Soto
dustin-wojciechowski