This is one step towards removing the dependency on having Mono
installed during the build.
For some reason that also ended up requiring a few nullability issues in
the msbuild tests.
GitHub won't allow dropping files into a field where 'render: shell'
(presumably because that means the field will automatically become a
fenced block in the final issue), so just remove the 'render' property (this
way it matches all the other input fields).
Fixes https://github.com/xamarin/xamarin-macios/issues/21243.
Use the Info.plist to set the launch image and app icons for the app, instead
of using a storyboard / asset catalog.
One minor change is that the ".NET" text in the launch image is not located in
exactly the same place anymore. This is because it was rather complicated to
get the background color of the launch image correct. I tried numerous
options, neither of them fully work:
* Set the background color in the launch sreen png itself: this will create
black or white borders around the image.
* Use svg: svg doesn't work.
* There doesn't seem to be a way to specify multiple launch screen images, and
have iOS pick the best one depending on the target device size.
The end solution was to provide a really big launch screen png, so that there
won't be any black or white border on any of today's devices. The downside is,
as mentioned, that the text is not located in the same place once iOS has
adjusted the size of the image to fit the current device.
The big advantage is that this means we won't need to install the iOS
simulator on CI during our product build, we only need Xcode itself (we'll
still need all the simulators for our tests).
iPhone launch screen:
![IMG_0423](https://github.com/user-attachments/assets/761f7ed9-73f9-4c2b-821f-6eb87010f901)
iPad launch screen:
![IMG_0146](https://github.com/user-attachments/assets/b71c2f0f-6cf7-4ad4-b6c8-013617287ed4)
This reverts commit e993173a3c.
It breaks CI (tests are still running duplicated, except for the macOS
tests, which aren't running, except on the xcode16 branch, where they're
running and failing).
This pull request updates the following dependencies
## From https://github.com/dotnet/sdk
- **Subscription**: 3727984b-7a79-4ba3-37dd-08dbe6bddf31
- **Build**: 20240914.3
- **Date Produced**: September 14, 2024 9:05:51 PM UTC
- **Commit**: 1a658dfc714a5064eea57af48d5fd68a3ffab7ef
- **Branch**: refs/heads/release/9.0.1xx
- **Updates**:
- **Microsoft.NET.Sdk**: [from 9.0.100-rc.2.24463.45 to 9.0.100-rc.2.24464.3][49]
[49]: 0f07337f8d...1a658dfc71
## 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-rc.2.24461.16 to 9.0.0-rc.2.24462.10 (parent: Microsoft.NET.Sdk)
- **Microsoft.AspNetCore.App.Ref**: from 9.0.0-rc.2.24462.5 to 9.0.0-rc.2.24463.6 (parent: Microsoft.NET.Sdk)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-rc.2.24461.16 to 9.0.0-rc.2.24462.10 (parent: Microsoft.NET.Sdk)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-rc.2.24461.16 to 9.0.0-rc.2.24462.10 (parent: Microsoft.NET.Sdk)
Compute the API diff using the public (stable) NuGet instead of
downloading custom zip files.
Also remove all the legacy logic, and improve the README to explain the
process.
Note: the api diff won't work correctly in this PR (the comparison
against the previous commit won't be correct, because the previous
commit doesn't have the changes from this PR, which the new code
expects).
Resource triggers do an or on the stage, not and and. That means that
the tests pipelines are triggered once per stage. A way to solve this is
to split the tests and each of the pipelines will listen to specific
stage.
Some of the availability attributes are from earlier OS versions, but
it's what the headers + Apple's documentation say.
Note: there were no changes in beta 2, beta 3, beta 4, beta 5 or beta 6.
Replace `MacPoolAccessToken` with a dynamically obtained Azure DevOps
access token. The `MacPoolAccessToken` is backed by the
`botdeploy--azdo--token--register--untrusted` secret, which is limited
to a 7-day lifespan. This change removes the dependency on that token
We were ignoring members based on whether a member had
ObsoletedOSPlatformAttribute/UnavailableOSPlatformAttribute, not taking
into account that the attribute might not apply to the current platform.
So implement logic to only take into account
[Obsoleted|Unavailable]OSPlatformAttributes for the current platform.
This is mostly geared towards removing things that are now unnecessary to do
in CI and take a significant amount of time (there's still plenty of minor legacy
logic).
The pwsh used on windows is based on dotnet framework. Dotnet framework
has a limit in the size of the env that can be passed to a child
process. We are very close to reach the limit, but after #21009 we can
ignore that env variable since it is parsed from the args.
This is just needed for the ci pipeline because the issues are going to
have are related with the vsdrops task used to upload nuget results
etc..
This is because `EnablePreviewFeatures=true` doesn't quite work, since it
requires the building .NET and the target .NET to be on the same version.
We might want to build with .NET 9, but the Xcode branch is targeting .NET 8,
so it doesn't work.
This behavior is explained here:
https://github.com/dotnet/designs/blob/main/accepted/2021/preview-features/preview-features.md#meaning-of-property-in-multi-targeted-projects
The best solution seems to switch to using the Experimental attribute instead,
which was designed for our scenario (and explicitly to fix the problem we're
running into): bba3216250/accepted/2023/preview-apis/preview-apis.md
This also meant we had to augment `-nowarn` for bgen to:
* Pass any nowarn values to the compiler when bgen compiles stuff.
* Pass `$(NoWarn)` (the MSBuild property) to bgen when building a binding project.
---------
Co-authored-by: Alex Soto <alex@soto.dev>