The test was merge with the xammac_tests in commit
93bbfe7a86
but we did not have the tests running to know.
This should fix some of the failures we have in older macs.
- Make git ignore the generated `report.md`
- Fix `.aotdata` reported total size in reports (was always 0)
- Add option to strip the dotnet app bundle (until [1]) so it's easier to compare with _oldnet_ sizes.
[1] https://github.com/xamarin/xamarin-macios/issues/11445
Create two pipelines that will be triggered when a new build is
completed and contains tests results. There are some important details:
1. pipeline triggers have to specify all branches or a subset. We use
tags to trigger for PRs.
2. Tags are and, not or, so we need to pipelines (lame lame).
Due to 2. we add a new tag to identify ci builds.
Do not publish the nugets that have been created in a PR build. The
build results can be accessed from the comment once completed. This way
we make sure that next builds do not have conflicts when publishing the
nugets.
This makes it easier to test localized strings used in mtouch, since we don't have
to replicate the build for all the resources.
This required a few changes to avoid including code in the mtouch tests that already
exists in the mtouch executable.
Also rename the mtouch test project to mtouchtests.csproj.
This way the test project can reference the actual mtouch.csproj without
causing conflicts due to having two projects with the same name.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
There's no general way to set a pending managed exception in CoreCLR (the
current plan is to support setting a pending managed exception for the
objc_msgSend family of functions). This means that the way we've implemented
custom wrappers that can handle Objective-C exceptions won't work, because
those wrappers currently tries to set a pending managed exception (which Mono
throws upon returning from the corresponding native wrapper function).
So rewrite this a bit: these custom wrappers now return a GCHandle with the
managed exception as an out parameter, and the calling managed code throws
that exception instead.
This also required adjusting a few API definitions to match how their wrapper
functions are defined.
Create a new parameter that can be used to decide if we build or not the
dotnet parts of the project. If we do not, we make sure that we do not
have any errors in all the other steps.
We have to consider (setup and process) `libSystem.Globalization.Native`
in order not to remove the required symbols when stripping the native
executable.
Ignore `libSystem.Globalization.Native` for dotnet / catalyst
ref: https://github.com/xamarin/xamarin-macios/issues/11392
Use the jenkins script as a base to get the PAI & generator from stable
diff back to the CI. Comment is not perfect, but does provide the
required information. The comment can be improve in a later commit since
this is getting too large.
* The generated static registration code will eventually be different.
* The generated code has to be compiled with different compiler flags.
This also required adding a new overload of xamarin_mono_object_release for the generated
code to compile.
This also meant reviewing calling code to make sure that MonoObject*s are
released when they should be, which meant reviewing every method that returns
a MonoObject*, and release the result.
For some reason, some of the internal hosted pools have been set without
the OS version (WRONG WRONG). The simples way is to allow to skip this
check in those pools over re-configuring all bots.
'We can lick gravity, but sometimes the paperwork is overwhelming.'
Move the xamarin_create_managed_ref internal call to managed code, to ease things
with CoreCLR.
In order to preserve performance, this wasn't a straight forward port.
* monotouch_create_managed_ref used to detect if there already was a GCHandle for
a native object. To avoid a managed->native transition, this logic has now been
moved into the code that sets the GCHandle (the xamarinSetGCHandle🎏 / xamarin_set_gchandle_trampoline
code), and these methods return a value saying whether the GCHandle was set or
not.
* xamarin_create_gchandle will check the retain count to determine whether to create
a weak or a strong GCHandle for the managed object. In this particular case we
should never need to create a strong GCHandle, which means that we don't need to
check the retain count (saving a managed->native transition).
Using the new perftest (#11298), I get very similar numbers for both old code and new code: https://gist.github.com/rolfbjarne/e0fc2ae0f21da15062b4f051138679af (multiple runs). Sometimes the old code is faster, sometimes the new code is faster (although the old code tends to be the one who wins).
In any case there aren't any significant performance hits due to this change, so it should be good to go.
Makes this error show properly:
> error MM2301: The linker step 'Setup' failed during processing: This version of {0} requires the {1} {2} SDK (shipped with Xcode {3}). Either upgrade Xcode to get the required header files or use the dynamic registrar or set the managed linker behaviour to Link Platform or Link Framework SDKs Only in your project's Mac Build Options > Linker Behavior} (to try to avoid the new APIs).. String.Format failed! Arguments were: "Microsoft.macOS" "macOS" "11.3" "12.5". Please file an issue to report this incorrect error handling.
* Extract the code we use to configure the assembly resolver during a normal
mmp run to make it usable for --runregistrar.
* Configure the assembly resolver we use for --runregistrar.
* Pass the assembly resolver to the registrar so that it's actually used.
* Adjust the System.Void lookup to look everywhere even if we find a corlib,
since behavior changes a bit now that we're using an assembly resolver:
* Previous behavior:
1. In .NET mode, look for a corlib named System.Private.CoreLib, and fail to find it.
2. Look in all the loaded assemblies for System.Void (and find it in System.Runtime.dll).
* Broken behavior as a result of the resolver changes:
1. Find corlib as System.Private.CoreLib.dll
2. Fail to find System.Void in System.Private.CoreLib.dll, since we'd only look in corlib.
* New behavior
1. Find corlib as System.Private.CoreLib.dll
2. Fail to find System.Void in System.Private.CoreLib.dll, but find it in System.Runtime.dll,
since we're now looking in all the loaded assemblies.
This is required to make VSMac's usage of --runregistrar
VSTS already provides a status per job, since the governance tests do
not give much feedback in the comments and just set a status, we can use
the default provided by the VSTS app.
Remove those devices of Mac OS X that will not happen because we cannot
run the agent in such and old device. This is due to the fact that the
agent runs using c# and we do not support such and old OS.
Also add a new stage to run tests on catalina. ATM older OS as not
working, but Catalina should work with our trusted pool.
We move from having a status per nugets to two statues:
1. xamarin-macios (Nugets built) - to let us know that we did build
nugets.
2. xamarin-macios (Nuvets published) - to let us know tat we did pubish
the nugets.
On a pull request, Azure DevOps does not build the exact version of the code that you pushed,
but a version merged with your target branch. This means that the commit
we see in the Buid.Revision is not the one of the last commit of the PR,
which makes some statuses get "lost" and checks be missed.
We make a distintion on which variable to used base on the build reason.
* [mtouch] It seems watchOS simulators can automatically choose the right architecture from fat apps.
So we can build a fat simulator app, and not depend on mlaunch copying in the
specific architecture at launch time.
A partial fix for https://github.com/xamarin/maccore/issues/2411.
* Bump maccore.
New commits in xamarin/maccore:
* xamarin/maccore@d11721f55e [Xamarin.Hosting] Xcode seems to have changed some logic with regards to getting the primary instruments server. (#2416)
* xamarin/maccore@d27297a098 [Xamarin.Hosting] Don't copy single-arch executable over a fat executable. (#2417)
* xamarin/maccore@6c305d4aa7 [Xamarin.Hosting] Launching may succeed even if the launch request fails. Don't fail in that case. (#2415)
* xamarin/maccore@bccc91d6a0 Support ARM64 and ARM64e simulators (#2418)
Diff: c89fd6a694..d11721f55e
In this case we can obsolete the attribute on both legacy and dotnet
since the replacement attribute is available on both. However this does
require a small update to the legacy linker (and is part of the PR).
Fix https://github.com/xamarin/xamarin-macios/issues/10674
This avoid some computation that might not be needed.
It also avoids a `NullReferenceException` when updating to net6 preview 4
builds (where `ResolveType` can return `null` but the type reference was
enough to complete the job).
Rolf Bjarne Kvinge
Manuel de la Pena
Mike Bond
Sebastien Pouliot
Connor Adsit
Peter Collins