This is part of the effort to migrate the Pair to Mac agents .NET.
As the Xamarin.iOS.Tasks.Windows project targets netstandard2.0, I'm
removing the Build agent reference, and modifying the Makefile to take
it from it's output directory. Note: the agent zip file is generated in
the intermediate output directory.
---------
Co-authored-by: Emanuel Fernandez Dell'Oca <ema@xamarin.com>
### Description
When building universal apps with NativeAOT, the output path for the app bundle (and zipped .ipa) is incorrect when building with NativeAOT.
For example publishing a MAUI template app with NativeAOT gives the following output (notice: `osx-arm64`):
```
Created the package: /Users/ivan/tmp/net9-rc1/MacCatRc1/bin/Release/net9.0-maccatalyst/osx-arm64/publish/MacCatRc1-1.0.pkg
```
and the following output tree:
```
bin/Release
bin/Release/net9.0-maccatalyst
bin/Release/net9.0-maccatalyst/maccatalyst-arm64/*
bin/Release/net9.0-maccatalyst/maccatalyst-x64/*
bin/Release/net9.0-maccatalyst/osx-arm64
bin/Release/net9.0-maccatalyst/osx-arm64/MacCatRc1.app/*
bin/Release/net9.0-maccatalyst/osx-arm64/publish/*
```
The problem comes from the fact that .NET SDK for NativeAOT builds will try to resolve `RuntimeIdentifier` when it is not specified in:
58eb155e30/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.RuntimeIdentifierInference.targets (L95-L114)
which resolves to `osx-arm64` and gets later used to setup `IntermediateOutputPath` and `OutputPath` in:
58eb155e30/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.RuntimeIdentifierInference.targets (L343-L346)
However, this shouldn't be done in universal builds, as the outer build does not have the runtime identifier specified and should not be altered.
### Changes
In this PR we are disabling the resolution of the `RuntimeIdentifier` when building universal apps with NativeAOT early in SDK in order to fix the output path.
I also included unit tests to verify the existence of .app bundles.
### Follow-up
There is an additional issue with Debug builds of universal apps with NativeAOT, where merging PDBs fails, which is reported in: https://github.com/xamarin/xamarin-macios/issues/20903
---
Contributes to: https://github.com/xamarin/xamarin-macios/issues/20903
---------
Co-authored-by: Ivan Povazan <ivan.povazan@gmail.com>
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.AspNetCore.App.Ref**: from 9.0.0-rc.2.24466.2 to 9.0.0-rtm.24466.12 (parent: Microsoft.NET.Sdk)
## From https://github.com/dotnet/sdk
- **Subscription**: 3727984b-7a79-4ba3-37dd-08dbe6bddf31
- **Build**: 20240918.2
- **Date Produced**: September 18, 2024 8:48:35 AM UTC
- **Commit**: c204043de141a4d00ae5b4ec1b82aab67cccac1d
- **Branch**: refs/heads/release/9.0.1xx
- **Updates**:
- **Microsoft.NET.Sdk**: [from 9.0.100-rc.2.24466.29 to 9.0.100-rc.2.24468.2][4]
- **Microsoft.AspNetCore.App.Ref**: [from 9.0.0-rc.2.24466.2 to 9.0.0-rtm.24466.12][5]
[4]: 92b8b5eb94...c204043de1
[5]: 9b3ca0b29a...0d72ad5e4c
The consumers of the API stage already passes a value, so a default is not needed.
This reduces the number of places we have to change every time we switch between stable and beta.
We need the AzDo.BearerToken in later steps that have the 'always()'
condition, and unless we actually get the AzDo.BearerToken under the same
conditions, those later steps will fail.
One example is if the job was cancelled, or previous steps failed (which is
common when running tests).
Example failure for re-enabling macOS bots:
```
AzDO.BearerToken : The term 'AzDO.BearerToken' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At D:\AzDO\_work\_temp\9b207e8a-c163-4c97-93d3-e7e3bb908583.ps1:6 char:23
+ $azdoBearerToken = "$(AzDO.BearerToken)"
+ ~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (AzDO.BearerToken:String) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : CommandNotFoundException
```
This problem causes a lot of bots to end up disabled, because we fail to
re-enable them after using them.
The test we had in our codebase for the SBApplication class was not only
outdated, but also incorrect.
With recent changes the test code doesn't work anymore, so delete it.
Instead, add XML documentation that explains how to use the class in a
way that works.
Fixes https://github.com/xamarin/xamarin-macios/issues/21242.
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:
iPad launch screen:
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.
Rolf Bjarne Kvinge
Ivan Povazan
Jeremi Kurdek
dotnet-maestro[bot]
Alex Soto
Manuel de la Pena