Building the custom-type-assembly assembly doesn't work quite right if the
RuntimeIdentifier(s) variables are set in the environment from the project
file, so don't forward those to the sub-make we execute to build the assembly.
This fixes an issue where building monotouch-test would fail locally, because
building the custom-type-assembly assembly would fail.
Also remove legacy Xamarin logic.
The variable TRACKING_DOTNET_RUNTIME_SEPARATELYis already defined further
above in this file, so just remove the second definition.
I believe this happened due to an incorrect merge conflict resolution at some
point.
This is another step towards removing Mono.
This required a few changes:
* Nullability updates in test code.
* Explicitly sorted list of strings in a warning message, to make the warning text stable.
* Stopped merging system assemblies in the merged tasks assembly. This was necessary for to solve a problem with duplicate types:
* The netstandard2.0 version of `System.Reflection.Metadata.dll` contains
the `UnconditionalSuppressMessageAttribute` type (internally).
* Since we ILMerge the tasks assembly, this type ends up in
Xamarin.iOS.Tasks.dll (internally).
* The test assembly can't be a net472 assembly, because that means using
the netfx/desktop versions of the Microsoft.Build.* assemblies, which
don't work on .NET (they check for Mono, but .NET isn't Mono, so the
check fails and a PlatformNotSupportedException is thrown).
* So I bumped the test assembly to be a net8.0 assembly, but then there's
a conflict between the `UnconditionalSuppressMessageAttribute` shipped
in .NET vs the one in `Xamarin.iOS.Tasks.dll` (because the test assembly
can see the internals of `Xamarin.iOS.Tasks.dll`).
* The fix that seems to work is to *not* merge system assemblies in the
`Xamarin.iOS.Tasks.dll` assembly. `Xamarin.iOS.Tasks.Windows.dll`
already does this, so hopefully there are no problems on Windows, and on
macOS our tests doesn't reveal any problems.
We know BCL won't have library resources to unpack, so there's no need to
spend any time looking at them.
This also required porting the UnpackLibraryResources task to use
System.Reflection.Metadata, because MetadataLoadContext requires the reference
assemblies to be available to resolve assembly dependencies (and the idea is
to not have to pass any reference assemblies to the task).
Fixes https://github.com/xamarin/xamarin-macios/issues/19511.
Fixes https://github.com/xamarin/xamarin-macios/issues/15030.
* Whenever we add a GitHub comment, also provide a comment id.
* When adding a GitHub comment, use that comment id to hide any previous comments with the same id.
It turns out this simplifies the code a lot, and additionally we now correctly
hide every comment we report whenever a step or stage is re-executed.
This is a log from our bots, note the 14 minute gap just before printing the timing results:
```
[...]
2024-09-27T07:34:00.3958920Z Making install in dotnet
2024-09-27T07:34:01.7633820Z Validated file permissions for Xamarin.Mac.
2024-09-27T07:34:01.7800150Z Validated file permissions for Xamarin.iOS.
2024-09-27T07:34:01.7825300Z
2024-09-27T07:34:01.7872490Z Xamarin.iOS has not been installed into your system by 'make install'
2024-09-27T07:34:01.7918570Z In order to set the currently built Xamarin.iOS as your system version,
2024-09-27T07:34:01.7965090Z execute 'make install-system'.
2024-09-27T07:34:01.7987920Z
2024-09-27T07:34:01.8034290Z Xamarin.Mac has not been installed into your system by 'make install'
2024-09-27T07:34:01.8080260Z In order to set the currently built Xamarin.Mac as your system version,
2024-09-27T07:34:01.8126200Z execute 'make install-system'.
2024-09-27T07:34:01.8148530Z
2024-09-27T07:48:22.3100850Z
2024-09-27T07:48:22.3102130Z real 15m26.160s
2024-09-27T07:48:22.3102800Z user 1m4.044s
2024-09-27T07:48:22.3103270Z sys 0m18.379s
```
What happens is this:
* We're using parallel make, and parallel make will start a jobserver, managed by file descriptors, where these file descriptors must be closed in all subprocesses for make to realize it's done.
* Any 'dotnet build' might start a build server
* The build server does not close any file descriptors it may have inherited when daemonizing itself.
* Thus the build server (which will still be alive after we're done building here) might have a file descriptor open which make is waiting for.
* The proper fix is to fix the build server to close its file descriptors.
* The intermediate working is to shut down the build server instead.
This will save 10-15 minutes at the end of every build in the bots.
This should speed up getting bots ready, since now we only run the
provisionator once for each bot, and we also don't try to provision the
same thing multiple times.
This will typically save between 1 and 2 minutes for every test run.
But potentially much more if GitHub happens to be slow:
```
[...]
Working on a PR, Undoing the github merge with main.
##[error]The task has timed out.
[...]
```
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-rtm.24473.2 to 9.0.0-rtm.24475.3 (parent: Microsoft.NET.Sdk)
- **Microsoft.AspNetCore.App.Ref**: from 9.0.0-rtm.24473.16 to 9.0.0-rtm.24474.6 (parent: Microsoft.NET.Sdk)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-rtm.24473.2 to 9.0.0-rtm.24475.3 (parent: Microsoft.NET.Sdk)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-rtm.24473.2 to 9.0.0-rtm.24475.3 (parent: Microsoft.NET.Sdk)
## From https://github.com/dotnet/sdk
- **Subscription**: 3727984b-7a79-4ba3-37dd-08dbe6bddf31
- **Build**: 20240925.4
- **Date Produced**: September 26, 2024 6:31:53 AM UTC
- **Commit**: f59e9ca09cb4d5b903b276c0d3d7825b6ddbc3a0
- **Branch**: refs/heads/release/9.0.1xx
- **Updates**:
- **Microsoft.NET.Sdk**: [from 9.0.100-rc.2.24474.4 to 9.0.100-rc.2.24475.4][1]
- **Microsoft.NET.ILLink.Tasks**: [from 9.0.0-rtm.24473.2 to 9.0.0-rtm.24475.3][2]
- **Microsoft.AspNetCore.App.Ref**: [from 9.0.0-rtm.24473.16 to 9.0.0-rtm.24474.6][3]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-rtm.24473.2 to 9.0.0-rtm.24475.3][2]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-rtm.24473.2 to 9.0.0-rtm.24475.3][2]
[1]: 42b2349ec2...f59e9ca09c
[2]: 3d9da91a97...2c4266c134
[3]: 91ef755ae0...afe2857bff
Also fix a couple of compiler warnings:
passkit.cs(2797,15): warning CS0109: The member 'PKShareablePassMetadataPreview.PassThumbnailImage' does not hide an accessible member. The new keyword is not required.
passkit.cs(2800,14): warning CS0109: The member 'PKShareablePassMetadataPreview.LocalizedDescription' does not hide an accessible member. The new keyword is not required.
It's old, hasn't been executed in years and quite bitrotten by now (it only
builds legacy Xamarin samples for instance).
We could port it to .NET, but first we'd need sample apps, and there
aren't many of those yet.
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-rc.2.24463.7 to 9.0.0-rtm.24473.2 (parent: Microsoft.NET.Sdk)
- **Microsoft.AspNetCore.App.Ref**: from 9.0.0-rtm.24466.12 to 9.0.0-rtm.24473.16 (parent: Microsoft.NET.Sdk)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-rc.2.24463.7 to 9.0.0-rtm.24473.2 (parent: Microsoft.NET.Sdk)
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**: from 9.0.0-rc.2.24455.1 to 9.0.0-rtm.24469.1 (parent: Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-rc.2.24463.7 to 9.0.0-rtm.24473.2 (parent: Microsoft.NET.Sdk)
- **Microsoft.DotNet.Cecil**: from 0.11.5-alpha.24419.1 to 0.11.5-alpha.24467.1 (parent: Microsoft.NETCore.App.Ref)
## From https://github.com/dotnet/sdk
- **Subscription**: 3727984b-7a79-4ba3-37dd-08dbe6bddf31
- **Build**: 20240924.4
- **Date Produced**: September 24, 2024 11:33:53 AM UTC
- **Commit**: 42b2349ec272dbb8bbc5d8df29adb7b77e3450cd
- **Branch**: refs/heads/release/9.0.1xx
- **Updates**:
- **Microsoft.NET.Sdk**: [from 9.0.100-rc.2.24468.2 to 9.0.100-rc.2.24474.4][1]
- **Microsoft.NET.ILLink.Tasks**: [from 9.0.0-rc.2.24463.7 to 9.0.0-rtm.24473.2][2]
- **Microsoft.AspNetCore.App.Ref**: [from 9.0.0-rtm.24466.12 to 9.0.0-rtm.24473.16][3]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-rc.2.24463.7 to 9.0.0-rtm.24473.2][2]
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**: [from 9.0.0-rc.2.24455.1 to 9.0.0-rtm.24469.1][4]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-rc.2.24463.7 to 9.0.0-rtm.24473.2][2]
- **Microsoft.DotNet.Cecil**: [from 0.11.5-alpha.24419.1 to 0.11.5-alpha.24467.1][5]
[1]: c204043de1...42b2349ec2
[2]: 46cfb747b4...3d9da91a97
[3]: 0d72ad5e4c...91ef755ae0
[4]: 6e079c23ae...8e660ff41e
[5]: c667bfea9c...526b22d829
Context: https://github.com/CommunityToolkit/Maui.NativeLibraryInterop
Introduces a `@(XcodeProject)` build action which can be used to build
and consume the outputs of Xcode framework projects.
The following metadata are supported on this item:
```xml
<XcodeProject Include="path/to/myproject.xcodeproj" >
<Configuration>Release</Configuration>
<CreateNativeReference>true</CreateNativeReference>
<ForceLoad></ForceLoad>
<Frameworks></Frameworks>
<Kind>Framework</Kind>
<OutputPath></OutputPath>
<SchemeName></SchemeName>
<SmartLink></SmartLink>
<Visible></Visible>
</XcodeProject>
```
* `%(SchemeName)`: The name of the build scheme or target that should
be used to build the project.
* `%(Configuration)`: The name of the configuration to use to build the
project. The default value is `Release`.
* `%(CreateNativeReference)`: Output XCFRAMEWORK files will be added as
a `@(NativeReference)` to the project. Metadata supported by
`@(NativeReference)` like `%(Kind)`, `%(Frameworks)`, or `%(SmartLink)`
will be forwarded if set. The default value is `true`.
* `%(OutputPath)`: Can be set to override the XCARCHIVE and XCFRAMEWORK
output path of the Xcode project. The default value is
`$(IntermediateOutputPath)xcode/{SchemeName}-{Hash}`.
A new `_BuildXcodeProjects` target will attempt to build XCARCHIVE and
XCFRAMEWORK files for each `@(XcodeProject)` item. These outputs will be
created for the platform specified in the target framework. If multiple
target frameworks are specified, the project will be built for each
platform during each inner build.
A new `$(MaciOSPrepareForBuildDependsOn)` build extension point has been
added to allow customer projects to more easily hook into the beginning
of the build process.
---------
Co-authored-by: Peter Collins <pecolli@microsoft.com>
Co-authored-by: Alex Soto <alex@soto.dev>
Addresses #13856
This was originally created by @dotMorten in #20434.
Also make SecIdentity.Import use an in-memory keychain on macOS 15+, so that
SecIdentity.Import works like all othe other platforms (i.e. not requiring
access to the default keychain, which, among other things, is not ideal on
bots).
---------
Co-authored-by: Morten Nielsen <mort5161@esri.com>
Co-authored-by: dotMorten <mn@iter.dk>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
### Description
Previously we were including .pdbs in NativeAOT debug bundles, which was causing issues with debug builds of universal apps (during app bundle merging). This does not seem to be required, as in debug builds NativeAOT compiler uses information from pdbs to provide more data about the managed code during native debugging (like line numbers in stack traces, etc), embedding it into the native image, and does not require presence of said files during runtime.
### Changes
- This PR excludes pdbs from NativeAOT app bundles by removing them from `ResolvedFileToPublish` item group.
- The relevant unit tests are reenabled.
---
Fixes https://github.com/xamarin/xamarin-macios/issues/20903