Remove the following warning:
```
make[3]: warning: -jN forced in submake: disabling jobserver mode.
/Applications/Xcode_13.0.0-beta5.app/Contents/Developer/usr/bin/make -C ../../../maccore/tools/mlaunch install -j8
make[3]: warning: -jN forced in submake: disabling jobserver mode.
/Applications/Xcode_13.0.0-beta5.app/Contents/Developer/usr/bin/make
../../_build/Microsoft.iOS.Sdk/tools/bin/mlaunch
../../_build/Microsoft.tvOS.Sdk/tools/bin/mlaunch
```
There is no need to pass the number of jobs to be used to a submake
commands as per the gnu make documentation:
```
The ‘-j’ option is a special case (see Parallel Execution). If you set it to some numeric value ‘N’ and your operating system supports it (most any UNIX system will; others typically won’t), the parent make and all the sub-makes will communicate to ensure that there are only ‘N’ jobs running at the same time between them all. Note that any job that is marked recursive (see Instead of Executing Recipes) doesn’t count against the total jobs (otherwise we could get ‘N’ sub-makes running and have no slots left over for any real work!)
```
That means there is not need to pass it since it will be the default
used in submake commands. The override has not effect other the warning
and therefore is better to remove the noise.
When checking if we need to manually preserve a native symbol, we need to
check if a P/Invoke matches both static and dynamic libraries from the Mono
runtime, not just dynamic libraries.
P/Invokes may point to a dylib, while the actual library linked into the .app
might be a static library, so make sure to compare without the extension.
This fixes an issue when linking with the static version of the runtime libraries.
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@9e6e29f [Xamarin.MacDev] Return valid iOS/macOS versions when converting betweeen iOS and macOS versions for Mac Catalyst.
Diff: 41d91e0de0..9e6e29f2a4
Fixes this test failure when running monotouch-test with the dynamic registrar and
linking has been enabled:
MonoTouchFixtures.ObjCRuntime.RegistrarTest
[FAIL] TestProtocolRegistration : UIApplicationDelegate/17669
Expected: True
But was: False
This is a port of what we do during linking for legacy Xamarin apps.
Ref: 682f54da87
Fixes https://github.com/xamarin/xamarin-macios/issues/12644.
* [dotnet-linker] Remove workaround for a dotnet/runtime issue wrt the AOT compiler.
The dotnet/runtime issue has been fixed.
Ref: https://github.com/dotnet/runtime/issues/55733
* [tests] Set the _BundlerVerbosity property instead of MtouchExtraArgs/MonoBundlingExtraArgs to increase verbosity.
This fixes a problem where a test project would try to set the
MtouchExtraArgs/MonoBundlingExtraArgs properties, and it would fail because
the MtouchExtraArgs/MonoBundlingExtraArgs properties were already set from the
command line (and in MSBuild, properties that are set from command line
arguments can't be changed later).
In particular we have logic to pass --dlsym:+nunit.framework.dll for
monotouch-test, and that would just be ignored.
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
Instead of something like this:
ILLINK : error MT2362: The linker step 'Registrar' failed during processing: One or more errors occurred. (The registrar cannot build a signature for type `Bindings.Test.Sf' in method `Sf()`.
) (The registrar cannot build a signature for type `Bindings.Test.Sf' in method `Sf_invoke()`. (TaskId:208)
) (The registrar cannot build a signature for type `Bindings.Test.Sdldl' in method `get_PSdldl()`. (TaskId:208)
) (The registrar cannot build a signature for type `Bindings.Test.Sdldl' in method `Bindings.Test.ObjCRegistrarTest.set_PSdldl`. (TaskId:208)
) (The registrar cannot build a signature for type `Bindings.Test.Sf' in method `get_PSf()`. (TaskId:208)
) (The registrar cannot build a signature for type `Bindings.Test.Sf' in method `Bindings.Test.ObjCRegistrarTest.set_PSf`. (TaskId:208)
) (The registrar cannot build a signature for type `Bindings.Test.Sff' in method `get_PSff()`. (TaskId:208)
) (The registrar cannot build a signature for type `Bindings.Test.Sff' in method `Bindings.Test.ObjCRegistrarTest.set_PSff`. (TaskId:208)
) (The registrar cannot build a signature for type `Bindings.Test.Sfff' in method `get_PSfff()`. (TaskId:208)
) (The registrar cannot build a signature for type `Bindings.Test.Sfff' in method `Bindings.Test.ObjCRegistrarTest.set_PSfff`. (TaskId:208)
) (The registrar cannot build a signature for type `Bindings.Test.Sffff' in method `get_PSffff()`. (TaskId:208)
) (The registrar cannot build a signature for type `Bindings.Test.Sffff' in method `Bindings.Test.ObjCRegistrarTest.set_PSffff`. (TaskId:208)
) (The registrar cannot build a signature for type `Bindings.Test.Sfffff' in method `get_PSfffff()`. (TaskId:208)
) (The registrar cannot build a signature for type `Bindings.Test.Sfffff' in method `Bindings.Test.ObjCRegistrarTest.set_PSfffff`. (TaskId:208)
) (The registrar cannot build a signature for type `Bindings.Test.Sfi' in method `get_PSfi()`. (TaskId:208)
) (The registrar cannot build a signature for type `Bindings.Test.Sfi' in method `Bindings.Test.ObjCRegistrarTest.set_PSfi`. (TaskId:208)
) (The registrar cannot build a signature for type `Bindings.Test.Sfifi' in method `get_PSfifi()`. (TaskId:208)
) (The registrar cannot build a signature for type `Bindings.Test.Sfifi' in method `Bindings.Test.ObjCRegistrarTest.set_PSfifi`. (TaskId:208)
we now get this:
/Users/rolf/work/maccore/dotnet-devicetests/xamarin-macios/tests/bindings-test/dotnet/iOS/obj/Debug/net6.0-ios/iOS/Bindings.Test/ObjCRegistrarTest.g.cs(3072): error MT4111: The registrar cannot build a signature for type `Bindings.Test.Sf' in method `Sf()`.
/Users/rolf/work/maccore/dotnet-devicetests/xamarin-macios/tests/bindings-test/dotnet/iOS/obj/Debug/net6.0-ios/iOS/Bindings.Test/ObjCRegistrarTest.g.cs(3100): error MT4111: The registrar cannot build a signature for type `Bindings.Test.Sf' in method `Sf_invoke()`.
/Users/rolf/work/maccore/dotnet-devicetests/xamarin-macios/tests/bindings-test/dotnet/iOS/obj/Debug/net6.0-ios/iOS/Bindings.Test/ObjCRegistrarTest.g.cs(6112): error MT4111: The registrar cannot build a signature for type `Bindings.Test.Sdldl' in method `get_PSdldl()`.
/Users/rolf/work/maccore/dotnet-devicetests/xamarin-macios/tests/bindings-test/dotnet/iOS/obj/Debug/net6.0-ios/iOS/Bindings.Test/ObjCRegistrarTest.g.cs(6138): error MT4111: The registrar cannot build a signature for type `Bindings.Test.Sdldl' in method `Bindings.Test.ObjCRegistrarTest.set_PSdldl`.
/Users/rolf/work/maccore/dotnet-devicetests/xamarin-macios/tests/bindings-test/dotnet/iOS/obj/Debug/net6.0-ios/iOS/Bindings.Test/ObjCRegistrarTest.g.cs(6149): error MT4111: The registrar cannot build a signature for type `Bindings.Test.Sf' in method `get_PSf()`.
ILLINK : error MT2362: The linker step 'Registrar' failed during processing: One or more errors occurred.
and in addition we'll get stack traces for each inner exception as well
whenever we have verbose mtouch logging enabled.
* Update vs-insertion-prep.yml
* Remove filters from symbol package download as well
* [temp] Changes for testing
* Shorten manifest name
* Shorten manifest name take 2
* Add ComponentResources and WorkloadPackages for tvOS and macOS
* Don't shorten MacCatalyst name, version string replacement should suffice
* Revert "Don't shorten MacCatalyst name, version string replacement should suffice"
This reverts commit d1c1d1d89d.
* Replace long macOS versions in .msi files
* Shorten tvossimulator msi names
* Test with real signing
* Revert testing changes
* Enable tests
Co-authored-by: Peter Collins <pecolli@microsoft.com>
Context: https://github.com/xamarin/yaml-templates/pull/131
Enables conversion and archiving of symbol files during the VS insertion
stage. Symbol archiving steps will only run if both the
`symbolArtifactName` parameter is provided, and `archiveSymbols` is set
to true. The `symbolConversionFilters` parameter can be used to filter
out paths of symbol files that should not be converted/archived.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
How we create the app manifest (Info.plist) has to be modified so that we can
add support for getting all the values from MSBuild properties (i.e. no
Info.plist in the project), as well as having multiple partial app manifests
that all get merged into the final app manifest.
Here's the new process:
1. The user can specify values in multiple ways:
* An Info.plist in their project file (as always, by using a `None` item
with filename "Info.plist" or with a `Link` metadata with filename
"Info.plist"). We find this Info.plist in the DetectAppManifest target.
* A partial plist in their project (using the `PartialAppManifest` item
group)
* Some MSBuild properties can also add values.
The general precedence is: MSBuild properties can be overridden by the
Info.plist, which can be overridden by a partial plist.
2. In the `CompileAppManifest` target we get all the inputs from above, and
compute a temporary app manifest, which is written to a temporary output
file.
3. In the `ReadAppManifest` target, we read the temporary output file and
outputs numerous MSBuild properties (most of them private)
4. We run other targets that may add more entries to the final app manifest
(these tasks might depend on the values from `ReadAppManifest`). These
entries are written to partial plists, and added to the
_PostCompilePartialAppManifest item group.
Currently the targets that can add more entries to the app manifest are
_CompileImageAssets and _CompileCoreMLModels.
5. In the new `WriteAppManifest` target, we read the temporary output file
from `ReadAppManifest` + any `_PostCompilePartialAppManifest` files and
merge them all together to get the final Info.plist.
This also required moving the computation of CFBundleIdentifier from the
DetectSigningIdentity task to the CompileAppManifest task, which also meant
reordering these two tasks, so that the DetectSigningIdentity task is executed
after the CompileAppManifest task (technically after the ReadAppManifest
task), because the DetectSigningIdentity task needs to know the bundle
identifier.
Commit c272040 started pushing both nupkgs and msis to the dotnet6 feed,
however the job dependency was not updated. Since the "Push NuGets" job
consumes packages created by the "Convert NuGet to MSI" job, it must
depend on it.
The `templates/release/vs-insertion-prep.yml` template which includes
package signing and feed publishing should only run against official
branches. The condition has been updated to check the branch name for
`main` or `release/` before running.
How we create the app manifest (Info.plist) has to be modified so that we can add
support for getting all the values from MSBuild properties (i.e. no Info.plist in
the project), as well as having multiple partial app manifests as well, that gets
merged into the final app manifest.
Here's the new process:
1. The user can specify values in multiple ways:
* An Info.plist in their project file (by using a `None` item with
filename "Info.plist" or with a `Link` metadata with filename
"Info.plist"). We figure this out in the DetectAppManifest target.
* A partial plist in their project (using the `PartialAppManifest` item group)
* Some MSBuild properties can also add values.
The precedence is: MSBuild properties can be overridden by the Info.plist,
which can be overridden by a partial plist.
2. In the `CompileAppManifest` target we get all the inputs from above, and compute
a temporary app manifest, which is written to a temporary output file.
3. In the `ReadAppManifest` target, we read the temporary output file and outputs
numerous MSBuild properties (most of then private)
4. We run other targets that may add more entries to the final app manifest (these
tasks might depend on the values from `ReadAppManifest`). These entries are written
to partial plists, and added to the _PostCompilePartialAppManifest item group.
The targets in question are:
* _CompileImageAssets * _CompileCoreMLModels
5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest`
+ any `_PartialAppManfiest` items and merge them all together to get the final Info.plist.
This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity
task to the CompileAppManifest task. This also meant reordering these two tasks,
so that the DetectSigningIdentity task is executed after the CompileAppManifest task
(technically after the ReadAppManifest task), because the DetectSigningIdentity task
needs to know the bundle identifier.
This way we can handle multiple scenarios easily (most of this is not covered by
these changes, and will be implemented separately):
* No Info.plist at all, all non-default values come from MSBuild properties.
* A single Info.plist, where everything is specified.
* An Info.plist with multiple partial app manifests as well.
* [xharness] Add LLVM test case for Mac Catalyst.
* [tests] Add make target to build monotouch-test using LLVM on Mac Catalyst.
* [tools] Pass the right arguments to the AOT compiler for Mac Catalyst. Fixes#12484.
Mac Catalyst is just special.
Fixes https://github.com/xamarin/xamarin-macios/issues/12484.
We should now have the ability to push to the `dotnet6` feed that
contains the rest of the .NET 6 SDK Workload packages. This should help
simplify workload acquisition. The .nupkg files containing .msi the
.msi installers used for VS insertions will also now be pushed to this
feed.
* [Toold] Add editor snippets to help new developers.
We do have a few tings that we have to do manually yet it is repetitive,
I am adding the vscode (soon to come vim) configuration files to provide
useful snippets when working with the bindings.
The syntax of the snippets present is very simple, there are just two
things to understand in these new ones:
1 Tab complitions: $1, $2 etc.. are the tab complitions that the user
can provide. This allows the user to navigate and the snippets engine
will replace all the complitions with the provided text.
2 Options: We can provide options for tab complitions, for example for
the PlatformName, which is a known value. The syntax to do so is
{$1|one,two,three|} where:
* `$1`: is the tab completion.
* `|one,two,three|`: are the options.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Update dependencies from https://github.com/dotnet/installer build 20210805.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21405.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21404.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210806.3
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21406.3
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21405.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210807.3
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21407.3
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21405.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210807.8
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21407.8
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21405.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210808.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21408.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21405.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210809.11
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21409.11
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21409.3 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210811.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21411.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21410.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210811.31
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21411.31
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21411.3 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210812.16
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21412.16
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21412.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210814.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21414.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21413.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210814.5
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21414.5
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21413.1 (parent: Microsoft.Dotnet.Sdk.Internal
* [dotnet-linker] Bump to net6.0.
It doesn't build with net5.0 anymore:
[...]xamarin-macios/tools/dotnet-linker/dotnet-linker.csproj : error NU1202: Package Microsoft.NET.ILLink 6.0.100-preview.6.21413.1 is not compatible with net5.0 (.NETCoreApp,Version=v5.0). Package Microsoft.NET.ILLink 6.0.100-preview.6.21413.1 supports: net6.0 (.NETCoreApp,Version=v6.0)
make[2]: *** [Makefile:23: bin/Debug/net5.0/dotnet-linker.dll] Error 1
make[2]: Leaving directory '[...]xamarin-macios/tools/dotnet-linker'
make[1]: *** [../mk/subdirs.mk:18: all-recurse] Error 1
make[1]: Leaving directory '[...]xamarin-macios/tools'
* Update dependencies from https://github.com/dotnet/installer build 20210815.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21415.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21413.1 (parent: Microsoft.Dotnet.Sdk.Internal
* [dotnet] Disable the template tests.
There were breaking changes upstream, but the path forward hasn't been defined
yet, so disable these tests.
Ref: https://github.com/xamarin/xamarin-macios/issues/12457
* Update dependencies from https://github.com/dotnet/installer build 20210816.45
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21416.45
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21413.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210817.3
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21417.3
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21416.1 (parent: Microsoft.Dotnet.Sdk.Internal
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This also required changing some linker code to not have platform-specific conditional compilation,
because dotnet-linker is built only once for .NET (same binary for all platforms).
Context: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=5074495&view=logs&j=f8a716f9-5318-5935-19a4-149a64409b96&t=773a1aad-99f2-5f0b-eafa-0deb88171543
Context: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1366309
Context: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1366310
Commit 9dbf451d added files required to support Hot Restart in .NET 6
packages, however it did not update SignList.xml to also include these
new file additions. This caused .nupkg signing issues:
C:\a\_temp\artifact-signing\SignFiles.proj(66,5): error : Unknown assemblies:
C:\a\_temp\artifact-signing\SignFiles.proj(66,5): error : C:\a\_temp\artifact-signing\extracted\Microsoft.iOS.Windows.Sdk.15.0.100-ci.main.446\tools\msbuild\iOS\BouncyCastle.Crypto.dll;
C:\a\_temp\artifact-signing\SignFiles.proj(66,5): error : C:\a\_temp\artifact-signing\extracted\Microsoft.iOS.Windows.Sdk.15.0.100-ci.main.446\tools\msbuild\iOS\imobiledevice-x64\bz2.dll;
C:\a\_temp\artifact-signing\SignFiles.proj(66,5): error : C:\a\_temp\artifact-signing\extracted\Microsoft.iOS.Windows.Sdk.15.0.100-ci.main.446\tools\msbuild\iOS\imobiledevice-x64\getopt.dll;
C:\a\_temp\artifact-signing\SignFiles.proj(66,5): error : C:\a\_temp\artifact-signing\extracted\Microsoft.iOS.Windows.Sdk.15.0.100-ci.main.446\tools\msbuild\iOS\imobiledevice-x64\ideviceactivation.dll;
...
Fix signing by listing all new content that should be skipped or signed
with first/third party certs.
Additionally, content in nested .zip files also needs to be signed. I've
added a couple of targets to SignList.targets to unzip and rezip these
files before and after individual file signing runs.
We extract frameworks from third-party libraries when running the linker, and
we need to store this information on disk and the reload it after the linker
has executed, and add it to the existing MSBuild variables that keep track of
the user frameworks and dynamic libraries that have to be copied to the app
bundle.
Fixes the framework-test tests.
when (by default)
* the interpreter is not enabled (since new code might subclass or override the members analyzed at build time)
* building for release
Reverts c56b893b68
Fix https://github.com/xamarin/xamarin-macios/issues/9573
Notes
* Even if possible (in metadata) there is no point in setting `final` on
a method if we remove `virtual`. This match ILLink version of the sealer
and makes the same test pass on both.
* Don't apply optimization on non-AOT builds, e.g. simulators, since some
features (like XML serialization) checks for
`RuntimeFeature.IsDynamicCodeSupported` and that requires some types
to be subclassed thru SRE
* [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).
Add support for universal / fat apps for iOS, macOS and Mac Catalyst.
We detect if we need to build a universal app by checking if `RuntimeIdentifiers` (plural) is set, and in that case we do a complete inner build for every `RuntimeIdentifier`, and then once those inner builds are done, we merge the resulting .app bundles together (using a new MSBuild task called `MergeAppBundles`).
When merging app bundles together, we'll run into files that exist in both apps. Depending on the file type, we do different things:
* MachO flies: lipo'ed together.
* Managed assemblies: we do a binary comparison, if the assemblies are different, we put them in a RID-specific subdirectory. At runtime we know to look for assemblies in this directory.
* runtimeconfig.bin, icudt.dat: put in a RID-specific subdirectory.
* Info.plist: computed in the outer (fat) build, the one from the inner build is ignored.
* Other files: for identical files we just copy one, otherwise we show an error.
If we run into files that are different between apps, but we should handle somehow, then we'll have to decide on a case-to-case basis what to do.
Some code shuffling was required to increase code sharing between the tools/ code, the msbuild/ code, and tests.
I've also added support for a default `RuntimeIdentifier`.
Fixes https://github.com/xamarin/xamarin-macios/issues/10294.
Fixes https://github.com/xamarin/xamarin-macios/issues/10861.
* Having .NET enabled with the windows-specific parts disabled is not a
scenario tested on CI (where we've always enabled both). This means it's
prone to bitrotting.
* It's another configuration to keep track of and make work locally.
* It doesn't work right now anyway.
So just always enable the windows-specific parts of the .NET build, if the
.NET build is enabled.
* [tools] Fix quoting quotes in StringUtils.QuoteForProcess.
Previously quoting a string with a quote:
a"b
would result in:
"a\"""b"
There are way too many quotes there.
We'll now get:
"a\"b"
which is correct.
* Add unit test.
Developers will now get the helpful:
> error MM0051: Xamarin.Mac 7.99.0 requires Xcode 12.0 or later. The current Xcode version (found in /Applications/Xcode_11.7.app/Contents/Developer) is 11.7.
instead of:
> error MM5309: Failed to execute the tool 'clang', it failed with an error code '1'. Please check the build log for details.
(and no clue from the build log that they need to upgrade their Xcode).
Xamarin.iOS projects still build fine with at least Xcode 11.3.1, so I've only
updated the minimum Xcode version for Xamarin.Mac.
Fixes https://github.com/xamarin/xamarin-macios/issues/11937.
This was allowed to ease existing (3rd party) code migration into net6.
However the reverse can also happen: trying to use net6 code with the
legacy SDK. In such case it's possible other (newer) attributes are being
used to preserve members.
ref: https://github.com/dotnet/aspnetcore/issues/33269
The Build.SourceBranchName variable is documented to be the last segment of
the git ref. If the git ref is 'refs/heads/main', then Build.SourceBranchName
is 'main' (as expected). However, if the git ref is
'refs/heads/release/6.0.1xx-preview5', then Build.SourceName is
'6.0.1xx-preview5', and that's not what we want.
Instead use the Build.SourceBranch variable, which is the entire git ref, and
then we strip out the 'refs/heads/' part from the beginning. This way we get
the correct branch name.
* Bump maccore.
New commits in xamarin/maccore:
* xamarin/maccore@9acbbed1f6 [mlaunch] Add support for Xcode 13 beta 1. (#2452)
* xamarin/maccore@e48f75c0b6 [Xamarin.Hosting] Fix the --stdout arg not being forwarded to DeviceLaunchConfig (#2435)
* xamarin/maccore@109c695b1b [Xamarin.Hosting] Fix help string for launchdev argument (#2429)
Diff: cddbd1915d..9acbbed1f6
* [xtro] Fix generation of .pch files
* [xtro] Fix deprecated check to handle (anonymous) declarations and enable latest C# syntax in project
* [xtro] Fix _sanity_ checks
* [xtro] Update todo for beta 1
* [Siminstaller] Force siminstaller to use the xcode 12.5 url
Related issue: https://github.com/xamarin/xamarin-macios/issues/11881
* Fix introspection failures (due to [breaking] changes)
* [tests][intro] Fix hang for tvOS
Creating an instance of `NSMetadataQuery` hangs the simulator.
Even after (xharness) timeout the simulator is not in a good state
to run further tests and every new (tvOS) test will also hang...
* [tests][intro] Same hang for watchOS
except that further test execution does not seem affected (like tvOS)
```
CoreSimulator 772.1 - Device: Apple Watch Series 3 - 38mm (watchOS 8.0) - created by XHarness (42262867-E060-40C0-803E-6DA676AF50CC) - Runtime: watchOS 8.0 (19R5266p) - DeviceType: Apple Watch Series 3 - 38mm
Thread 0 Crashed:: tid_103 Dispatch queue: com.apple.main-thread
0 com.apple.Foundation 0x00007fff21470bd0 -[NSMetadataQuery dealloc] + 432
1 libobjc.A.dylib 0x00007fff200d11f7 objc_object::sidetable_release(bool, bool) + 177
2 com.apple.Foundation 0x00007fff21470a03 -[NSMetadataQuery init] + 64
3 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107efc139 xamarin_dyn_objc_msgSend + 217 (trampolines-x86_64-objc_msgSend.s:15)
4 ??? 0x000000010c76d4f6 0 + 4504081654
5 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107cffc85 mono_jit_runtime_invoke + 1621 (mini-runtime.c:3197)
6 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107e177d8 do_runtime_invoke + 54 (object.c:3052) [inlined]
7 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107e177d8 mono_runtime_invoke_checked + 136 (object.c:3220)
8 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107e1e3c5 mono_runtime_try_invoke_array + 2101 (object.c:5601)
9 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107daf977 ves_icall_InternalInvoke + 871 (icall.c:3927)
10 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107dc0167 ves_icall_InternalInvoke_raw + 103 (icall-def.h:667)
11 ??? 0x000000010a232799 0 + 4465043353
12 ??? 0x000000010c76e08b 0 + 4504084619
```
* [tests][monotouch-test] Fix failures with xcode 13 beta 1
* [tests][mmptest] Use a FAT framework that's build with x86_64 and arm64
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Only the `SanitizeObjectiveCName` method _can_ be needed, by the
registrar. However if marked then the `StringUtils:.cctor` will also be
marked, including the data (`static char[]`) which is not needed for apps
Moving `SanitizeObjectiveCName` to the `Registrar` type is simpler and
solve (removes) the extra cost (baggage) from the app.
* making sure new strings get added to designer and resources plus the test
* Next wave of changes to csproj to incorporate Rolf's changes
* fixing path
* Update tests/msbuild/Xamarin.MacDev.Tasks.Tests/TaskTests/LocalizationStringTest.cs
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Update tests/mtouch/LocalizationTests.cs
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* forgot the include
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
We have to list each readme as per vsts docs:
```
Tips:
* Wild cards are not supported with path filters.
* Paths are always specified relative to the root of the repository.
* If you don't set path filters, then the root folder of the repo is implicitly included by default.
* If you exclude a path, you cannot also include it unless you qualify it to a deeper folder. For example if you exclude /tools then you could include /tools/trigger-runs-on-these
* The order of path filters doesn't matter.
* Paths in Git are case-sensitive. Be sure to use the same case as the real folders.
* You cannot use variables in paths, as variables are evaluated at runtime (after the trigger has fired).
```
src: https://docs.microsoft.com/en-us/azure/devops/pipelines/repos/github?view=azure-devops&tabs=yaml#ci-triggers
We added the github pages to make the life of the reviews easier, the
issue we found is that we have a limited amount of space. Due to that we
are removing the generation from the ci.
Triggers in pipleines are disable by default, removing it will stop it
from being executed. The PR are triggered via a release pipeline we
called macios.glue
* If the return value from xamarin_get_reflection_method_method is cached in a
static variable, we can only release at process exist.
* Otherwise just release at the end of the current method.
Before:
There were 258096 MonoObjects created, 246948 MonoObjects freed, so 11148 were not freed. (dynamic registrar)
There were 205834 MonoObjects created, 205214 MonoObjects freed, so 620 were not freed. (static registrar)
After:
There were 258092 MonoObjects created, 246945 MonoObjects freed, so 11147 were not freed. (dynamic registrar)
There were 205834 MonoObjects created, 205600 MonoObjects freed, so 234 were not freed. (static registrar)
Before:
There were 258046 MonoObjects created, 235142 MonoObjects freed, so 22904 were not freed. (dynamic registrar)
There were 205804 MonoObjects created, 204193 MonoObjects freed, so 1611 were not freed. (static registrar)
After:
There were 258054 MonoObjects created, 235172 MonoObjects freed, so 22882 were not freed. (dynamic registrar)
There were 205804 MonoObjects created, 205190 MonoObjects freed, so 614 were not freed. (static registrar)
This fixes a memory corruption where we'd try to process out parameters when
an exception had occurred, and those out parameters weren't expected to be
processed.
Before:
There were 258046 MonoObjects created, 235142 MonoObjects freed, so 22904 were not freed. (dynamic registrar)
There were 205804 MonoObjects created, 204193 MonoObjects freed, so 1611 were not freed. (static registrar)
After:
There were 258018 MonoObjects created, 235128 MonoObjects freed, so 22890 were not freed. (dynamic registrar)
There were 205809 MonoObjects created, 204221 MonoObjects freed, so 1588 were not freed. (static registrar)
This involves storing the out parameter in an additional variable, so that we
can still access it after the method call.
Before:
There were 257927 MonoObjects created, 235060 MonoObjects freed, so 22867 were not freed. (dynamic registrar)
There were 205700 MonoObjects created, 203983 MonoObjects freed, so 1717 were not freed. (static registrar)
After:
There were 257935 MonoObjects created, 235064 MonoObjects freed, so 22871 were not freed. (dynamic registrar)
There were 205700 MonoObjects created, 204006 MonoObjects freed, so 1694 were not freed. (static registrar)
Before:
> There were 205700 MonoObjects created, 113865 MonoObjects freed, so 91835 were not freed. (static registrar)
After:
> There were 205700 MonoObjects created, 113982 MonoObjects freed, so 91718 were not freed. (static registrar)
Step fwd to get the stativ page. We download all the artifacts from the
cascade pipeline. The artifacts are inherited thanks to the trigger.
Download, extract, print files to be removed.
* Pass any native references to the LinkNativeCode task so that they're linked
with the main executable.
* Copy frameworks and dynamic libraries to the app bundle (also add support
for MSBuild metadata - the CopyToAppBundle property - to avoid copying a
framework / dynamic library to the app bundle).
* Refactor MTouchTaskBase a bit to make parts of it reusable from the
LinkNativeCode task.
* Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/11061.
The branch name will be:
* pr/branchname/branch_commit/buildid - for builds triggered by a pr
* ci/branchname/branch_commit/buildid - for all others.
Commit and build id have been added to ensure we have no collisions.
We already define it in the generated code, so the native compiler shows a warning:
Microsoft.macOS.registrar.coreclr.x86_64.m:1:9: warning: 'CORECLR_RUNTIME' macro redefined [-Wmacro-redefined]
#define CORECLR_RUNTIME
^
<command line>:2:9: note: previous definition is here
#define CORECLR_RUNTIME 1
^
Add changes to sync main into Localization branch
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
Co-authored-by: Connor Adsit <cadsit@microsoft.com>
* Pass any native references to the LinkNativeCode task so that they're linked
with the main executable.
* Copy frameworks and dynamic libraries to the app bundle (also add support for
MSBuild metadata - the CopyToAppBundle property - to avoid copying a framework
/ dynamic library to the app bundle).
* Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/11061.
If can happen that when we bump xcode we do not get an api & generator
diff. This results in a set of cascading events that make the build
fail.
We know track when the result is not 0, store it in a var and pass that
variable to all the tempaltes that need it. The pwsh script already has
an if to check if the file if present and if not, it shows a warning.
* Make 'throw Objective-C exception' the default for managed exception marshalling.
* Make 'throw managed exception' the default for Objective-C exception marshalling.
* Disallow the 'unwind through native frames' option: CoreCLR won't do it.
* Disallow the 'unwind through managed frames' option: it's the safeset
option by far, and also matches the reverse case.
* Disallow the 'disable' option: this is also not safe, let's try to go the
safe route with CoreCLR.
* Change the default in native code too.
Partial fix for #10940.
Add stage names to the templates to use them in triggers in the future.
Remove a yaml file that turned out not to be needed (via a hack around
vsts limitations).
* Update to new linker custom steps API
* PR feedback
- Fix indentation
- Add Initialize(LinkContext) to ExceptionalMarkHandler
- Remove unnecessary ifdef
- Use IsSetter/IsGetter
- Use [0] instead of Single()
- Avoid allocating empty collections
* Note override issue
* Clean up comments
* Move `DynamicRegistrationSupported` change earlier, along with the
detection code.
This solve the issue that `ILLink` does a similar job _before_ we have
the chance to disable the dynamic registrar.
* ILLink does not support considering other attributes as `[Preserve]`
when it is itself preserved at the assembly-level.
This ignored test is checking that feature so it cannot be enabled
for `NET`
Added to known breaking changes https://github.com/xamarin/xamarin-macios/issues/8900
* Fix removal of the dynamic registrar on legacy
* Fix IntPtr size inlining
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
* Implement our xamarin_dyn_objc_msgSend[Super] overrides for ARM64.
* Modify mmp to use those overrides.
* Fix an issue with the existing xamarin_arm64_common_trampoline that caused
exceptions to not unwind correctly.
* Add an ARM64 variation of xammac tests in xharness.
* Various test fixes.
Adds a coherent parent dependency to `Microsoft.NET.ILLink.Tasks`, which
ensures that it will not be updated past the version included in
`Microsoft.Dotnet.Sdk.Internal`.
These changes allow us to remove our mono/linker darc subscriptions, as
`Microsoft.Dotnet.Sdk.Internal` updates will also bring in the latest
`Microsoft.NET.ILLink.Tasks` that the SDK references. This will reduce
the number of dependency update PRs created by maestro.
Since the `Microsoft.NET.ILLink.Tasks` and `Microsoft.NET.ILLink` NuGet
packages are created by the same build, we only need to track one of
these package IDs in eng/Version* files.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Enabling OneLocBuild to run every build we have on main because the Loc team will need the Loc artifacts to be published every time. By moving the conditional to the isPRSelected input, we will run the task every time but only create the PRs once a week!
The newly extracted `RegistrarRemovalTrackingStep` can be used inside
`dotnet-linker` to remove the dynamic registrar (if not required by some
other code).
We are using cascade pipelines, those are triggered automatically and
get all the artifacts. We create a json file that will be used by one of
the cascaded pipelines to make educated choices.
Manuel de la Pena
Rolf Bjarne Kvinge
Peter Collins
Matthew Leibowitz
Rachel Kang
Mike Bond
Filip Navara
dotnet-maestro[bot]
TJ Lambert
Sebastien Pouliot
VS MobileTools Engineering Service 2
Sven Boemer
Přemek Vysoký
Alex Soto