In Xamarin.Mac we have some code to support unusual ways of creating app
bundles while including Xamarin.Mac, and also dynamic loading of the Mono
runtime.
In .NET, we don't support these unusual app bundle creating logic for any
platform, and the Mono runtime isn't even an option for macOS, so exclude some
of the corresponding code from .NET.
This fixes a few warnings in NativeAOT about this code not being trimmer-safe.
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 8.0.0-rc.2.23454.12 to 8.0.0-rc.2.23455.8 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: f9b68d84-9c90-4bd0-5499-08db4112d57e
- **Build**: 20230906.6
- **Date Produced**: September 7, 2023 12:12:59 AM UTC
- **Commit**: 476310d94a3f821f8413a213472224729bfd43a8
- **Branch**: refs/heads/release/8.0.1xx
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.100-rc.2.23455.10 to 8.0.100-rc.2.23456.6][3]
- **Microsoft.AspNetCore.App.Ref**: [from 8.0.0-rc.2.23454.12 to 8.0.0-rc.2.23455.8][4]
[3]: 096a36b4b2...476310d94a
[4]: 51367f6a3e...2772a78349
We have numerous methods that we should never end up executing when using
NativeAOT, in particular methods called from native code.
Ideally we'd be able to link these away completely, but that's a much larger
refactoring, so in the meantime we can do something simpler: just throw an
exception in these methods if using NativeAOT.
There are two advantages:
* Smaller apps.
* No warnings from NativeAOT about these methods doing things that aren't
trimmer-safe.
Contributes towards https://github.com/xamarin/xamarin-macios/issues/18629.
Warn when we detect that the app developer is trying to link with a static
library when using Hot Restart, because we don't support linking with static
libraries in that case.
Also change the resource generation for Xamarin.iOS.Tasks.Windows project to
generate the code-behind for the resources during the build (as opposed to by
the IDE - which won't happen unless using an IDE, while the build will always
happen).
Fixes https://github.com/xamarin/xamarin-macios/issues/17640.
This is the pull request automatically created by the OneLocBuild task
in the build process to check-in localized files generated based upon
translation source files (.lcl files) handed-back from the downstream
localization pipeline. If there are issues in translations, visit
https://aka.ms/icxLocBug and log bugs for fixes. The OneLocBuild wiki is
https://aka.ms/onelocbuild and the localization process in general is
documented at https://aka.ms/AllAboutLoc.
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 8.0.0-rc.2.23453.2 to 8.0.0-rc.2.23454.12 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: f9b68d84-9c90-4bd0-5499-08db4112d57e
- **Build**: 20230905.10
- **Date Produced**: September 6, 2023 7:15:30 AM UTC
- **Commit**: 096a36b4b25ee54d00938076f467f3696a295104
- **Branch**: refs/heads/release/8.0.1xx
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.100-rc.2.23454.1 to 8.0.100-rc.2.23455.10][1]
- **Microsoft.AspNetCore.App.Ref**: [from 8.0.0-rc.2.23453.2 to 8.0.0-rc.2.23454.12][2]
[1]: d511823dcc...096a36b4b2
[2]: 7ac89ddffb...51367f6a3e
Multi targetting is described here:
https://github.com/xamarin/xamarin-macios/blob/main/docs/multi-target-framework.md
This change implements support for:
* Building using the first .NET 7 packages we shipped.
* Building using the last .NET 7 packages we've shipped.
In both cases by specifying the OS version in the target framework.
Additionally adding support for any other API/OS version is trivial: it's just
a matter of listing the corresponding versions in a few files (this is
particularly interesting to add support for preview versions).
It does so by:
* Renaming the ref, sdk and runtime packs to contain the target framework and
the target platfrom version, so the packages will now be named:
* iOS
* Microsoft.iOS.Sdk.net8.0_16.4
* Microsoft.iOS.Ref.net8.0_16.4
* Microsoft.iOS.Runtime.ios-arm64.net8.0_16.4
* Microsoft.iOS.Runtime.iossimulator-arm64.net8.0_16.4
* Microsoft.iOS.Runtime.iossimulator-x64.net8.0_16.4
* tvOS
* Microsoft.tvOS.Sdk.net8.0_16.4
* Microsoft.tvOS.Ref.net8.0_16.4
* Microsoft.tvOS.Runtime.ios-arm64.net8.0_16.4
* Microsoft.tvOS.Runtime.iossimulator-arm64.net8.0_16.4
* Microsoft.tvOS.Runtime.iossimulator-x64.net8.0_16.4
* Mac Catalyst
* Microsoft.MacCatalyst.Sdk.net8.0_16.4
* Microsoft.MacCatalyst.Ref.net8.0_16.4
* Microsoft.MacCatalyst.Runtime.maccatalyst-x64.net8.0_16.4
* Microsoft.MacCatalyst.Runtime.maccatalyst-arm64.net8.0_16.4
* macOS
* Microsoft.macOS.Sdk.net8.0_13.3
* Microsoft.macOS.Ref.net8.0_13.3
* Microsoft.macOS.Runtime.osx-x64.net8.0_13.3
* Microsoft.macOS.Runtime.osx-arm64.net8.0_13.3
* Updating the WorkloadManifest.json and WorkloadManifest.targets files to
load the correct packs according to the TargetFramework in the developer's
project.
* We're also now giving a better error message for invalid/unsupported/eol'ed
target frameworks. Fixes https://github.com/xamarin/xamarin-macios/issues/18790.
* Add a few tests.
Fixes:
* https://github.com/xamarin/xamarin-macios/issues/18790.
* https://github.com/dotnet/sdk/issues/30103.
* https://github.com/xamarin/xamarin-macios/issues/16802.
Contributes towards:
* https://github.com/xamarin/xamarin-macios/issues/18343.
We have a few different implementations of how to compute a set or array of NSString
constants from an enum value, and also computing an enum value from a set or array
of NSString constants.
So add support to the generator for generating a ToArray and a ToFlags method for
these conversions, and remove all the manual code.
This has a few advantages:
* The generated code is automatically updated with new enum fields (not all previous
implementations were).
* Reduces code duplication.
* Reduces manual code.
Additionally, when computing between a group of constants and the corresponding flags,
we have to handle any missing constants or flags gracefully, otherwise the code won’t
be forward compatible.
Example (from bug #18833):
* App developer writes code to fetch the AVCaptureMetadataOutput.AvailableMetadataObjectTypes
property, which is an enum value of flags.
* App developer ships their app in the app store.
* Apple releases a new iOS update, adding new values and constants to the enum.
* The native [AVCaptureMetadataOutput availableMetadataObjectTypes] method returns
these new constants.
* This means that if the AVCaptureMetadataOutput.AvailableMetadataObjectTypes property
throws an exception if encountering unknown constants, our API wouldn’t be forward
compatible.
* The correct solution here is that AVCaptureMetadataOutput.AvailableMetadataObjectTypes
must ignore any constants it doesn’t know about.
Fixes https://github.com/xamarin/xamarin-macios/issues/18833.
This PR implements a workaround for the following build warning:
```
ILC: Method '[Microsoft.iOS]Foundation.NSObject.RegisterToggleRef(NSObject,native int,bool)' will always throw because:
Invalid IL or CLR metadata in 'Void Foundation.NSObject.RegisterToggleRef(Foundation.NSObject, IntPtr, Boolean)'
```
Ref #18524
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-rc.2.23426.4 to 8.0.0-rc.2.23431.9 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 8.0.0-rc.2.23425.11 to 8.0.0-rc.2.23453.2 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-rc.2.23426.4 to 8.0.0-rc.2.23431.9 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-rc.2.23426.4 to 8.0.0-rc.2.23431.9 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.DotNet.Cecil**: from 0.11.4-alpha.23421.1 to 0.11.4-alpha.23428.2 (parent: Microsoft.NETCore.App.Ref)
## From https://github.com/dotnet/installer
- **Subscription**: f9b68d84-9c90-4bd0-5499-08db4112d57e
- **Build**: 20230904.1
- **Date Produced**: September 4, 2023 10:20:53 AM UTC
- **Commit**: d511823dcc3ac2a03333d9572625605d2a9929ab
- **Branch**: refs/heads/release/8.0.1xx
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.100-rc.2.23428.11 to 8.0.100-rc.2.23454.1][17]
- **Microsoft.NET.ILLink.Tasks**: [from 8.0.0-rc.2.23426.4 to 8.0.0-rc.2.23431.9][18]
- **Microsoft.AspNetCore.App.Ref**: [from 8.0.0-rc.2.23425.11 to 8.0.0-rc.2.23453.2][19]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-rc.2.23426.4 to 8.0.0-rc.2.23431.9][18]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-rc.2.23426.4 to 8.0.0-rc.2.23431.9][18]
- **Microsoft.DotNet.Cecil**: [from 0.11.4-alpha.23421.1 to 0.11.4-alpha.23428.2][20]
[17]: b0336e3edc...d511823dcc
[18]: 4122c63a13...3c48925a6c
[19]: fcc98f5c65...7ac89ddffb
[20]: d412306c15...fa5acbd2cc
This makes it possible to call the generic
Marshal.GetDelegateForFunctionPointer<T> method instead of the non-generic
Marshal.GetDelegateForFunctionPointer method, which is easier for AOT
compilers to handle (no reflection for Marshal.GetDelegateForFunctionPointer<T>).
Contributes towards https://github.com/xamarin/xamarin-macios/issues/18629.
This test uses reflection to figure out if there are any ARConfiguration
subclasses that don't implement a particular method. The reflection usage is
problematic when trimming apps, and this is really what the Cecil tests are
for, so just re-implement the entire tests as a Cecil test.
dotnet-maestro[bot]
Rolf Bjarne Kvinge
Ivan Povazan
Haritha Mohan
Manuel de la Pena
Šimon Rozsíval
VS MobileTools Engineering Service 2
Ivan Povazan