Those are called respectively inside `xamarin_vm_initialize` and
`xamarin_bridge_initialize` functions.
This fix the **AppContext.GetData always return null for iOS** issue
https://github.com/dotnet/runtime/issues/50290
Thanks for @filipnavara for diagnosing this quicker than anyone else!
Added unit tests to ensure `AppContext.GetData` can read back the values
we're providing at startup.
Fixes: https://github.com/xamarin/xamarin-macios/issues/10887
After bumping to .NET 6 Preview 3, we get hundreds of ILLINK warnings.
This is because of:
https://github.com/dotnet/sdk/pull/16327
We need to default `$(SuppressTrimAnalysisWarnings)` to ignore these
warnings for now.
We should continue to use `TrimMode=link`, as that is the behavior
Xamarin developers get today.
The type implementation of an interface member does not need to be
`virtual` but, since it's done by _sealing_ the member.
Example
```diff
public virtual ---final--- int Count { get; }
```
* Link FrameworkList.xml to a place where MSBuild SDK actually expects it
* Create necessary directories
* Fix symlinks for packaging
* Add test case
* Minor tweak to test case
* Fix cut & paste error
Co-authored-by: Filip Navara <navara@emclient.com>
Sometimes msbuild wants to restore packages during this process, which may
take a while.
Hopefully fixes errors like this:
Harness exception for 'Tests for C6353E8B-BFDA-4F54-93D9-FF0F838BF8EE': System.Exception: Unable to evaluate the property OutputPath.
at Xharness.AppBundleLocator.GetPropertyByMSBuildEvaluationAsync (System.Xml.XmlDocument csproj, System.String projectPath, System.String evaluateProperty, System.String dependsOnTargets, System.Collections.Generic.Dictionary`2[TKey,TValue] properties) [0x00327] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/AppBundleLocator.cs:109
at Xharness.AppBundleLocator.LocateAppBundle (System.Xml.XmlDocument projectFile, System.String projectFilePath, Microsoft.DotNet.XHarness.iOS.Shared.TestTarget target, System.String buildConfiguration) [0x000d2] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/AppBundleLocator.cs:49
at Microsoft.DotNet.XHarness.iOS.Shared.AppBundleInformationParser.ParseFromProject (System.String projectFilePath, Microsoft.DotNet.XHarness.iOS.Shared.TestTarget target, System.String buildConfiguration) [0x00147] in /_/src/Microsoft.DotNet.XHarness.iOS.Shared/AppBundleInformationParser.cs:71
at Xharness.AppRunner.InitializeAsync () [0x00046] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/AppRunner.cs:120
at Xharness.Jenkins.TestTasks.RunSimulator.SelectSimulatorAsync () [0x002df] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/Jenkins/TestTasks/RunSimulator.cs:108
at Xharness.Jenkins.TestTasks.AggregatedRunSimulatorTask.ExecuteAsync () [0x00335] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/Jenkins/TestTasks/AggregatedRunSimulatorTask.cs:63
at Xharness.Jenkins.TestTasks.TestTasks.RunInternalAsync () [0x00226] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/Jenkins/TestTasks/TestTask.cs:283
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This requires a few things:
* [runtime] Add support for generating managed delegates only for CoreCLR.
However, since our managed code is shared between CoreCLR and MonoVM, the
best we can do is to make these CoreCLR-only delegates .NET-only.
* [runtime] Make it possible to implement Mono Embedding API in the CoreCLR bridge
By making it possible to skip the automatically generated Mono Embedding
* [runtime] Add a MonoObject implementation for CoreCLR.
We need a way to represent a managed object in native code, and since most
our existing runtime code uses MonoObjects, we use the same for the
CoreCLR bridge, just our own version of it. In Mono, the MonoObjects are
tracked by the GC (which scans the stack), but we can't make CoreCLR scan
the stack, so we use a reference counted version of MonoObject instead -
we just put the GCHandle into a reference counted MonoObject, and when the
MonoObject is freed, then we free the GCHandle as well.
* Go through all uses of mono_assembly_open, and make sure they release the
returned assembly.
and that requires ensuring all (implicit/explicit) interface members are
generated...
**Example**
Removed interfaces:
```csharp
IARAnchorCopying
Foundation.INSCoding
Foundation.INSCopying
Foundation.INSSecureCoding
```
We need a way to represent a managed object in native code, and since most our existing
runtime code uses MonoObjects, we use the same for the CoreCLR bridge, just our own
version of it. In Mono, the MonoObjects are tracked by the GC (which scans the stack),
but we can't make CoreCLR scan the stack, so we use a reference counted version of
MonoObject instead - we just put the GCHandle into a reference counted MonoObject,
and when the MonoObject is freed, then we free the GCHandle as well.
* Move the existing logic to call Runtime.Initialize into the MonoVM code.
* Implement calling the managed Runtime.Initialize method from the CoreCLR bridge.
The call to Runtime.Initialize succeeds, which means we're now executing
managed code with CoreCLR for the first time.
This test verifies that the build log prints:
"execution started with arguments: actool --errors --warnings --notices --output-format xml1 --output-partial-info-plist "
However, for M1 machines, we don't call actool directly, we go through 'arch'
instead, and this line is printed:
Tool arch execution started with arguments: -arch arm64e /usr/bin/xcrun actool --errors --warnings --notices --output-format xml1 --output-partial-info-plist ...
So adjust the test to cope with both of these behaviors.
* [mono] Bump mono to bring iOS binaries built with xcode12.4
Also bumping system mono pkg to the one that contains arm64 support
New commits in mono/mono:
* mono/mono@eb4c3116eb Build iOS SDK archives on Xcode 12.4
* mono/mono@acb8d8ed6f [2020-02][marshal] Fix VARIANT and BSTR marshaling in structs (#20918)
Diff: be9218f4d1..eb4c3116eb
* [mtouch] fix version logic check
Fixes Unexpected minOS version (expected 8.0.0, found 7.0.0) in MonoTouch.iphonesimulator.sdk/lib/libmono-native-compat.dylib ()
we really only care if it is over the version we expect not below.
* Fix version test
* Bump to .NET 6.0.100-preview.3.21152.10
* Bump to 6.0.100-preview.3.21152.10.
* Bump to 6.0.100-preview.3.21161.7.
* Bump to .NET 6.0.100-preview.3.21161.23.
* [dotnet-linker] Bump ILink and use the supported method of getting an assembly's location.
* Bump to MSBuild.StructuredLogger 2.1.364 to get support for newer binlog versions.
* Fix build failure
Fixes:
TestHelpers/BuildEngine.cs(161,24): error CS0433: The type 'ProjectEvaluationFinishedEventArgs' exists in both 'Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'StructuredLogger, Version=2.1.0.0, Culture=neutral, PublicKeyToken=d4c7181801cb6448' [/Users/builder/azdo/_work/1/s/xamarin-macios/tests/msbuild/Xamarin.MacDev.Tests/Xamarin.MacDev.Tests.csproj]
* Update parsing binlog properties.
* Be more defensive.
* [tests] Make sure the InternalsVisibleToAttribute constructor isn't linked away.
* [tests] Implement better printing of binlogs.
The latest MSBuild.StructuredLogger made some internal changes to the Message
property which confuses some of our test logic. So implement manual printing
of the log entries that we care about to make sure they conform to the
expected format by the tests (the output is mimicing what 'msbuild /v:diag
foo.binlog' would show).
* [ObjCRuntime] Simplify Runtime.NSLog to always call xamarin_log.
This also fixes a couple of bugs:
* We wouldn't use the arm64 version of NSLog on Xamarin.Mac.
* We would use a wrong xamarin_log declaration on Xamarin.Mac on older macOS
(the string argument would be UTF8 as opposed to Unicode, which is what the
native function expects).
* [Dlfcn] Ignore any failures to show a warning about dlopen with full path.
We can run into this problem:
System.EntryPointNotFoundException: xamarin_log assembly:<unknown assembly> type:<unknown type> member:(null)
at (wrapper managed-to-native) ObjCRuntime.Runtime.xamarin_log(string)
at ObjCRuntime.Runtime.NSLog (System.String value) [0x00001] in <7b41a16d434f401091abbf1beafe6453>:0
at ObjCRuntime.Dlfcn.dlopen (System.String path, System.Int32 mode) [0x0003b] in <7b41a16d434f401091abbf1beafe6453>:0
at ObjCRuntime.Runtime.LookupInternalFunction[T] (System.String name) [0x00040] in <7b41a16d434f401091abbf1beafe6453>:0
at ObjCRuntime.Runtime.EnsureInitialized () [0x00036] in <7b41a16d434f401091abbf1beafe6453>:0
at AppKit.NSApplication.Init () [0x00016] in <7b41a16d434f401091abbf1beafe6453>:0
at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&)
at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0006a] in /Users/builder/jenkins/workspace/build-package-osx-mono/2020-02/external/bockbuild/builds/mono-x64/mcs/class/corlib/System.Reflection/RuntimeMethodInfo.cs:395
which happens because we're trying to find libxammac.dylib, which we first try
to load without a full path, which runs into a code path that wants to show a
warning, which wants to use xamarin_log, which is in libxammac.dylib, which
we're trying to load. Ops.
So just ignore any failures to print this warning.
* Find a solution that doesn't involve catching exceptions.
The fields of the MonoObject struct is specific to MonoVM, so this makes sure
we don't accidentally poke into random memory on CoreCLR.
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
If no exception handling is provided when calling a managed delegate from native
code, and the managed code throws, then we'll abort.
It's not entirely clear how we'll handle managed exceptions that go through native
code yet, so this makes the initial implementation easier. By making the exception
handling optional, it'll be easy to find all cases where we need to fix it later,
by making it non-optional. The alternative is to add exception handling code all
over the place that would potentially have to be updated when we figure out exactly
what needs to be done.
Manuel de la Pena
TJ Lambert
Sebastien Pouliot
Mike Bond
Jonathan Peppers
VS MobileTools Engineering Service 2
Rolf Bjarne Kvinge
Alex Soto
Rachel Kang
Filip Navara