New commits in mono/mono:
* mono/mono@f34bd77e39 [2020-02][Android] Workaround for invalid return value from clock_nanosleep
* mono/mono@0f5e80e577 Disable ClientWebSocketTest tests that started failing for no reason
Diff: 4efc825e83..f34bd77e39
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
New commits in mono/mono:
* mono/mono@4efc825e83 [Tools] Fix mono-api-html MarkdownFormatter.cs to avoid a NRE
* mono/mono@6171c87180 vtable setup fix for generic default interface methods in mono runtime
* mono/mono@148f536b0b [2020-02] [AOT] Use .short directive instead of .hword
* mono/mono@a6f3e8f179 Avoid an assert in ves_icall_RuntimeFieldInfo_SetValueInternal
* mono/mono@3c4f3de377 Add correct InetAccess category to HttpClientTest.Proxy_Disabled test and disable Ping tests
* mono/mono@9f35bf1b80 Add missing handle function enter/return macros
Diff: 45efaa3b6f..4efc825e83
In .NET, all files that should be published (put into the final .app bundle) are put into the @(ResolvedFileToPublish) item group, and at the end of the build process, .NET will publish all the files in that item group. Which files are in this item group, and how they're put in there, is out of our control (it's just how the build process works in .NET), so we'll have to cope.
Additionally, publishing an app for Apple platforms is different than publishing other .NET apps, because we can't just put all the files in the a directory like .NET usually does, we have a fairly strict directory structure we need to follow, and it also differs between platforms (the structure is different between macOS and iOS for instance).
This means that for every file in the `ResolvedFileToPublish` item group, we have to figure out:
* Should it be put into the app bundle in the first place?
* If so, in which subdirectory (if any)?
This PR implements these changes. The exact details are explained in a document in the PR, but the general logic is:
* We make an educated guess for some types of files we know about (assemblies, unmanaged libraries, images, etc).
* We provide a way to set metadata on each item specifying which type of item it is (assembly, unmanaged library, image, etc), and we'll treat the item as such. This method can also be used to override the guess we made (for files that shouldn't be published for instance).
* We warn if we run into files we're not educated enough to be able to guess about, and for which there's no custom metadata set.
Fixes https://github.com/xamarin/xamarin-macios/issues/12572.
New commits in mono/mono:
* mono/mono@b8d7525156 [2020-02] [cominterop] Add coop handle enter/return on native CCW methods
* mono/mono@2ca650f1f6 [2020-02] Adds full path to libcairo for correct assembly directory resolution in monterey
* mono/mono@e750cb3ee5 [aot] Prepend the assembly name to the names of gsharedvt wrappers to avoid duplicate symbol errors during static linking.
* mono/mono@b32801a63c Remove NuGet.config
* mono/mono@dfcef74640 Allow nfloat to be in the ObjCRuntime namespace, and make it work for Xamarin.MacCatalyst.dll as well.
* mono/mono@5ce143a1a8 Revert "[2020-02] Start a dedicated thread for MERP crash reporting (mono/mono#21126)"
Diff: 4150e65c9e..b8d7525156
* Submodule MonoTouch.Dialog.
Submodule MonoTouch.Dialog, so that we can easily build it using .NET. This
submodule will become redundant when/if we publish a .NET version of
MonoTouch.Dialog, but until that happens we need it at least for our own test
suites.
This also means we have to copy our NuGet.config and global.json files to the
MonoTouch.Dialog project directory so that we point msbuild to use our local
build.
New commits in spouliot/Touch.Unit:
* spouliot/Touch.Unit@cbda703 [Touch.Client] Use MonoTouch.Dialog from a submodule. (#109)
Diff: 3345db2f4e..cbda703583
* Use relative path for submodule.
And fix indentation and set the branch name.
* Don't use 'RootTestsDirectory' when it might not be defined yet.
* [tests] Our test projects don't need to reference MonoTouch.Dialog directly.
The projects get the MonoTouch.Dialog reference indirectly through the
Touch.Client project reference.
* [tests] Only validate unique errors in the .NET unit tests.
* [tests] No need to reference System.Json anymore, that's handled directly in the MonoTouch.Dialog project.
* [tests] Reference nunit.framework.targets so we get a workaround for an NUnit issue everywhere.
* [msbuild] Only try to create a package if we're able to create an app bundle.
This fixes an issue where a library project would try (and fail) to create a
package when 'CreatePackage=true' (which could be set for the executable
project, but inherited by the library project since the executable project
depends on it).
* [tests] Adjust PackTest.BindingXcFrameworksProject to not set the AssemblyName property.
MSBuild ends up being very confused when the project we're trying to build
depends on other projects, because AssemblyName is set for all the projects
being build, and MSBuild complains about ambiguous projects:
> error: Ambiguous project name 'bindings-xcframework-test'
New commits in xamarin/maccore:
* xamarin/maccore@c7809739bd [Xamarin.Hosting] Add each platform as an exposed capability to the plugin manager. Fixes #xamarin/xamarin-macios@11901. (#2455)
Diff: 9acbbed1f6..c7809739bd
* Bump maccore.
New commits in xamarin/maccore:
* xamarin/maccore@9acbbed1f6 [mlaunch] Add support for Xcode 13 beta 1. (#2452)
* xamarin/maccore@e48f75c0b6 [Xamarin.Hosting] Fix the --stdout arg not being forwarded to DeviceLaunchConfig (#2435)
* xamarin/maccore@109c695b1b [Xamarin.Hosting] Fix help string for launchdev argument (#2429)
Diff: cddbd1915d..9acbbed1f6
* [xtro] Fix generation of .pch files
* [xtro] Fix deprecated check to handle (anonymous) declarations and enable latest C# syntax in project
* [xtro] Fix _sanity_ checks
* [xtro] Update todo for beta 1
* [Siminstaller] Force siminstaller to use the xcode 12.5 url
Related issue: https://github.com/xamarin/xamarin-macios/issues/11881
* Fix introspection failures (due to [breaking] changes)
* [tests][intro] Fix hang for tvOS
Creating an instance of `NSMetadataQuery` hangs the simulator.
Even after (xharness) timeout the simulator is not in a good state
to run further tests and every new (tvOS) test will also hang...
* [tests][intro] Same hang for watchOS
except that further test execution does not seem affected (like tvOS)
```
CoreSimulator 772.1 - Device: Apple Watch Series 3 - 38mm (watchOS 8.0) - created by XHarness (42262867-E060-40C0-803E-6DA676AF50CC) - Runtime: watchOS 8.0 (19R5266p) - DeviceType: Apple Watch Series 3 - 38mm
Thread 0 Crashed:: tid_103 Dispatch queue: com.apple.main-thread
0 com.apple.Foundation 0x00007fff21470bd0 -[NSMetadataQuery dealloc] + 432
1 libobjc.A.dylib 0x00007fff200d11f7 objc_object::sidetable_release(bool, bool) + 177
2 com.apple.Foundation 0x00007fff21470a03 -[NSMetadataQuery init] + 64
3 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107efc139 xamarin_dyn_objc_msgSend + 217 (trampolines-x86_64-objc_msgSend.s:15)
4 ??? 0x000000010c76d4f6 0 + 4504081654
5 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107cffc85 mono_jit_runtime_invoke + 1621 (mini-runtime.c:3197)
6 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107e177d8 do_runtime_invoke + 54 (object.c:3052) [inlined]
7 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107e177d8 mono_runtime_invoke_checked + 136 (object.c:3220)
8 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107e1e3c5 mono_runtime_try_invoke_array + 2101 (object.c:5601)
9 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107daf977 ves_icall_InternalInvoke + 871 (icall.c:3927)
10 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107dc0167 ves_icall_InternalInvoke_raw + 103 (icall-def.h:667)
11 ??? 0x000000010a232799 0 + 4465043353
12 ??? 0x000000010c76e08b 0 + 4504084619
```
* [tests][monotouch-test] Fix failures with xcode 13 beta 1
* [tests][mmptest] Use a FAT framework that's build with x86_64 and arm64
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* [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
* [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
* [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.
* 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>
* Add configure option to disable building for legacy Xamarin.
This can greatly speed up the debug-edit-build cycle when doing .NET
development, since it cuts down the build time in half more or less.
* Bump maccore.
New commits in xamarin/maccore:
* xamarin/maccore@548fa45432 [mlaunch] Disable building mlaunch when not including the legacy Xamarin build. (#2403)
Diff: 0562e08b12..548fa45432
* [runtime] Build our runtime for Mac Catalyst/ARM64 for .NET.
* [ObjCRuntime] There's no need for the StartWWAN implementation on Mac Catalyst.
This also fixes a build error:
error MT5214: Native linking failed, undefined symbol: _xamarin_start_wwan. This symbol was referenced by the managed member ObjCRuntime.Runtime.xamarin_start_wwan.
* Only exclude xamarin_start_wwan in the .NET version of Mac Catalyst.
* [tests] Update to not run the StartWWAN test on Mac Catalyst.
* Update conditional logic.
* Fix build with newer make versions.
This also means linking with the runtime packs from .NET instead of the mono archive
(thus we have one less reliance on the mono archive).
We're also using the Xamarin.iOS code for our macOS launch sequence now, since
(at least at first) we're only going to support self-contained .NET macOS apps
(so no need to support a system-installed runtime, which simplifies things a
bit).
Rolf Bjarne Kvinge
Alex Soto
Manuel de la Pena
Přemek Vysoký
Connor Adsit