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.
We stopped converting full pdbs to mdbs on Windows, so we need to override the `DebugType` property to `portable` if it's `full`, otherwise the debugger won't work from Visual Studio.
There were 2 "problems":
1- Messaging depends on `System.Net.Mqtt` and not in `System.Net.Mqtt.Server`. It still worked because the latter depends on the former package, but we were restoring unnecessary dependencies.
2- We don't need an excplicit reference, since `Xamarin.Messaging.Build.Client` already depends on it, and by removing it we avoid having another dependency to keep up to date.
Context: https://github.com/dotnet/maui/pull/807
When implementing a new `@(MauiSplashScreen)` feature for .NET MAUI, I
found out that Catalyst doesn't have support for splash screens.
I even tested this in Xcode:
* Create a new Objective-C iOS app
* Make `LaunchScreen.storyboard` red and `Main.storyboard` green.
* Check the new `macOS` checkbox in project settings to enable
Catalyst and be a multiplatform app.
I see red, then green on iOS but only green on macOS. I think Catalyst
completely ignores `UILaunchStoryboardName`.
This removes splash screens from the `dotnet new maccatalyst` template
as well as the `MyCatalystApp` sample project.
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.
This exposed a few tests that are failing on dotnet (adjusted or fixed)
Also fix a typo in an exception message in `src/ObjCRuntime/PlatformAvailability.cs`
and a build warning in `tests/common/TestRuntime.cs`
Fix part of https://github.com/xamarin/xamarin-macios/issues/11243
And allows enabling the tvOS/dotnet link all tests
* 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
* [msbuild] Fixes Windows task namespace
* [msbuild] Fixes unzipping files from Windows
This is the same approach we're using on the Xamarin.iOS.Tasks project, we need to replace the System.Text.Encoding.CodePages reference assembly by it's runtime implementation before ilmerging it, otherwise when trying to unzip files from Windows we'll get a null ref exception because that's what the ref assembly implemented.
* [msbuild] Try to copy output to Windows before ending the XMA connection
When relying on BuildDependsOn we can end up running the targets after _SayGoodBye, which ends the XMA connection. `CopyDSYMFromMac` and `CopyAppBundleFromMac` need an active connection, since both copy files from the Mac to Windows.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
This required adding a helper method to get the assembly name for a given
MonoAssembly, since that's what CoreCLR uses to determine what to execute.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
The `$(_UsingXamarinSdk)` property has been renamed to help improve
external usability. This change increases parity with the Android SDK,
which currently defines `$(UsingAndroidNETSdk)` for internal and
external use.
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.
Fixes:
?fixed-todo? Entry '!missing-pinvoke! AudioSessionAddPropertyListener is not bound' in 'MacCatalyst-AudioToolbox.todo' is not found in corresponding 'MacCatalyst-AudioToolbox.raw' file
?fixed-todo? Entry '!missing-pinvoke! AudioSessionGetProperty is not bound' in 'MacCatalyst-AudioToolbox.todo' is not found in corresponding 'MacCatalyst-AudioToolbox.raw' file
?fixed-todo? Entry '!missing-pinvoke! AudioSessionGetPropertySize is not bound' in 'MacCatalyst-AudioToolbox.todo' is not found in corresponding 'MacCatalyst-AudioToolbox.raw' file
?fixed-todo? Entry '!missing-pinvoke! AudioSessionInitialize is not bound' in 'MacCatalyst-AudioToolbox.todo' is not found in corresponding 'MacCatalyst-AudioToolbox.raw' file
?fixed-todo? Entry '!missing-pinvoke! AudioSessionSetActive is not bound' in 'MacCatalyst-AudioToolbox.todo' is not found in corresponding 'MacCatalyst-AudioToolbox.raw' file
?fixed-todo? Entry '!missing-pinvoke! AudioSessionSetActiveWithFlags is not bound' in 'MacCatalyst-AudioToolbox.todo' is not found in corresponding 'MacCatalyst-AudioToolbox.raw' file
?fixed-todo? Entry '!missing-pinvoke! AudioSessionSetProperty is not bound' in 'MacCatalyst-AudioToolbox.todo' is not found in corresponding 'MacCatalyst-AudioToolbox.raw' file
?fixed-todo? Entry '!missing-enum! NSTextWritingDirection not bound' in 'MacCatalyst-UIKit.todo' is not found in corresponding 'MacCatalyst-UIKit.raw' file
Sanity check failed (8)
make: *** [classify] Error 8
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
* Update dependencies from https://github.com/dotnet/installer build 20210408.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21208.1
* Update dependencies from https://github.com/dotnet/installer build 20210409.4
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21209.4
* Update dependencies from https://github.com/dotnet/installer build 20210410.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21210.1
* same P4 specific fix as ccb43cba56
but the ICU support was added based on P3 but merged after ^
* Update dependencies from https://github.com/dotnet/installer build 20210412.5
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21212.5
* Update dependencies from https://github.com/dotnet/installer build 20210413.70
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21213.70
* Update dependencies from https://github.com/dotnet/installer build 20210414.14
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21214.14
* Update to new package names
Thanks @pjcollins for the heads up https://github.com/xamarin/xamarin-macios/pull/11175#issuecomment-819936692
* Update dependencies from https://github.com/dotnet/installer build 20210415.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21215.1
* Fix build (path changed to include '.mono')
* remove more '.mono' special case that are not needed anymore
* Update dependencies from https://github.com/dotnet/installer build 20210415.12
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21215.12
* Fix building apps (it now finds the native libs)
Credits to @filipnavara
8325f8dadc
* Add back IsTrimmable (or nothing gets linked)
* Update dependencies from https://github.com/dotnet/installer build 20210418.6
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21218.6
* Keep downloading the CoreCLR runtime packs.
* [runtime] Adjust the build to link with the correct runtime library for CoreCLR.
* [tests][monotouch-test] Ignore NSTimeZoneTest / All_28300 on dotnet as it hangs
Introduced with https://github.com/dotnet/runtime/pull/48931
Issue https://unicode-org.atlassian.net/browse/ICU-21591
PR https://github.com/unicode-org/icu/pull/1699
* [dotnet][msbuild] Add more (missing) '\'
Fix satellite/location assemblies and some unit tests
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@gmail.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
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