Context: b2d3a3a355
Context: https://github.com/xamarin/yaml-templates/pull/339
The VS insertion manifest generation has been updated to use new VS
component IDs required for .NET 9+.
Backport of #21423
---------
Co-authored-by: Peter Collins <pecolli@microsoft.com>
We need to set "UseCurrentRuntimeIdentifier=false", we must only set it for
the outer build for universal builds - when `RuntimeIdentifiers` is set - but
that means we can only do it *after* we set any default value for
`RuntimeIdentifiers`.
Fixes https://github.com/xamarin/xamarin-macios/issues/19391#issuecomment-2405499973.
This isn't very user friendly:
ILLink : unknown error IL7000: An error occurred while executing the custom linker steps. Please review the build log for more information.
ILLINK : error MT0073: Microsoft.iOS 18.0.8337 does not support a deployment target of 10.0 for iOS (the minimum is 11.0). Please select a newer deployment target in your project's Info.plist or change the SupportedOSPlatformVersion property in your project file.
ILLINK : error MT2301: The linker step 'Setup' failed during processing: Microsoft.iOS 18.0.8337 does not support a deployment target of 10.0 for iOS (the minimum is 11.0). Please select a newer deployment target in your project's Info.plist or change the SupportedOSPlatformVersion property in your project file.
[...]/packages/microsoft.net.illink.tasks/8.0.8/build/Microsoft.NET.ILLink.targets(87,5): error NETSDK1144: Optimizing assemblies for size failed. Optimization can be disabled by setting the PublishTrimmed property to false.
So improve this to only show a single error message:
The SupportedOSPlatformVersion value '10.0' in the project file is lower than the minimum value '11.0'.
Fixes https://github.com/xamarin/xamarin-macios/issues/21368.
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.
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>
### 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
### 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 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>
This change removes the xcsync tool as an installed component of the SDK
and uses it as a .NET Global Tool. The existing targets will continue to
work, they will check if the tool is already installed, and if not,
install it.
When VS (Windows) needs to figure out where the iOS SDK is located on disk on
the Mac machine, the project is evaluated and
the`_XamarinRelativeSdkRootDirectory` property is read. Unfortunately an
MSBuild optimization recently occurred in VS, where they don't keep
underscored properties around after the build, and thus the property XVS needs
to inspect isn't there anymore.
So make `_XamarinRelativeSdkRootDirectory` and `_RelativeMlaunchPath` public
properties by removing the underscore.
Fixes https://dev.azure.com/devdiv/DevDiv/_workitems/edit/2220369.
Backports the following maestro and artifact storage changes,
removing dependencies on bosstoragemirror and adding support
for passwordless maestro auth.
0d1bd7b1bcebf969ee402562461eeb
Context: https://github.com/dotnet/android/issues/9164
We've seen the build promotion pipeline fail when trying to publish
stable package versions:
error : Package 'Microsoft.iOS.Ref.net8.0_17.5' has stable version '17.5.8001' but is targeted at a non-isolated feed 'https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet8/nuget/v3/index.json'
This is because we were not declaring these packages as stable when
building the build asset registry manifest.
Fix this by passing the `$NUGET_PRERELEASE_IDENTIFIER` variable to the
build asset manifest creation task to determine if a build is stable.
When `$(IsStableBuild)` is set to true, packages will be pushed to an
isolated feed during publishing, such as:
Package Microsoft.Android.Ref.34@34.0.125 (Shipping) should go to https://pkgs.dev.azure.com/dnceng/public/_packaging/darc-pub-dotnet-android-b8317b6f/nuget/v3/index.json (Isolated, Public)
Additionally migrates darc/maestro commands to use a passwordless auth flow,
as token-based authentication will be removed in the future.
This will hopefully make it easier to diagnose these kinds of crashes:
Thread 0 Crashed:
0 libobjc.A.dylib 0x00000001a6f6e7f8 object_getClass + 48
1 MyTestDotNetApp.Net 0x0000000104b90a68 do_icall (interp.c:2273)
2 MyTestDotNetApp.Net 0x0000000104b8f838 do_icall_wrapper (interp.c:2361)
3 MyTestDotNetApp.Net 0x0000000104b85214 interp_exec_method (interp.c:3885)
4 MyTestDotNetApp.Net 0x0000000104b82de8 interp_runtime_invoke (interp.c:2122)
5 MyTestDotNetApp.Net 0x0000000104b4aedc mono_jit_runtime_invoke (mini-runtime.c:3650)
6 MyTestDotNetApp.Net 0x0000000104a8b874 mono_runtime_try_invoke (object.c:2415)
7 MyTestDotNetApp.Net 0x0000000104a8d8a0 mono_runtime_invoke (object.c:2464)
8 MyTestDotNetApp.Net 0x0000000104c42b68 native_to_managed_trampoline_68(objc_object*, objc_selector*, _MonoMethod**, objc_object*, unsigned int) (registrar.mm:4511)
9 MyTestDotNetApp.Net 0x0000000104c42a00 +[__NSObject_Disposer drain:] (registrar.mm:20968)
10 Foundation 0x00000001adc13b14 __NSThreadPerformPerform + 260
This happens because we try to access freed/invalid memory, but unfortunately
the crash report / stack trace does not contain any hint whatsoever about the
memory that triggered the crash.
By adding an opt-in to validate the memory for a given object, we might be
able to detect this crash in a few cases, and instead throw a managed
exception with much more information.
A project opts-in by setting `_ValidateObjectPointers=true` in the csproj.
Ref: https://github.com/xamarin/xamarin-macios/issues/19493
---------
Co-authored-by: Manuel de la Pena <mandel@microsoft.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.NET.ILLink.Tasks**: from 9.0.0-preview.7.24366.18 to 9.0.0-rc.1.24378.5 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.AspNetCore.App.Ref**: from 9.0.0-rc.1.24375.10 to 9.0.0-rc.1.24379.7 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-preview.7.24366.18 to 9.0.0-rc.1.24378.5 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**: from 9.0.0-preview.7.24365.1 to 9.0.0-rc.1.24373.3 (parent: Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-preview.7.24366.18 to 9.0.0-rc.1.24378.5 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.DotNet.Cecil**: from 0.11.5-alpha.24324.1 to 0.11.5-alpha.24365.1 (parent: Microsoft.NETCore.App.Ref)
## From https://github.com/dotnet/sdk
- **Subscription**: 3727984b-7a79-4ba3-37dd-08dbe6bddf31
- **Build**: 20240730.5
- **Date Produced**: July 30, 2024 10:19:29 PM UTC
- **Commit**: 10803eca35eef6e685924886ba74caf0bd9439ad
- **Branch**: refs/heads/main
- **Updates**:
- **VS.Tools.Net.Core.SDK.Resolver**: [from 9.0.100-rc.1.24377.4 to 9.0.100-rc.1.24380.5][16]
- **Microsoft.NET.ILLink.Tasks**: [from 9.0.0-preview.7.24366.18 to 9.0.0-rc.1.24378.5][17]
- **Microsoft.AspNetCore.App.Ref**: [from 9.0.0-rc.1.24375.10 to 9.0.0-rc.1.24379.7][18]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-preview.7.24366.18 to 9.0.0-rc.1.24378.5][17]
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**: [from 9.0.0-preview.7.24365.1 to 9.0.0-rc.1.24373.3][19]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-preview.7.24366.18 to 9.0.0-rc.1.24378.5][17]
- **Microsoft.DotNet.Cecil**: [from 0.11.5-alpha.24324.1 to 0.11.5-alpha.24365.1][20]
[16]: 74dafbfb0c...10803eca35
[17]: 1f70f0cc66...0912e94a6c
[18]: 98ee50279a...27f2a011a4
[19]: 99ea0c06b8...40781ca2fc
[20]: 7e4af02521...e05101e694
---------
Co-authored-by: Alex Soto <alex@soto.dev>
Backport of https://github.com/xamarin/xamarin-macios/pull/20952
--------
## Description
Previous fix https://github.com/xamarin/xamarin-macios/pull/20945 did
not take into account that when we target non arm64 apple mobile
platforms we are using `MONO_AOT_MODE_INTERP_ONLY` which cannot use
dedup optimization as it discards AOT images during runtime.
## Changes
- Enable dedup only when targeting ARM64
- Fix tests to cover builds for both ARM64 and X64 builds
Finally, the change was tested against MAUI iossimulator-x64 template
app
---------
Co-authored-by: Ivan Povazan <ivan.povazan@gmail.com>
Co-authored-by: Ivan Povazan <55002338+ivanpovazan@users.noreply.github.com>
## Description
This is a follow-up PR to:
https://github.com/xamarin/xamarin-macios/pull/20936
We should not enable dedup when targeting `maccatalyst-x64` because in
case when the project file specifies
`MtouchInterpreter=all,-System.Private.CoreLib`, the build will run the
full AOT compiler with interpreter enabled.
In this setup the runtime is configured to run in interp only mode:
97a91cc4e3/tools/common/Target.cs (L812-L813)
which means that during runtime, AOT images will be ignored - aot
runtime will load them but mark them as unusuable since they are
compiled with `full` compiler switch and the code falls back to
interpreter (ref:
efebf202a4/src/mono/mono/mini/aot-runtime.c (L2131-L2148)
)
This is problematic for the `aot-instances` container image, which has a
special handling at the runtime and does not accept it to be marked as
unusable (we might want to revisit this in the future):
efebf202a4/src/mono/mono/mini/aot-runtime.c (L2527-L2529)
## Changes
This PR disables dedup optimization when targeting `maccatalyst-x64` and
updates the required tests to match the behavior.
---
Backports:
- [x] https://github.com/xamarin/xamarin-macios/pull/20946
- [x] Original reenabling of dedup for .NET 9 already includes these
changes: https://github.com/xamarin/xamarin-macios/pull/20941
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Backport of #20936
---
## Description
As part of the fix for: https://github.com/dotnet/runtime/issues/99248
we disabled dedup optimization in partial/hybrid AOT mode (when both
interpreter and AOT compiler are enabled). This change got backported to
.NET 8 and with the latest servicing release regressed build times and
app sizes significantly as reported in:
https://github.com/xamarin/xamarin-macios/issues/20848
However, it turns out that disabling dedup optimization is not required
to fix https://github.com/dotnet/runtime/issues/99248 but instead we
should correct the Xamarin SDK integration with this optimization which
this PR is doing. The following section describes the initial problem in
more details.
## Overview of AOT modes and dedup optimization
When the repro project from
https://github.com/dotnet/runtime/issues/99248 is built with dedup
enabled in hybrid AOT+interpreter mode, the app crashes with:
```
024-07-23 14:32:37.524110+0200 IvansApp[12711:20244208] debug: AOT NOT FOUND: (wrapper other) object:gsharedvt_out_sig (intptr).
2024-07-23 14:32:37.524120+0200 IvansApp[12711:20244208] error: * Assertion at /Users/ivan/repos/runtime-mono-iOS/src/mono/mono/mini/interp/interp.c:2667, condition `is_ok (error)' not met, function:init_jit_call_info, Attempting to JIT compile method '(wrapper other) void object:gsharedvt_out_sig (intptr)' while running in aot-only mode. See https://learn.microsoft.com/xamarin/ios/internals/limitations for more information.
```
To track down why these wrappers which are used to transition from
interpreter to AOT code, are not generated we need to understand when
they are compiled in different AOT modes with and without dedup
optimization enabled:
- In full AOT setup - all assemblies AOT compiled
- `gsharedvt_out_sig` methods are never generated
- In hybrid AOT + interpreter setup - all assemblies AOT compiled:
`MtouchInterpreter=-all`
- Dedup OFF:
- `gsharedvt_out_sig` methods are generated in AOT images of every
assembly (to enable interpreter calling into each specific assembly -
here wrappers with same signatures are duplicated)
- Dedup ON:
- `gsharedvt_out_sig` methods are generated only in `aot-instances` AOT
image
- during AOT compilation of individual assemblies generation of
`gsharedvt_out_sig` is skipped
- during AOT compilation of `aot-instances` assembly we collect all
`gsharedvt_out_sig` variants from the full program scope and generate
code for them in `aot-instances` AOT image
- In hybrid AOT + interpreter setup - all assemblies interpreted except
a given assembly: `MtouchInterpreter=all,-MyAssembly`
- Dedup OFF:
- `gsharedvt_out_sig` methods are generated in AOT image of `MyAssembly`
(to enable interpreter calling into it)
- Dedup ON: <- $${\color{red} ISSUE }$$
- `gsharedvt_out_sig` methods *should* be generated only in
`aot-instances` AOT image, but the `aot-instances` image is missing
- explanation:
- what happens is that generation of `gsharedvt_out_sig` is skipped
during AOT compilation of `MyAssembly` (as expected).
- But, the build does not mark `aot-instances` assembly as the one that
should be AOT compiled.
- The reason for this is that we have a global `_IsDedupEnabled` flag,
but when custom linker step analysis `aot-instances.dll` it does not see
it as an assembly which should not be interpreted.
- To explain that better: we mark *all* assemblies as to be interpreted
(via: `MtouchInterpreter=all`), but exclude only `MyAssembly` (via:
`MtouchInterpreter=all,-MyAssembly`).
- So when custom linker step processes `aot-instaces.dll` it treats it
as an assembly to be interpreted, so it does not mark it for AOT
compilation.
- This further results with `aot-instances` AOT image missing, and all
the methods which we skipped during AOT compilation never get generated.
## The fix
To fix this and address regressions reported in:
https://github.com/xamarin/xamarin-macios/issues/20848 we are reenabling
dedup optimization whenever AOT compilation is requested and fixing the
issue where the custom linker step for generating AOT parameters always
treates the dedup assembly as the one to be AOTed.
Once approved this should be backported to .NET 8 as servicing releases
are also affected with it.
---------
Co-authored-by: Ivan Povazan <ivan.povazan@gmail.com>
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
This pull request updates the following dependencies
[marker]: <> (Begin:3727984b-7a79-4ba3-37dd-08dbe6bddf31)
## From https://github.com/dotnet/sdk
- **Subscription**: 3727984b-7a79-4ba3-37dd-08dbe6bddf31
- **Build**: 20240725.4
- **Date Produced**: July 25, 2024 11:31:03 AM UTC
- **Commit**: 8fcbaac1e96fa740af46c9e766c5a4d54e59fe75
- **Branch**: refs/heads/main
[DependencyUpdate]: <> (Begin)
- **Updates**:
- **VS.Tools.Net.Core.SDK.Resolver**: [from 9.0.100-preview.7.24361.1 to
9.0.100-preview.7.24375.4][42]
- **Microsoft.NET.ILLink.Tasks**: [from 9.0.0-preview.7.24357.2 to
9.0.0-preview.7.24366.18][43]
- **Microsoft.AspNetCore.App.Ref**: [from 9.0.0-preview.7.24360.7 to
9.0.0-rc.1.24374.2][44]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-preview.7.24357.2 to
9.0.0-preview.7.24366.18][43]
-
**Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**:
[from 9.0.0-preview.7.24319.4 to 9.0.0-preview.7.24365.1][45]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-preview.7.24357.2 to
9.0.0-preview.7.24366.18][43]
[42]: 81ac886071...8fcbaac1e9
[43]: 4e278fe17f...1f70f0cc66
[44]:
71b5ef3f5c...e7fa345782
[45]: ffe9afdc04...99ea0c06b8
[DependencyUpdate]: <> (End)
[marker]: <> (End:3727984b-7a79-4ba3-37dd-08dbe6bddf31)
[marker]: <> (Begin:Coherency Updates)
## 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)
[DependencyUpdate]: <> (Begin)
- **Coherency Updates**:
- **Microsoft.NET.ILLink.Tasks**: from 9.0.0-preview.7.24357.2 to
9.0.0-preview.7.24366.18 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.AspNetCore.App.Ref**: from 9.0.0-preview.7.24360.7 to
9.0.0-rc.1.24374.2 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-preview.7.24357.2 to
9.0.0-preview.7.24366.18 (parent: VS.Tools.Net.Core.SDK.Resolver)
-
**Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**:
from 9.0.0-preview.7.24319.4 to 9.0.0-preview.7.24365.1 (parent:
Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-preview.7.24357.2 to
9.0.0-preview.7.24366.18 (parent: VS.Tools.Net.Core.SDK.Resolver)
[DependencyUpdate]: <> (End)
[marker]: <> (End:Coherency Updates)
---------
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: GitHub Actions <github-actions@xamarin.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Alex Soto <alex@soto.dev>
## Description
As part of the fix for: https://github.com/dotnet/runtime/issues/99248
we disabled dedup optimization in partial/hybrid AOT mode (when both
interpreter and AOT compiler are enabled). This change got backported to
.NET 8 and with the latest servicing release regressed build times and
app sizes significantly as reported in:
https://github.com/xamarin/xamarin-macios/issues/20848
However, it turns out that disabling dedup optimization is not required
to fix https://github.com/dotnet/runtime/issues/99248 but instead we
should correct the Xamarin SDK integration with this optimization which
this PR is doing. The following section describes the initial problem in
more details.
## Overview of AOT modes and dedup optimization
When the repro project from
https://github.com/dotnet/runtime/issues/99248 is built with dedup
enabled in hybrid AOT+interpreter mode, the app crashes with:
```
024-07-23 14:32:37.524110+0200 IvansApp[12711:20244208] debug: AOT NOT FOUND: (wrapper other) object:gsharedvt_out_sig (intptr).
2024-07-23 14:32:37.524120+0200 IvansApp[12711:20244208] error: * Assertion at /Users/ivan/repos/runtime-mono-iOS/src/mono/mono/mini/interp/interp.c:2667, condition `is_ok (error)' not met, function:init_jit_call_info, Attempting to JIT compile method '(wrapper other) void object:gsharedvt_out_sig (intptr)' while running in aot-only mode. See https://learn.microsoft.com/xamarin/ios/internals/limitations for more information.
```
To track down why these wrappers which are used to transition from
interpreter to AOT code, are not generated we need to understand when
they are compiled in different AOT modes with and without dedup
optimization enabled:
- In full AOT setup - all assemblies AOT compiled
- `gsharedvt_out_sig` methods are never generated
- In hybrid AOT + interpreter setup - all assemblies AOT compiled:
`MtouchInterpreter=-all`
- Dedup OFF:
- `gsharedvt_out_sig` methods are generated in AOT images of every
assembly (to enable interpreter calling into each specific assembly -
here wrappers with same signatures are duplicated)
- Dedup ON:
- `gsharedvt_out_sig` methods are generated only in `aot-instances` AOT
image
- during AOT compilation of individual assemblies generation of
`gsharedvt_out_sig` is skipped
- during AOT compilation of `aot-instances` assembly we collect all
`gsharedvt_out_sig` variants from the full program scope and generate
code for them in `aot-instances` AOT image
- In hybrid AOT + interpreter setup - all assemblies interpreted except
a given assembly: `MtouchInterpreter=all,-MyAssembly`
- Dedup OFF:
- `gsharedvt_out_sig` methods are generated in AOT image of `MyAssembly`
(to enable interpreter calling into it)
- Dedup ON: <- $${\color{red} ISSUE }$$
- `gsharedvt_out_sig` methods *should* be generated only in
`aot-instances` AOT image, but the `aot-instances` image is missing
- explanation:
- what happens is that generation of `gsharedvt_out_sig` is skipped
during AOT compilation of `MyAssembly` (as expected).
- But, the build does not mark `aot-instances` assembly as the one that
should be AOT compiled.
- The reason for this is that we have a global `_IsDedupEnabled` flag,
but when custom linker step analysis `aot-instances.dll` it does not see
it as an assembly which should not be interpreted.
- To explain that better: we mark *all* assemblies as to be interpreted
(via: `MtouchInterpreter=all`), but exclude only `MyAssembly` (via:
`MtouchInterpreter=all,-MyAssembly`).
- So when custom linker step processes `aot-instaces.dll` it treats it
as an assembly to be interpreted, so it does not mark it for AOT
compilation.
- This further results with `aot-instances` AOT image missing, and all
the methods which we skipped during AOT compilation never get generated.
## The fix
To fix this and address regressions reported in:
https://github.com/xamarin/xamarin-macios/issues/20848 we are reenabling
dedup optimization whenever AOT compilation is requested and fixing the
issue where the custom linker step for generating AOT parameters always
treates the dedup assembly as the one to be AOTed.
Once approved this should be backported to .NET 8 as servicing releases
are also affected with it.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
fixes: https://github.com/dotnet/maui/issues/23577
## Cause:
`MtouchInterpreter` is set as
d1ec7a793f/msbuild/Xamarin.Shared/Xamarin.Shared.props (L308)
`DynamicCodeSupport` is set by
d1ec7a793f/dotnet/targets/Xamarin.Shared.Sdk.targets (L146)
`Xamarin.Shared.Sdk.targets` is imported *before* `Xamarin.Shared.props`
as shown below (courtesy of @ivanpovazan)
<img
src="https://github.com/user-attachments/assets/c97b7f01-2372-4f9d-bedf-83060eed1c50">
so unless the value of `MtouchInterpreter` is set in the project, it's
value will be empty when the `DynamicCodeSupport` property is evaluated.
## Resolution:
To minimize the impact of this change, until it can be investigated more
fully, the value of `MtouchInterpreter` is evaluated as
d1ec7a793f/msbuild/Xamarin.Shared/Xamarin.Shared.props (L308)
So adding `( '$(MtouchInterpreter)' == '' And '$(UseInterpreter)' ==
'false' )` to the definition of `DynamicCodeSupport` to match the
`MtouchInterpreter` definition.
A further fix might be to either:
1. Reorder the imports so that the props are included before the
targets, although the ramifications of that change could be significant
2. Move the definition of `DynamicCodeSupport` to
`Xamarin.Shared.props`. This at first glance seems to be less
significant than 1) but would need review and testing.
---------
Co-authored-by: Ivan Povazan <55002338+ivanpovazan@users.noreply.github.com>
### Description
This PR enables building app extensions with NativeAOT.
App extensions are class libraries and to build them with NativeAOT we
must not specify `CustomNativeMain=true`. If we do, ILC would expect
that the input assembly has a managed Main as the module entry point.
Additionally, when building class libraries (with the absence of a
managed Main entry point), our static reference from:
2e5ef1eb1c/runtime/nativeaot-bridge.m (L39)
requires build-time symbol resolution. To avoid linking errors, we
generate an empty `__managed__Main`
in the native bootstrapping code of the app extension (e.g., in
`main.arm64.mm`).
### Testing
The unit tests have been introduced to test building app extensions with
both Mono and NativeAOT.
Executing an iOS app TodayExtension built with NativeAOT has been
verified manually on an actual device.
---
Fixes: https://github.com/xamarin/xamarin-macios/issues/20653
This also required some changes to the generation of the workload
manifest files, since the Xcode 15.4 packages support multi-targeting.
---------
Co-authored-by: Alex Soto <alex@soto.dev>
VS MobileTools Engineering Service 2
Rolf Bjarne Kvinge
Alex Soto
Peter Collins
Ivan Povazan
Michael Cummings (MSFT)
dotnet-maestro[bot]
Alex Soto
Meri Khamoyan