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.
Xamarin.MacCatalyst ships a `Xamarin.iOS.dll` assembly that contains
forwarders (to `Xamarin.MacCatalyst.dll`) and stubs that throws
`PlatformNotSupportedException`.
This is used to help code compatibility between both platforms - but
that requires exposing an identical surface and the best way to ensure
this is to compare (and report) them using `apidiff`
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
We need to call coreclr_initialize/monovm_initialize at startup, so do that.
This is a partial implementation, in that we're not setting all the properties
that we should, and also the PINVOKE_OVERRIDE callback is not doing everything
it should either yet.
Ref: #10504.
The way that CoreiOSSdkDirectory was definded ($(MSBuildThisFileDirectory.Replace('...', '...'))) was returning an encoded string value that caused issues in legacy project systems. The reason of the issues is that the CoreiOSSdkDirectory value for legacy project systems is `Program Files (x86)`, and the "Replace'" function was encoding the '(' and ')' causing the "UsingTask" for fail because the Assembly File path was wrong (because it contains those encoding values).
The fix consist of applying the "Replace" function only when the path of the targets belongs to a .net SDK path, in which case it won't fail because it's under "Program Files".
We need to discuss with the MSBuild team to show this issue and know if it's a bug or how we can avoid the failure
iOS Binding projects were not building remotely since 16.9. This commit fixes that and allows to start building remotely.
Xamarin.iOS.ObjCBinding.CSharp.After.props is imported too early and because it was also importing the Messaging targets, some things like RebuildDependsOn and BuildDependsOn were being overridden by other targets, resulting on not hooking up on the remote execution.
Add support for parsing --setenv from bundler arguments and passing them to
dotnet-linker so that the environment variables can be baked into the app at
launch (like they would be for mtouch/mmp).
* [runtime] Download the CoreCLR embedding header file
* [runtime] Create VM-specific code and header files and include them in the build
* [runtime] Move MonoVM-specific initialization to MonoVM-specific code.
* Add support for Xamarin.Mac arm64
* Add compile product definition task
Xamarin.Mac can be provided with a ProductDefinition file for the generated pkg. Normally, providing a product definition was optional. However, with Apple Silicon, we have an extra issue : `productbuild` needs to know what architectures your package target. If not provided with them, it will guess to the best of its abilities. However, on Catalina and lower, the guess is x86_64, even if you have an arm64 slice. To fix this, we add a new task to compile the product definition and use this file to create the pkg. If you provide your own Product Definition, we can check and warn if the architectures don't match what we expect. If the file doesn't exist or there is no architecture, we set it ourselves based on our target architectures.
* Don't reference dynamic objC_send on arm64
When building in debug, we currently try to link dynamic objC_send symbols when targeting a 64-bit architecture. However, this is actually only defined on Intel architectures, not on arm64, so we end up failing because we're referring symbols that don't exist. Rework the `GetRequiredSymbols` to take an abi, and tag those symbols to only be valid on i386/x86_64, so they don't get referred at all when building on arm64, but still get referred in x86_64.
* Fix improper delete/move with already existing directories
* Fix stret requirement for Xamarin.Mac in arm64.
The generator supposes that we're running in x64 mode, refactor to take into account the possibility of running in arm64.
* Implement OS version generation in Product.plist, based on MinimumSystemVersion of the app
* Re-generalize some mmp registrar rules
`Microsoft.macOS.registrar` was missed by the current rule set
* Fix mmp tests
* Set E7072 as not translated
Tests were failing otherwise
* Rename Xamarin.Mac lib/x86_64 folder to 64bits (currently all targeted archs are the same)
* Fix style issues
* Fix `ToLower` usage for invariant usage
* Fix xtro-sharpie test
* [tests] Don't forcefully exit macOS tests.
Instead give the process a chance to exist (3 seconds), before we take drastic
measures.
* Bump Touch.Unit.
New commits in spouliot/Touch.Unit:
* spouliot/Touch.Unit@f19eb45 [TouchRunner] Try to make MacRunner exit nicely. (#100)
Diff: a33e0c3f2e..f19eb45cb6
* It looks like mono from 2020-02 doesn't want to exit no matter what, so limit this to .NET.
* Remove references to the login keychaintools/devops/automation/templates/build/build.yml
* remove login-keychain envvar, add credential envvars
* use special branch of maccore
* Fix variable references
* Add keyringPass back in
* and here, too
* Change maccore to HEAD of current needed version + keychain fixes
* Bump back to maccore/main.
New commits in xamarin/maccore:
* xamarin/maccore@e81fac5451 [CI] remove login keychain password and xqa cert passwords (#2404)
* xamarin/maccore@548fa45432 [mlaunch] Disable building mlaunch when not including the legacy Xamarin build. (#2403)
Removed commits from xamarin/maccore:
* xamarin/maccore@ef5502ee51 remove login keychain password and xqa cert passwords
Diff: ef5502ee51..e81fac5451
* revert pipeline branch of maccore to main
* [maccore] Bump maccore
New commits in xamarin/maccore:
* xamarin/maccore@b9aaee7254 Remove unneeded block intended to add creds to login.keychain
* xamarin/maccore@0ac61f1fba [dotnet] Changes the msbuild.zip to include Windows files (#2408)
* xamarin/maccore@e81fac5451 [CI] remove login keychain password and xqa cert passwords (#2404)
Diff: 548fa45432..b9aaee7254
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
Previously, the SuperHandle property returned a pointer into the middle of the
NSObject instance. This is not safe, because we can't make pin the NSObject
instance past the return of the SuperHandle property getter.
So rework the logic, to allocate a chunk of native memory that SuperHandle can
return, and use that instead. This means a little bit of book-keeping to
create and destroy this native memory.
Unfortunately it will also increase the memory usage for each NSObject
instance, but I don't see a way around that, while still fixing the problem
with SuperHandle, given that we can't change the signature of SuperHandle.
The test run can fail even if all the tests pass: in case the process crashes
or deadlocks at exit for instance. Don't overwrite such failures with the unit
test results.
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
This fixes almost [1] all `extra` API detected from the extrospection
(header-based) tests for MacCatalyst. This is needed to complete the
introspection fixes (without having _too large PR).
[1] except `!extra-null-allowed!` since those are still in progress for
all platforms
Use a private property (prefixed with underscore) for now, until we can decide
on a better/general name.
Also add a variation to xharness to build monotouch-test with CoreCLR
(building works fine, but it crashes at startup, which is expected at this
point).
* [tests] Preserve all test fixtures.
This fixes the wildly diffetent number of tests when running xammac tests with and without linking.
Without linking:
> Tests run: 2446 Passed: 2321 Inconclusive: 9 Failed: 0 Ignored: 125
vs with linking:
> Tests run: 1885 Passed: 1802 Inconclusive: 4 Failed: 0 Ignored: 83
Now we run the same tests either with or without linking.
One test was updated to not fail when linking is enabled.
Also add a test to ensure all future test fixtures are preserved.
* Remove whitespace noise.
The API were already available (iOS) and this helps fixing tests for
MacCatalyst (as it's based on our iOS API but expose the same issue
as macOS wrt extra ctor/init).
Move the creation of an uninitialized NSObject from native to managed, which:
* Removes the need for the mono_object_new Embedding API.
* Removes one location where we write to managed memory from native code (to
write the handle + flags in the uninitialized NSObject).
* Makes things easier for CoreCLR.
`$(_KeepLaunchProfiles)` will be defined on single projects to use `LaunchProfiles` capability required on VisualStudio, see:
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1291515
When a single-project is loaded on VisualStudio, to enable the switch between target frameworks the LaunchProfiles capability need to be enabled.
By default, it is enabled but this capability is removed by our SDKs because the HEAD projects (Android and iOS) does not use this IDE feature to display devices on the start button.
`$(_KeepLaunchProfiles)` property avoids that removal in order to have LaunchProfiles enabled on VisualStudio.
MAUI targets adds `$(_KeepLaunchProfiles)` with the value true to enable it for single-project.