This pull request updates the following dependencies
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Coherency Updates**:
- **Microsoft.NET.ILLink.Tasks**: from 9.0.0-preview.6.24319.11 to 9.0.0-preview.7.24357.2 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.AspNetCore.App.Ref**: from 9.0.0-preview.6.24320.4 to 9.0.0-preview.7.24360.7 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-preview.6.24319.11 to 9.0.0-preview.7.24357.2 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**: from 9.0.0-preview.6.24317.2 to 9.0.0-preview.7.24319.4 (parent: Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-preview.6.24319.11 to 9.0.0-preview.7.24357.2 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.DotNet.Cecil**: from 0.11.4-alpha.24313.1 to 0.11.5-alpha.24324.1 (parent: Microsoft.NETCore.App.Ref)
## From https://github.com/dotnet/sdk
- **Subscription**: 3727984b-7a79-4ba3-37dd-08dbe6bddf31
- **Build**: 20240711.1
- **Date Produced**: July 11, 2024 8:29:26 AM UTC
- **Commit**: 81ac886071828da7f14d0c26d731ac06abd0c7f6
- **Branch**: refs/heads/main
- **Updates**:
- **VS.Tools.Net.Core.SDK.Resolver**: [from 9.0.100-preview.7.24323.5 to 9.0.100-preview.7.24361.1][58]
- **Microsoft.NET.ILLink.Tasks**: [from 9.0.0-preview.6.24319.11 to 9.0.0-preview.7.24357.2][59]
- **Microsoft.AspNetCore.App.Ref**: [from 9.0.0-preview.6.24320.4 to 9.0.0-preview.7.24360.7][60]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-preview.6.24319.11 to 9.0.0-preview.7.24357.2][59]
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**: [from 9.0.0-preview.6.24317.2 to 9.0.0-preview.7.24319.4][61]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-preview.6.24319.11 to 9.0.0-preview.7.24357.2][59]
- **Microsoft.DotNet.Cecil**: [from 0.11.4-alpha.24313.1 to 0.11.5-alpha.24324.1][62]
[58]: ea9243f9cb...81ac886071
[59]: 117cfccdd7...4e278fe17f
[60]: 613c1e990b...71b5ef3f5c
[61]: 9880d891dd...ffe9afdc04
[62]: d145726036...7e4af02521
This pull request updates the following dependencies
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Coherency Updates**:
- **Microsoft.NET.ILLink.Tasks**: from 9.0.0-preview.5.24256.1 to 9.0.0-preview.6.24281.1 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.AspNetCore.App.Ref**: from 9.0.0-preview.5.24256.2 to 9.0.0-preview.6.24305.3 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-preview.5.24256.1 to 9.0.0-preview.6.24281.1 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**: from 9.0.0-preview.5.24223.2 to 9.0.0-preview.6.24277.2 (parent: Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-preview.5.24256.1 to 9.0.0-preview.6.24281.1 (parent: VS.Tools.Net.Core.SDK.Resolver)
## From https://github.com/dotnet/sdk
- **Subscription**: 3727984b-7a79-4ba3-37dd-08dbe6bddf31
- **Build**: 20240605.17
- **Date Produced**: June 5, 2024 11:40:08 PM UTC
- **Commit**: 6ecc573c92a1237627b37310c6aec65ff3caacc8
- **Branch**: refs/heads/main
- **Updates**:
- **VS.Tools.Net.Core.SDK.Resolver**: [from 9.0.100-preview.5.24262.2 to 9.0.100-preview.6.24305.17][65]
- **Microsoft.NET.ILLink.Tasks**: [from 9.0.0-preview.5.24256.1 to 9.0.0-preview.6.24281.1][66]
- **Microsoft.AspNetCore.App.Ref**: [from 9.0.0-preview.5.24256.2 to 9.0.0-preview.6.24305.3][67]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-preview.5.24256.1 to 9.0.0-preview.6.24281.1][66]
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**: [from 9.0.0-preview.5.24223.2 to 9.0.0-preview.6.24277.2][68]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-preview.5.24256.1 to 9.0.0-preview.6.24281.1][66]
[65]: 1741345c63...6ecc573c92
[66]: 84b3339505...3750ac5161
[67]: da3aa27233...8adff2c3cf
[68]: 53288f87c5...fae2c95346
---------
Co-authored-by: Alex Soto <alex@alexsoto.me>
The GKHybridStrategist type doesn't exist in iOS. This was probably a type
initially introduced in a beta version, and then removed in a later beta
version, and then we didn't notice.
This also required a minor generator fix to fix generation of async methods
with a nullable NSError.
---------
Co-authored-by: Israel Soto <issoto@microsoft.com>
The Skip* overrides in introspection are of the type "Do we skip? If not, then
I don't know, and we should call base", but the implementation of
iOSApiCtorInitTest.SkipCheckShouldReExposeBaseCtor is wrong, it just says to
not skip for every type except the one the method knows about.
So adjust the logic to call base if
iOSApiCtorInitTest.SkipCheckShouldReExposeBaseCtor has no knowledge of the
type in question.
We don't want to leak exceptions back to the calling native code in WrappedNSInputStream.Read, because that will likely crash the process.
Example stack trace:
ObjectDisposed_StreamClosed (System.ObjectDisposedException)
at System.ThrowHelper.ThrowObjectDisposedException_StreamClosed(String) + 0x3c
at System.IO.MemoryStream.Read(Byte[], Int32, Int32) + 0x124
at System.Net.Http.MultipartContent.ContentReadStream.Read(Byte[], Int32, Int32) + 0x78
at System.Net.Http.NSUrlSessionHandler.WrappedNSInputStream.Read(IntPtr buffer, UIntPtr len) + 0x58
at MyApp!<BaseAddress>+0x7082f8
Instead return -1 from the Read method, which is documented as an error
condition, and then also return a custom NSError from the Error property -
which is also documented to be where the error is supposed to be surfaced.
Ref: https://developer.apple.com/documentation/foundation/nsinputstream/1411544-read
Ref: https://github.com/xamarin/xamarin-macios/issues/20123.
This is a manual and squashed backport of
https://github.com/xamarin/xamarin-macios/pull/19717 and it was updated
to use Xcode 15.2 since Xcode 15.2 contains the same SDKs as Xcode 15.1
but Xcode 15.2 has visionOS SDK and it is the new stable release from
Apple.
---------
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
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).
Alex Soto
Rolf Bjarne Kvinge
dotnet-maestro[bot]
Alex Soto
Manuel de la Pena
TJ Lambert
Haritha Mohan
GitHub Actions Autoformatter