By moving the test from a macOS-specific location to a general location, it
becomes obvious that the test behaves the same on all platforms (which the
issue was about: it looked like we had different behavior on macOS vs the
other platforms, and the issue requested validation that this was correct - by
running the test on all platforms, with no platform-specific code, it
demonstrates that there's no macOS-specific behavior).
Fixes https://github.com/xamarin/xamarin-macios/issues/12468.
Detect if a url we use in our tests actually works, and if not, save the
results and ignore any subsequent test that tries to use that url.
---------
Co-authored-by: Haritha Mohan <harithamohan@microsoft.com>
* 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.
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 8.0.0-preview.3.23171.4 to 8.0.0-preview.4.23176.4 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 8.0.0-preview.4.23171.7 to 8.0.0-preview.4.23176.6 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-preview.3.23171.4 to 8.0.0-preview.4.23176.4 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100.Transport**: from 8.0.0-preview.3.23167.1 to 8.0.0-preview.4.23170.1 (parent: Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-preview.3.23171.4 to 8.0.0-preview.4.23176.4 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: 9a2944cb-7dee-4bf2-a65c-08dabd10ae64
- **Build**: 20230328.2
- **Date Produced**: March 28, 2023 10:27:20 AM UTC
- **Commit**: 69e28735b98581f2ee0825953de83a8581df7563
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.100-preview.4.23172.3 to 8.0.100-preview.4.23178.2][21]
- **Microsoft.NET.ILLink.Tasks**: [from 8.0.0-preview.3.23171.4 to 8.0.0-preview.4.23176.4][22]
- **Microsoft.AspNetCore.App.Ref**: [from 8.0.0-preview.4.23171.7 to 8.0.0-preview.4.23176.6][23]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-preview.3.23171.4 to 8.0.0-preview.4.23176.4][22]
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100.Transport**: [from 8.0.0-preview.3.23167.1 to 8.0.0-preview.4.23170.1][24]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-preview.3.23171.4 to 8.0.0-preview.4.23176.4][22]
[21]: 27622e3898...69e28735b9
[22]: edb161ab06...8d5f520838
[23]: 16907a1efa...c2350729d0
[24]: 25d9f7a5e3...a464820353
There's a 'link all' test that's verifying that the IntroducedAttribute is
linked away. It does so by verifying that the linked app doesn't have a
'IntroducedAttribute' type - but the test was constructing the fully qualified
type name to look for incorrectly:
ObjCRuntime.IntroducedAttribute, , Microsoft.iOS
Note the double comma: that meant we wouldn't find the type, even if it wasn't linked away.
The fix is easy (use a single comma), with one caveat (don't use a constant
string, because the linker sees the reference to
"ObjCRuntime.IntroducedAttribute" and _helpfully_ preserves it, exactly what
we don't want), but it revealed that the tested behavior regressed: a fully
linked app wouldn't link away the IntroducedAttribute.
So a fix is also needed: properly remove TVAttribute, WatchAttribute and
MacCatalystAttribute, which are subclasses of IntroducedAttribute (and what
would make the linker keep IntroducedAttribute).
Interestingly this showed up because of a bug in the runtime, where parsing
the invalid assembly name would now throw an exception
(https://github.com/dotnet/runtime/issues/84118).
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.
The BackingFieldDelayHandler will temporarily remove the body of Dispose
methods, and then for every field accessed in the Dispose method that was
preserved by the linker, we'll keep the corresponding code in the Dispose
method (otherwise we'd remove the code).
This is a way to remove fields that are _only_ accessed (and nulled out) in
the Dispose method.
However, we were running into a problem with determining if a field was marked
by the linker: if the field is in a generic type, and that field was not
marked by the linker, the linker might have actually removed the field from
the containing type before we're processing the Dispose methods, and we'd find
a null field definition where no null field definition was expected
(eventually resulting in an ArgumentNullException).
Fix this by treating a null field definition as an unmarked field.
Also add a test.
Fixes https://github.com/xamarin/xamarin-macios/issues/16957.
Implement a launch timeout for macOS and Mac Catalyst apps where if a certain
environment variable (LAUNCH_SENTINEL_FILE) is set, the app will create that
file at launch. The code launching the test app will wait 10 seconds and check
if the file is there: if it's not, something went wrong, in which case the app
should be terminated and launched again.
This necessitated re-implementing the launch script in C#, since it got quite
complicated to implement in bash.
This fixes an issue with Mac Catalyst apps where something would go wrong
during the app launch and nothing would happen (but the app wouldn't be
deadlocked, it would just sit there, doing nothing).
The TestRuntime.cs and ApplePlatform.cs had to be added to a few test projects
to make this compile, which required a few fixes in these files for building
with legacy Xamarin.Mac.
Fixes https://github.com/xamarin/maccore/issues/2414.
Fixes:
[FAIL] Bug12221 : System.AggregateException : One or more errors occurred. (Response status code does not indicate success: 403 (Forbidden).)
----> System.Net.Http.HttpRequestException : Response status code does not indicate success: 403 (Forbidden).
at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean )
at System.Threading.Tasks.Task.Wait(Int32 , CancellationToken )
at System.Threading.Tasks.Task.Wait()
at LinkSdk.AsyncTests.Bug12221() in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/linker/ios/link sdk/AsyncTest.cs:line 25
at System.Reflection.MethodInvoker.InterpretedInvoke(Object , Span`1 , BindingFlags )
--HttpRequestException
at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()
at System.Net.Http.HttpClient.GetStringAsyncCore(HttpRequestMessage , CancellationToken )
at LinkSdk.AsyncTests.<>c.<<LoadCategories>b__0_0>d.MoveNext() in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/linker/ios/link sdk/AsyncTest.cs:line 16
One important detail is the change from calling 'Wait ()' to calling
'GetAwaiter ().GetResult ()': this is to avoid the AggregateException in the
stack trace above.
Fixes https://github.com/xamarin/maccore/issues/2570.
Fixes this test in .NET 8:
AesCreate: System.Security.Cryptography.Algorithms,
Expected: String starting with "System.Security.Cryptography.Algorithms, "
But was: "System.Security.Cryptography, Version=7.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
Simon Rozsival
GitHub Actions Autoformatter
Rolf Bjarne Kvinge
Manuel de la Pena
dotnet-maestro[bot]