This seems to be required when running monotouch-test with lldb (!) - no idea
why it doesn't fail otherwise.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* Remove 1 array allocation per print statement.
* Remove 2 string concatenations per print statement.
* Don't indent empty lines.
For the generated code for watchOS, this is the difference (time-wise I wasn't
able to measure anything significant, although the memory savings are
significant):
Before:
Allocation summary
Bytes Count Average Type name
535.485.544 7.115.025 75 System.String
145.340.480 2.270.945 64 IKVM.Reflection.CustomAttributeData
110.149.624 1.238.394 88 System.Char[]
...
Total memory allocated: 1.793.323.536 bytes in 28.827.325d objects
After:
Allocation summary
Bytes Count Average Type name
494.592.328 6.624.441 74 System.String
145.340.480 2.270.945 64 IKVM.Reflection.CustomAttributeData
99.345.984 968.303 102 System.Char[]
...
Total memory allocated: 1.741.626.784 bytes in 28.066.650d objects
Difference:
Allocation summary
Bytes Count Average Type name
-40.893.216 -490.584 -1 System.String
0 0 64 IKVM.Reflection.CustomAttributeData
-10.803.640 -270.091 +14 System.Char[]
...
Total memory allocated: -51.696.752 bytes in -760.675 objects
This was measured by executing the following in an already built working copy:
/Library/Frameworks/Mono.framework/Versions/Current/bin/mono --profile=log:nocalls,alloc --debug build/common/bgen.exe @build/watchos.rsp
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* 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.
Converts the Microsoft.iOS.Windows.Sdk NuGet package into a proper
[workload SDK pack][0]. The entry point for this pack has been changed,
and it is now imported through the `WorkloadManifest.targets` file
included in `Microsoft.NET.Workload.iOS`, rather than being imported
directly from `Microsoft.iOS.Sdk`.
Import ordering has otherwise changed slightly. The following files are
now imported before the majority of the `Microsoft.iOS.Sdk` (and the
majority of the .NET SDK targets):
* Xamarin.iOS.Common.Before.props
* Xamarin.iOS.Common.Before.targets
After this the majority of the .NET SDK targets will load, followed by
the `Microsoft.iOS.Sdk` targets. Finally, everything declared in the
`<AfterMicrosoftNETSdkTargets/>` hook loads, which consists of:
* Microsoft.iOS.Windows.Sdk.targets
* tools/msbuild/*
[0]: https://github.com/dotnet/designs/blob/main/accepted/2020/workloads/workload-manifest.md#sdk-packs
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Native headers show it's null_resettable.
```objc
/// If set, the receiver will inherit the appearance of that object, as well as use KVO to observe its effectiveAppearance for changes. Typically this is used for child windows that are shown from a parent window or specific view. Defaults to NSApp.
@property (weak, null_resettable) NSObject<NSAppearanceCustomization> *appearanceSource API_AVAILABLE(macos(10.14));
```
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.
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.
Alexander Köplinger
Sebastien Pouliot
Rolf Bjarne Kvinge
Mauro Agnoletti
Manuel de la Pena
Peter Collins
Marius Ungureanu
Emanuel Fernandez Dell'Oca
Alex Soto
Jonathan Peppers
Filip Navara