Teach our bgen to ignore those types that have been marked as a rgen
BindingType. The code adds a new smart enum in the sources that should
not be processed by bgen and therefore should not have the smart enum
extension method. You can verify that this is try by looking at the API
diff:
<img width="560" alt="Screenshot 2024-10-15 at 14 58 00"
src="https://github.com/user-attachments/assets/83790ae6-d94a-424f-8f70-e33bde7c4f22">
This has a few advantages:
* We simplify and unify more of our code.
* We have more control over the error reporting / logging behavior.
Additionally:
* Use 'xcrun' to invoke 'metal' and 'metallib' (partial fix for #3931).
* Allow for overriding the path to the command-line tool in question.
* Add support for cancellation.
* Fix nullability.
Fixes https://github.com/xamarin/xamarin-macios/issues/21437.
The existing Objective-C class to request an App Store review (SKStoreReviewController) is deprecated in Xcode 16+, and it doesn't even work on the corresponding OS versions.
The replacement API is Swift-only, but luckily it's a very simple API (just a static method), so it's possible to bind it manually.
This required a few other changes/improvements:
* Add support for Swift code in our runtime.
* Just to keep the changes to a minimum, bump the min OS version for legacy code to match the .NET min OS versions. This is because our build logic uses the legacy min versions when compiling native code (a more involved fix would be to update all the build logic to build native code to use the .NET min OS versions, but that's not the point of this PR, so I took the easy route). Fixes#10659.
I've tested the method locally, and it seems to work fine, but I've still marked
it as experimental for now. There are no unit tests because calling the method will
put up a dialog, which won't work correctly in unit tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/21410.
Fixes https://github.com/xamarin/xamarin-macios/issues/10659.
We are doing the following:
1. Adding the rgen directory with the following solutions:
* Analyzer: Analyzer that will catch errors in the bindings. At the
moment it provides a single error when the BindingTypeAttribute is used
in a nont partial type.
* Analyzer Tests: Allows tests for the analyzer.
* Analyzer Sample: Sample project to test the analyzer.
* Code Generator: A code generator that adds the BindingTypeAttribute to
the compilcation.
* Code Generator Tests: Allows tests for the generator.
* Code Sample: Sample project for the code generator.
2. Make rule to build the roslyn code generator.
3. Makefile changes to add the code generator as part as the second
compilation of the bindings.
This changes add the starting gounds to move to roslyn.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Alex Soto <alex@soto.dev>
This logic was intented to zip up the .NET unit tests to run them on Windows,
but in the end we went with a different approach that doesn't require zipping.
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.
We still need some of the source files from the legacy Mono library, but it's
only a few files, so just add them to the git repo.
Also implement caching of the .NET download, which speeds up clean rebuilds
significantly.
Note: all the files in the `builds/mono-ios-sdk-destdir` are a straight import
from the Mono archive, so those shouldn't need much reviewing (nor will I
change them unless absolutely necessary).
The methods 'GetTraitCollectionWithTraits' and 'GetTraitCollectionByModifyingTraits' takes a callback, but the callback
had the wrong signature.
So introduce a new overload for each of these methods, using a delegate with the correct signature.
Also deprecate 'FromTraitsFromCollections' according to both headers and documentation.
Fixes https://github.com/xamarin/xamarin-macios/issues/21377.
On the bots we're executing with Rosetta, and 'arch' returns 'i386' under
Rosetta, so detect when we're executing under Rosetta, and install the arm64
version of .NET in that case as well.
Also fix a bug in the same area in our tests.
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 allowing the test assemblies to see internals of the task 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 _doesn't work_ is to not merge system assemblies in the
`Xamarin.iOS.Tasks.dll` assembly anymore. `Xamarin.iOS.Tasks.Windows.dll`
already does this, but it doesn't work when building remotely.
* The fix that seems to work is to just not allow the test assemblies to
see the internals of the task assembly. This is really an anti-pattern
anyway, so no big loss. This required a few changes (make some API in
the task assembly public, remove some legacy tests that don't apply
anymore in .NET, etc.)
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.
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.
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.
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
### 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>
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.
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)
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.
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 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>
Because simulator is where we most commonly run tests.
And hardcode arm64 - if x64 is ever needed, and I'm bugged enough to add
auto-detection, I'll do it then.
There's both a Network.NWEndpoint and a NetworkExtension.NWEndpoint, and the
generator generates ambiguous code in certain cases.
Fix the generator to use the full type reference for such types.
Rolf Bjarne Kvinge
Manuel de la Pena
Alex Soto
Peter Collins
Ivan Povazan
Jeremi Kurdek
dotnet-maestro[bot]