* [dotnet] Remove workaround for private symbols for AOT.
* [tools] Make Application.AotArguments a list of string.
This is just a simple refactoring to make Application.AotArguments a list of
strings instead of a comma-separated list of values.
* [tools] Only use direct-icalls when linking mono statically.
Ref: https://github.com/dotnet/runtime/issues/55000
* [mtouch] Fix aot arguments comparison.
* [tests] Adjust mtouch test according to mtouch changes.
* [tests] Add minimum OS version to the Mac Catalyst variation of the MySimpleApp test case.
On CI we'll collect all the binlogs in the repository and make them available
for post-build analysis if need be, so this will make it easier to diagnose
build problems.
Previously we'd only call Runtime.RegisterEntryAssembly in the simulator if
the dynamic registrar was available, but now we may call it on device as well
(still only if the dynamic registrar is available). So modify the linker to
keep Runtime.RegisterEntryAssembly even if we're executing on device, as long
as the dynamic registrar is around.
This ensures we get the same behavior both in the simulator and on device (and
desktop for that matter).
Fixes https://github.com/xamarin/xamarin-macios/issues/12327.
* Add support for Mono Components.
* Modify how we look up symbols from native libraries shipped with Mono: we keep
track of which native libraries we linked with, and depending on how we linked
to those assemblies, we look the symbols up at runtime in either the current executable
(if linking statically), or the actual library (where the P/Invoke says they're
supposed to be).
* This means that we have to propagate how libmono is linked from the MSBuild code
to the Application class so that our existing logic is able to correctly determine
which native mono lib to use.
* Modify how we list the P/Invokes we need to preserve by taking into account the
list of native libraries from Mono we have to link with (for .NET). For legacy
Xamarin, I've reverted the logic to how it was before we started adding .NET support.
Fixes https://github.com/xamarin/xamarin-macios/issues/10950.
Fixes https://github.com/xamarin/xamarin-macios/issues/11145.
Fixes https://github.com/xamarin/xamarin-macios/issues/12100.
In mtouch and mmp's implementation of these functions, they take the assembly
name, not the assembly path.
So for .NET, we'd previouslyget input such as "Xamarin.iOS", think it was a
filename, strip the extension, and compare "Xamarin" to the platform assembly
name, which didn't work.
Fixes https://github.com/xamarin/xamarin-macios/issues/12276.
This makes it possible to preserve embedded debug symbols for a release build:
by passing "--package-debug-symbols=true" to mmp. Previously we'd remove the
symbols unconditionally for release builds.
This also conserves the old behavior (strip symbols in release builds), unless
users have explicitly passed "--package-debug-symbols=true" to mmp (because
PackageManagedDebugSymbols defaults to the same value as EnableDebug).
Fixes https://github.com/xamarin/xamarin-macios/issues/12263.
* A lot of availability attribute updates.
* Some conditional "#if !__MACCATALYST__" in manual binding files.
* xtro updates.
* Misc other minor tweaks.
Commit 2af23dbd introduced a new "Prepare Release" stage that will
sign .NET 6 NuGet packages, and push them to the xamarin-impl feed.
The post build pipeline that pushes build metadata to Maestro for
downstream dependency updating should run after this stage. There is
no reason to push build information to Maestro without also pushing
packages to a feed for external consumption.
* Update dependencies from https://github.com/dotnet/installer build 20210727.4
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21376.3 -> To Version 6.0.100-rc.1.21377.4
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21370.1 -> To Version 6.0.100-preview.6.21376.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Bump Mono.Cecil from 0.11.3 to 0.11.4.
* [dotnet-linker] Reference Mono.Cecil 0.11.4 directly.
Works around https://github.com/mono/linker/issues/2173.
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Add support for the interpreter everywhere.
* Add support for the AOT compiler everywhere we didn't support it before,
because the interpreter needs it (at least System.Private.CoreLib.dll must
be AOT-compiled when using the interpreter).
* Do FullAOT compilation on Mac Catalyst/ARM64 if we're not using the
interpreter, since we can't use the JIT.
* Fix monotouch-test to be green on Mac Catalyst/ARM64.
Fixes https://github.com/xamarin/xamarin-macios/issues/11724.
Fixes https://github.com/xamarin/xamarin-macios/issues/11421.
Using 'direct-pinvoke' will tell the AOT compiler to emit a direct call to the
native function declared in the DllImport, which doesn't work when we want to
redirect to a different native funcion (in our xamarin_pinvoke_override/PINVOKE_OVERRIDE
implementation).
This fixes our exception marshalling tests in monotouch-test.
Fixes these test failures:
Ctor_Trust: System.DllNotFoundException : libSystem.Security.Cryptography.Native.Apple
MailX1: System.DllNotFoundException : libSystem.Security.Cryptography.Native.Apple
Encrypt_Empty: System.DllNotFoundException : libSystem.Security.Cryptography.Native.Apple
KeyRecordTest: System.DllNotFoundException : libSystem.Security.Cryptography.Native.Apple
Basic_Leaf_Only: System.DllNotFoundException : libSystem.Security.Cryptography.Native.Apple
which are all because of
Xamarin.MacCatalyst: Unable to resolve P/Invoke 'AppleCryptoNative_X509GetContentType' in the library 'libSystem.Security.Cryptography.Native.Apple'
which happens because without this change we're not linking with the static version
of libSystem.Security.Cryptography.Native.Apple.
This means not listing per-assembly linker flags for only binding projects, but delay
it until we've computed the linker flags for all assemblies (and reflect this in
variable names as well).
The interpreter requires running the AOT compiler for System.Private.CoreLib.dll,
so the first step in implementing the interpreter is to implement support for the
AOT compiler as well.
For .NET the logic is now as follows:
* If the interpreter is enabled, AOT compile System.Private.CoreLib.dll.
* If the interpreter is disabled, AOT everything on device + Mac Catalyst on ARM64.
This also meant propagating how libmono is linked from the MSBuild code to the Application
class so that our existing logic is able to correctly determine which native mono
lib to use.
Context: xamarin/yaml-templates#117
Updates the .NET 6 NuGet packaging steps to exclude package metadata,
as the .msi conversion tooling does not process .nupkg file names with
the +sha.commit metadata.
Two new stages have been added to facilitate the Visual Studio setup
authoring process.
The first stage named "Prepare Release" will sign the .NET 6 NuGet
package content (inside and out), convert relevant packages to .msi
installers, generate Visual Studio manifests for the .msi installers,
and push the signed packages to the xamarin-impl feed.
The new SignList.xml file is required for our NuGet signing templates.
The new xamarin-workload.props file contains version information
and other metadata required to generate a Visual Studio manifest.
The second stage starts with a manual validation task. This task
will pause and wait for someone to click a "Resume" or "Reject" button
that will appear on the pipeline UI. This task is configured to be
rejected after waiting for two days, but it can be manually re-ran at a
later date if we want to trigger VS insertion for an older build.
If the manual validation task is approved, a VS Drop will be created
containing all .NET 6 .msi files. This Drop URL can then be used to
update our component versions in Visual Studio. This last piece is
currently manual as we will initially be introducing new components,
however we should be able to automate VS PR creation in the future.
Commit 09f911b missed adding the
PR build check condition to a step in sign-and-notarized.yml, causing
PR builds from forks to fail. We can fix this by adding in the missing
condition.
* Add proper .NET project files for dont link, link sdk and link all. This
includes a Mac Catalyst variant, and adding helpful Makefile targets for
simple execution.
* Adjust various tests to work with Mac Catalyst.
* Add the new Mac Catalyst variants to xharness.
This is a partial fix for #10833.
Context: https://github.com/xamarin/yaml-templates/pull/117
Updates the .NET 6 NuGet packaging steps to exclude package metadata,
as the .msi conversion tooling does not process .nupkg file names with
the `+sha.commit` metadata.
Two new stages have been added to facilitate the Visual Studio setup
authoring process.
The first stage named "Prepare Release" will sign the .NET 6 NuGet
package content (inside and out), convert relevant packages to .msi
installers, generate Visual Studio manifests for the .msi installers,
and push the signed packages to the `xamarin-impl` feed.
The new `SignList.xml` file is required for our NuGet signing templates.
The new `xamarin-workload.props` file contains version information
and other metadata required to generate a Visual Studio manifest.
The second stage starts with a [manual validation task][0]. This task
will pause and wait for someone to click a "Resume" or "Reject" button
that will appear on the pipeline UI. This task is configured to be
rejected after waiting for two days, but it can be manually re-ran at a
later date if we want to trigger VS insertion for an older build.
If the manual validation task is approved, a VS Drop will be created
containing all .NET 6 .msi files. This Drop URL can then be used to
update our component versions in Visual Studio. This last piece is
currently manual as we will initially be introducing new components,
however we should be able to automate VS PR creation in the future.
[0]: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/manual-validation?view=azure-devops&tabs=yaml
So that the ComputeAOTArguments can compute the llvm-path value to pass to the AOT
compiler (the llvm-path value states where the opt and llc command-line tools are,
and they're next to the AOT compiler).
Rolf Bjarne Kvinge
Manuel de la Pena
TJ Lambert
VS MobileTools Engineering Service 2
Peter Collins
dotnet-maestro[bot]
Sebastien Pouliot