[.NET 5] Start adding some project capabilities #3
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Aligned with XA too, see dotnet/android#4383. We'll start using Apple instead of iOS for these things at the IDE level since many behaviors don't actually depend on iOS but also apply to tvOS, watchOS, and so on. These capabilities go before other imports just in case additional packages/targets from the SDK need to access them too.
rolfbjarne
pushed a commit
that referenced
this pull request
Mar 13, 2020
Aligned with XA too, see dotnet/android#4383. We'll start using Apple instead of iOS for these things at the IDE level since many behaviors don't actually depend on iOS but also apply to tvOS, watchOS, and so on. These capabilities go before other imports just in case additional packages/targets from the SDK need to access them too.
rolfbjarne
pushed a commit
that referenced
this pull request
Mar 16, 2020
Aligned with XA too, see dotnet/android#4383. We'll start using Apple instead of iOS for these things at the IDE level since many behaviors don't actually depend on iOS but also apply to tvOS, watchOS, and so on. These capabilities go before other imports just in case additional packages/targets from the SDK need to access them too.
rolfbjarne
pushed a commit
that referenced
this pull request
Mar 16, 2020
Aligned with XA too, see dotnet/android#4383. We'll start using Apple instead of iOS for these things at the IDE level since many behaviors don't actually depend on iOS but also apply to tvOS, watchOS, and so on. These capabilities go before other imports just in case additional packages/targets from the SDK need to access them too.
rolfbjarne
pushed a commit
that referenced
this pull request
Mar 18, 2020
Aligned with XA too, see dotnet/android#4383. We'll start using Apple instead of iOS for these things at the IDE level since many behaviors don't actually depend on iOS but also apply to tvOS, watchOS, and so on. These capabilities go before other imports just in case additional packages/targets from the SDK need to access them too.
rolfbjarne
pushed a commit
that referenced
this pull request
Mar 19, 2020
Aligned with XA too, see dotnet/android#4383. We'll start using Apple instead of iOS for these things at the IDE level since many behaviors don't actually depend on iOS but also apply to tvOS, watchOS, and so on. These capabilities go before other imports just in case additional packages/targets from the SDK need to access them too.
rolfbjarne
pushed a commit
that referenced
this pull request
Mar 25, 2020
Aligned with XA too, see dotnet/android#4383. We'll start using Apple instead of iOS for these things at the IDE level since many behaviors don't actually depend on iOS but also apply to tvOS, watchOS, and so on. These capabilities go before other imports just in case additional packages/targets from the SDK need to access them too.
rolfbjarne
pushed a commit
that referenced
this pull request
Apr 24, 2020
Aligned with XA too, see dotnet/android#4383. We'll start using Apple instead of iOS for these things at the IDE level since many behaviors don't actually depend on iOS but also apply to tvOS, watchOS, and so on. These capabilities go before other imports just in case additional packages/targets from the SDK need to access them too.
rolfbjarne
pushed a commit
that referenced
this pull request
Jul 6, 2020
Aligned with XA too, see dotnet/android#4383. We'll start using Apple instead of iOS for these things at the IDE level since many behaviors don't actually depend on iOS but also apply to tvOS, watchOS, and so on. These capabilities go before other imports just in case additional packages/targets from the SDK need to access them too.
rolfbjarne
added a commit
that referenced
this pull request
Jul 8, 2020
* [.NET 5] Start adding some project capabilities (#3) Aligned with XA too, see dotnet/android#4383. We'll start using Apple instead of iOS for these things at the IDE level since many behaviors don't actually depend on iOS but also apply to tvOS, watchOS, and so on. These capabilities go before other imports just in case additional packages/targets from the SDK need to access them too. * Remove the LaunchProfiles capability for the CPS integration (xamarin#8472) Implements https://work.azdo.io/1112733 as a workaround for the conflicts between the built-in launchsettings.json-based .NET Core debugger and our Mono debugger. Co-authored-by: Daniel Cazzulino <daniel@cazzulino.com>
rolfbjarne
added a commit
that referenced
this pull request
May 4, 2021
Next failure is: > monotouchtest[8307:20722735] Xamarin.Mac: The method mono_runtime_invoke has not been implemented for CoreCLR. ``` * frame #0: 0x00007fff2059b462 libsystem_kernel.dylib`__pthread_kill + 10 frame #1: 0x00007fff205c9610 libsystem_pthread.dylib`pthread_kill + 263 frame #2: 0x00007fff2051c720 libsystem_c.dylib`abort + 120 frame #3: 0x0000000100044ab8 monotouchtest`xamarin_assertion_message(msg="The method %s has not been implemented for CoreCLR.\n") at runtime.m:1474:2 frame #4: 0x0000000100013f0d monotouchtest`mono_runtime_invoke(method=0x0000000100e5afe0, obj=0x0000000100e5afd0, params=0x00007ffeefbfdd28, exc=0x0000000000000000) at mono-runtime.m:1946:2 frame #5: 0x00000001000a1a69 monotouchtest`native_to_managed_trampoline_30(self=0x0000000100e5bad0, _cmd="xamarinApplySelector", managed_method_ptr=0x00000001001d5028, token_ref=12113) at Microsoft.macOS.registrar.coreclr.x86_64.m:1371:2 frame xamarin#6: 0x00000001000a1bcc monotouchtest`-[__MonoMac_NSActionDispatcher xamarinApplySelector](self=0x0000000100e5bad0, _cmd="xamarinApplySelector") at Microsoft.macOS.registrar.coreclr.x86_64.m:38540:3 frame xamarin#7: 0x00007fff2143bba9 Foundation`-[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] + 935 frame xamarin#8: 0x00007fff2143b6a1 Foundation`-[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:] + 124 frame xamarin#9: 0x000000010005cc89 monotouchtest`xamarin_dyn_objc_msgSend at trampolines-x86_64-objc_msgSend.s:15 ```
rolfbjarne
added a commit
that referenced
this pull request
May 4, 2021
Next failure is: > monotouchtest[8307:20722735] Xamarin.Mac: The method mono_runtime_invoke has not been implemented for CoreCLR. ``` * frame #0: 0x00007fff2059b462 libsystem_kernel.dylib`__pthread_kill + 10 frame #1: 0x00007fff205c9610 libsystem_pthread.dylib`pthread_kill + 263 frame #2: 0x00007fff2051c720 libsystem_c.dylib`abort + 120 frame #3: 0x0000000100044ab8 monotouchtest`xamarin_assertion_message(msg="The method %s has not been implemented for CoreCLR.\n") at runtime.m:1474:2 frame #4: 0x0000000100013f0d monotouchtest`mono_runtime_invoke(method=0x0000000100e5afe0, obj=0x0000000100e5afd0, params=0x00007ffeefbfdd28, exc=0x0000000000000000) at mono-runtime.m:1946:2 frame #5: 0x00000001000a1a69 monotouchtest`native_to_managed_trampoline_30(self=0x0000000100e5bad0, _cmd="xamarinApplySelector", managed_method_ptr=0x00000001001d5028, token_ref=12113) at Microsoft.macOS.registrar.coreclr.x86_64.m:1371:2 frame xamarin#6: 0x00000001000a1bcc monotouchtest`-[__MonoMac_NSActionDispatcher xamarinApplySelector](self=0x0000000100e5bad0, _cmd="xamarinApplySelector") at Microsoft.macOS.registrar.coreclr.x86_64.m:38540:3 frame xamarin#7: 0x00007fff2143bba9 Foundation`-[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] + 935 frame xamarin#8: 0x00007fff2143b6a1 Foundation`-[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:] + 124 frame xamarin#9: 0x000000010005cc89 monotouchtest`xamarin_dyn_objc_msgSend at trampolines-x86_64-objc_msgSend.s:15 ```
rolfbjarne
added a commit
that referenced
this pull request
May 14, 2021
…delegate.
* CoreCLR doesn't support generic Action delegates in reverse (P/Invokes), so
we need to find a different solution.
* The native CGPDFOperatorTable callback API is not very friendly to us,
because we can't pass it callback-specific data, which means that the
managed caller must conform to the FullAOT requirement of the managed
callback (must be a static function; must have a MonoPInvokeCallback
attribute).
* We can leverage the new function pointer syntax in C# 9 to make these
requirements enforced by the C# compiler (unmanaged function pointer +
UnmanagedCallersOnly attribute). The resulting API is still clunky to use,
but I don't see any way around that.
Fixes this monotouch-test failure with CoreCLR:
[FAIL] Tamarin : System.Runtime.InteropServices.MarshalDirectiveException : Cannot marshal 'parameter #3': Non-blittable generic types cannot be marshaled.
at CoreGraphics.CGPDFOperatorTable.CGPDFOperatorTableSetCallback(IntPtr table, String name, Action`2 callback)
at CoreGraphics.CGPDFOperatorTable.SetCallback(String name, Action`2 callback)
at MonoTouchFixtures.CoreGraphics.PDFScannerTest.Tamarin() in xamarin-macios/tests/monotouch-test/CoreGraphics/PDFScannerTest.cs:line 102
Ref: dotnet/runtime#32963
rolfbjarne
added a commit
that referenced
this pull request
May 17, 2021
…delegate. (xamarin#11560) * CoreCLR doesn't support generic Action delegates in reverse (P/Invokes), so we need to find a different solution. * The native CGPDFOperatorTable callback API is not very friendly to us, because we can't pass it callback-specific data, which means that the managed caller must conform to the FullAOT requirement of the managed callback (must be a static function; must have a MonoPInvokeCallback attribute). * We can leverage the new function pointer syntax in C# 9 to make these requirements enforced by the C# compiler (unmanaged function pointer + UnmanagedCallersOnly attribute). The resulting API is still clunky to use, but I don't see any way around that. Fixes this monotouch-test failure with CoreCLR: [FAIL] Tamarin : System.Runtime.InteropServices.MarshalDirectiveException : Cannot marshal 'parameter #3': Non-blittable generic types cannot be marshaled. at CoreGraphics.CGPDFOperatorTable.CGPDFOperatorTableSetCallback(IntPtr table, String name, Action`2 callback) at CoreGraphics.CGPDFOperatorTable.SetCallback(String name, Action`2 callback) at MonoTouchFixtures.CoreGraphics.PDFScannerTest.Tamarin() in xamarin-macios/tests/monotouch-test/CoreGraphics/PDFScannerTest.cs:line 102 Ref: dotnet/runtime#32963
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Aligned with XA too, see dotnet/android#4383.
We'll start using Apple instead of iOS for these things at the IDE level since many
behaviors don't actually depend on iOS but also apply to tvOS, watchOS, and so on.
These capabilities go before other imports just in case additional packages/targets
from the SDK need to access them too.