* Remove code to test NWPath.EnumerateInterfaces, because this method is already tested elsewhere.
* Assume that if the test fails to find any gateways, it might be because the
current machine doesn't have any (which happens on one of my machines), and
in that case ignore the test.
Move the architecture-specific vargs implementation of UIAppearance.GetAppareance into a more generic way of calling objc_msgSend with variadic arguments.
This prepares the way for more APIs with variadic arguments (which is coming in Xcode 16).
Apple says the bug on their side causing a runtime crash has been fixed since
macOS 12, so unignore the code and add a version check for macOS 12.
Fixes https://github.com/xamarin/maccore/issues/2345.
When finding an enumerator for the given code:
```cs
var collection = new NSSet<NSNumber> ();
foreach (var item in collection) {
// ...
}
```
the C# compiler will first look for any `GetEnumerator` methods. The non-generic `NSSet` class defines a `IEnumerator<NSObject> GetEnumerator<NSObject> ()` method, which, since the generic `NSSet<T>` class doesn't define such a method, is selected.
The end result is that the type of the foreach element is `NSObject`
(`GetEnumerator`'s return type') - which is somewhat unexpected:
```cs
var collection = new NSSet<NSNumber> ();
foreach (var item in collection) {
Console.WriteLine (item.LongValue); // error CS1061: 'NSObject' does not contain a definition for 'LongValue'
}
```
The fix is to define a `IEnumerator<T> GetEnumerator<T> ()` method in the
generic `NSSet<T>` class, which the C# will find and choose over the base
class' method. Then the type of the foreach element is the correct type, and
the following code works:
```cs
var collection = new NSSet<NSNumber> ();
foreach (var item in collection) {
Console.WriteLine (item.LongValue); // it works!
}
```
Do this for all our generic collection classes.
Also document these methods + all the other public `GetEnumerator` methods.
The logic to update the request's RequestUri is somewhat old:
518ac1bf19
but it makes sense to do so.
Some testing with a console app, also revealed that a plain .NET does this in
case of a redirect:
```cs
async static Task Main ()
{
var client = new HttpClient () { BaseAddress = new Uri("https://httpbin.org") };
var request = new HttpRequestMessage (HttpMethod.Get,
"/redirect-to?url=https%3A%2F%2Fmicrosoft.com&status_code=302&queries[]={}"
);
Console.WriteLine ($"Request uri 1: {request.RequestUri}");
var response = await client.SendAsync(request);
Console.WriteLine ($"Request uri 2: {request.RequestUri}");
var content = await response.Content.ReadAsStringAsync();
Console.WriteLine ((int) response.StatusCode);
Console.WriteLine(content.Length);
}
```
prints:
```
Request uri 1: /redirect-to?url=https%3A%2F%2Fmicrosoft.com&status_code=302&queries[]={}
Request uri 2: https://www.microsoft.com/es-es/
200
201252
```
Further looking into .NET's code, `SocketsHttpHandler` updates RequestUri after
following a redirect:
f5eb26e4da/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/RedirectHandler.cs (L65-L66)
So it seems the expected behavior is to update RequestUri only in case of a
redirect.
Now the question becomes: how to detect whether we're a redirect or not?
Contrary to `SocketsHttpHandler`, we don't do the actual redirect, it's
handled transparently by `NSUrlSession`.
Fortunately `NSUrlSessionTask` has two properties which help:
[`OriginalRequest`][1] and [`CurrentRequest`][2]. According to Apple's
documentation, these are the same, "except when the server has responded to
the initial request with a redirect to a different URL."
This sounds perfect for us, so use these two properties to determine whether a redirect occurred.
Note that we can't use object identity, because these are 'copy' properties,
which means they'll never be the same instances, only at most a copy of
eachother. So instead compare the `AbsoluteString` property to check for
equality. As far as I'm aware, none of the other properties (request body,
headers, cookies, etc.) can be set by the server in a redirect, so there's no
need to compare those.
Fixes https://github.com/xamarin/xamarin-macios/issues/20629.
[1]: https://developer.apple.com/documentation/foundation/nsurlsessiontask/1411572-originalrequest
[2]: https://developer.apple.com/documentation/foundation/nsurlsessiontask/1411649-currentrequest
We've recently started using more and more ARM64 bots, so these tests are
failing in those cases.
Fixes:
MonoTouchFixtures.Security.SecureTransportTest
[FAIL] SslSupportedCiphers : 3224092716
Expected: True
But was: False
at MonoTouchFixtures.Security.SecureTransportTest.SslSupportedCiphers () [0x000de] in <f08bd76ea2204d929c96e3bd36ae955a>:0
Xamarin.Mac.Tests.EveryFrameworkSmokeTests
[FAIL] ExpectedLibrariesAreLoaded : QTKitLibrary (/System/Library/Frameworks/QTKit.framework/QTKit) failed to load but this was not expected
at Xamarin.Mac.Tests.EveryFrameworkSmokeTests.ExpectedLibrariesAreLoaded () [0x000e6] in <f08bd76ea2204d929c96e3bd36ae955a>:0
Stop requiring a LinkWith attribute in an assembly in order to keep any Objective-C
types within. There are many ways to include a native library in a build nowadays,
and more and more often they don't need any LinkWith attributes to specify custom
linker behavior (in particular for frameworks, which can typically be included as-is).
The result of not searching such assemblies for Objective-C types would be that the
native linker would strip them away, and that would mean incorrect behavior at runtime.
However, this is a rather invasive change, especially for a minor release, so I'm
adding two things to make it better:
1. An opt-out MSBuild property: `RequireLinkWithAttributeForObjectiveCClassSearch`.
Set to 'true' to opt-out (default is 'false').
2. Improve handling of native symbols with regards to the native linker.
Add a new item group, ReferenceNativeSymbol, that contains native symbols
we handle in some way - either to be ignored or we ask the native linker
to keep it (by passing it as '-u ...' or in a symbol list file).
There are two supported types of metadata:
* SymbolType: either 'ObjectiveCClass', 'Function' or 'Field'. Used to
compute the complete native name of a symbol (for instance, the native
symbol for the Objective-C class "MyClass" is `_OBJC_CLASS_$_MyClass`,
while for a function "MyFunction" it's just `_MyFunction`.
* SymbolMode: either 'Ignore' or 'Default'. "Ignore" means to not pass the given
symbol to the native linker, the default is to do so.
SymbolType is required, while SymbolMode isn't.
Example symbol to keep:
```xml
<ItemGroup>
<ReferenceNativeSymbol Include="MyClass" SymbolType="ObjectiveCClass" />
</ItemGroup>
```
Example symbol to ignore:
```xml
<ItemGroup>
<ReferenceNativeSymbol Include="MyClass" SymbolType="ObjectiveCClass" SymbolMode="Ignore" />
</ItemGroup>
```
Finally use the latter solution to work around an issue that arouse with monotouch-test:
we reference an Objective-C class that doesn't exist in monotouch-test. This worked
because the referencing assembly didn't have a LinkWith attribute (and thus the reference
was ignored), but now that the reference isn't ignored anymore, we need to explicitly
ignore the Objective-C class.
The UITextAttributes.Dictionary property is supposed to work like the
UIStringAttributes.Dictionary property, but there's one big difference: the
UITextAttributes version can (and calling code does) be disposed, while the
UIStringAttributes version can't.
This is because the UITextAttributes version creates a new dictionary every
time, while the UIStringAttributes version doesn't.
Since properties shouldn't really do much, it makes sense to remove the
UITextAttributes version, and instead rely on the
UITextAttributes.ToDictionary method, where the difference in behavior is more
obvious.
This required a few changes in calling code, which used either UITextAttributes
or UIStringAttributes using conditional compilation.
Fixes https://github.com/xamarin/xamarin-macios/issues/20409.
Fixes this test failure:
MonoTests.System.Net.Http.MessageHandlerTest.GHIssue16339
[FAIL] GHIssue16339() : ReasonPhrase #1
Expected string length 2 but was 11. Strings differ at index 0.
Expected: "OK"
But was: "Bad Gateway"
The signature of the callback provided when creating AVAudioSourceNode instances
was wrong, so the callback would get corrupted data, causing crashes.
Fix the callback to have the right signature (not too difficult), and also make the
existing signature work (a bit more complicated).
Note that this is the second time we've tried to fix the delegate signature for the
AVAudioSourceNode callbacks, but now with tests, so hoping there won't be a third
time.
Fixes https://github.com/xamarin/xamarin-macios/issues/19868.
Also deprecate CGEventPostToPSN in documentation, but not formally using
attributes, because Apple only documented the deprecation of CGEventPostToPSN
in a header comment, and not their API documentation, nor using attributes.
Create a better binding for `[NSEvent eventWithGCEvent:]` by binding it as
`NSEvent.Create(CGEvent)` instead of `NSEvent.EventWithGCEvent(IntPtr)`.
Partial fix for https://github.com/xamarin/xamarin-macios/issues/12650.
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>
We've recently had a few test failures like this:
MonoTests.System.Net.Http.MessageHandlerTest.GHIssue16339
[FAIL] GHIssue16339() : IsSuccessStatusCode #1
Expected: True
But was: False
which doesn't provide much info into what went wrong.
It turns out this particular assert for IsSuccessStatusCode is redundant,
because we assert on the exact StatusCode a bit later, and if that assert
fails, we'll know a bit more.
So just remove this redundant assert for IsSuccessStatusCode.
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.
Also adjust naming and descriptions to make it clear we don't use a
specific minor version of each major OS version (so we're running on
"macOS 11", not necessarily "macOS 11.5").
---------
Co-authored-by: Alex Soto <alex@soto.dev>
Co-authored-by: Alex Soto <alex@alexsoto.me>
When resizing an array to a certain number of elements, we need to compute the
number of elements and use that to resize the array (and not use the size of
each element as the number of elements).
We also need to recompute the number of elements after calling the P/Invoke
(which may have changed the total size) - otherwise resizing the array is
entirely redundant (because the number of elements wouldn't change).
Looks like this was substep was only added to mtouch, never to mmp, so
let's fix that.
This also makes it possible to remove a test that was only there for the
linker to keep some required methods so that the test app would build
correctly.
Fixes https://github.com/xamarin/xamarin-macios/issues/19712.
This turned into a rather involved exercise, because the
MidiThruConnectionParamsStruct struct had several array fields that needed
marshalling to work.
The changes include:
* Unwrap the array fields with MarshalAs attributes to be individual fields
instead.
* Write a number of tests to ensure the changes work.
* Fix an overflow issue found by the tests for the Controls array if trying to
set to an array with more than 65535 elements.
* Fix an overflow issue found by the tests for the Maps array if trying to set
to an array with more than 65535 elements.
* Fix an issue found by the tests where we wouldn't deserialize the Maps array
correctly from a byte array / NSData if the Maps array had more than 1
element.
* Fix a consistency issue found in the tests where deserializing a serialized
structure doesn't yield the same result.
* In particular this happens with the ChannelMap property: behavior has
changed a little bit where setting the ChannelMap to an array with fewer
than 16 elements (including a null array) will not return the same array
anymore, but instead an array with 16 elements, where the extra elements
are all 0. I've also made the ChannelMap property non-nullable, since
the nullability state isn't serializable into the underlying struct.
Contributes towards #15684.
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>
Adding up for review but will block its landing until the PR
https://github.com/xamarin/xamarin-macios/pull/7539 which was fixed by
@dustin-wojciechowski has been landed.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Also fix the signature for the Dispose method - it has to override the base
implementation, not provide a new implementation.
Contributes towards #15684.
There are a few issues with the bindings, because the typedef `UITrait`
in the headers is defined like this:
```objective-c
typedef Class<UITraitDefinition> UITrait
```
which means: "A Class that implements the UITraitDefinition protocol",
and not "The UITraitDefinition" protocol", which is how it was bound.
This means the corresponding bindings are incorrect, so fix them. In
some cases it's not possible to fix the API, so new ones had to be
implemented in order to maintain backwards compatibility.
Fixes https://github.com/xamarin/xamarin-macios/issues/19410.
This commit adds some missing bindings and fixes up some of the previous
API that were incorrectly bound with Vector4 instead of Matrix4.
A sample app using some of these latest bindings can be found here:
https://github.com/haritha-mohan/vision-analyzer
Contributes to https://github.com/xamarin/maccore/issues/2719, though
the manual testing ended up not being necessary still helped catch a few
bugs and showcases some of the latest work done for this Xcode release.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Fix sending MidiPacket when MidiPacket has been created using a pointer to a byte[] rather than a byte[] passed as a reference.
MidiPacket.bytes used to be initialized to null, but that changed in a null-refactoring. Unfortunately code that dependend on the initial value being null wasn't updated, so the code regressed. Here we revert the old behavior by making the MidiPacket.bytes field nullable
Also add a test to make sure we don't regress this code again.
---------
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This cuts down a lot of the warnings we get when building monotouch-test, in
particular the availability warnings, which we don't care about since these
are test projects.
* Try again if we get a DuplicateItem error in MonoTouchFixtures.Security.KeyChainTest.Add_Certificate, hopefully fixes this random test failure:
MonoTouchFixtures.Security.KeyChainTest
[FAIL] Add_Certificate : Add_Certificate
Expected: Success
But was: DuplicateItem
at MonoTouchFixtures.Security.KeyChainTest.Add_Certificate() in /Users/builder/azdo/_work/2/s/xamarin-macios/tests/monotouch-test/Security/KeyChainTest.cs:line 49
Ref: https://github.com/xamarin/maccore/issues/2394
* Use a unique account name in MonoTouchFixtures.Security.RecordTest.Protocol_17579, hopefully fixes this random test failure:
MonoTouchFixtures.Security.RecordTest
[FAIL] Protocol_17579 : Add
Expected: Success
But was: DuplicateItem
at MonoTouchFixtures.Security.RecordTest.Protocol(SecProtocol protocol) in /Users/builder/azdo/_work/2/s/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 204
at MonoTouchFixtures.Security.RecordTest.Protocol_17579() in /Users/builder/azdo/_work/2/s/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 232
Ref: https://github.com/xamarin/maccore/issues/2692
The “Thawte SGC CA” certificate we're using for testing is now blocked by
Apple, evaluating trust results in this error:
> “Thawte SGC CA” certificate is blocked
So update the mail_google_com certificates to what mail.google.com serves now, and also update the corresponding parent certificates (which have changed).
Then adjust the tests accordingly.
Finally delete all unused certificates from the code.
Fixes these test failures:
MonoTouchFixtures.Security.TrustTest
[FAIL] Trust_FullChain : GetTrustResult-2
Expected: RecoverableTrustFailure
But was: FatalTrustFailure
at MonoTouchFixtures.Security.TrustTest.Trust_FullChain(SecTrust trust, SecPolicy policy, X509CertificateCollection certs) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/monotouch-test/Security/TrustTest.cs:line 389
at MonoTouchFixtures.Security.TrustTest.Trust_FullChain() in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/monotouch-test/Security/TrustTest.cs:line 321
[FAIL] Trust2_FullChain : GetTrustResult-2
Expected: RecoverableTrustFailure
But was: FatalTrustFailure
at MonoTouchFixtures.Security.TrustTest.Trust_FullChain(SecTrust trust, SecPolicy policy, X509CertificateCollection certs) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/monotouch-test/Security/TrustTest.cs:line 389
at MonoTouchFixtures.Security.TrustTest.Trust2_FullChain() in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/monotouch-test/Security/TrustTest.cs:line 449
* Add basic logic to detect network problems for NSErrors.
* Include better logging of NSError failures in the UrlConnectionTest.SendSynchronousRequest test.
* Misc code cleanup.
Also introduce a few other improvements:
* Add an varation that takes an 'out bool' instead of a 'ref bool'. According
to the documentation the value is out-only.
* Name this variation according to our guidelines (with a verb).
* Deprecate the old version.
Contributes towards https://github.com/xamarin/xamarin-macios/issues/15684.
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>
Rolf Bjarne Kvinge
Alex Soto
Yauheni Pakala
Manuel de la Pena
Haritha Mohan
jamesdlow