Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Developers can target macOS UI with .NET 6 #44736

Closed
26 of 32 tasks
Tracked by #2536
maddymontaquila opened this issue Nov 13, 2020 · 16 comments
Closed
26 of 32 tasks
Tracked by #2536

Developers can target macOS UI with .NET 6 #44736

maddymontaquila opened this issue Nov 13, 2020 · 16 comments
Assignees
Labels
area-Meta Cost:L Work that requires one engineer up to 4 weeks os-mac-os-x macOS aka OSX Priority:1 Work that is critical for the release, but we could probably ship without User Story A single user-facing feature. Can be grouped under an epic.
Milestone

Comments

@maddymontaquila
Copy link
Member

maddymontaquila commented Nov 13, 2020

This work is the evolution of existing Xamarin.Mac solution but built on CoreCLR VM foundations. The goal is to expose macOS APIs to allow developers to leverage macOS APIs such us Cocoa, Catalyst system and other native macOS APIS in the way they can build applications which run locally or are distributed via Mac App Store.

Work Items

@marek-safar marek-safar transferred this issue from dotnet/xamarin Nov 16, 2020
@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added the untriaged New issue has not been triaged by the area owner label Nov 16, 2020
@Dotnet-GitSync-Bot
Copy link
Collaborator

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

@marek-safar marek-safar added User Story A single user-facing feature. Can be grouped under an epic. area-Meta and removed untriaged New issue has not been triaged by the area owner labels Nov 16, 2020
@marek-safar marek-safar added Priority:1 Work that is critical for the release, but we could probably ship without Cost:L Work that requires one engineer up to 4 weeks labels Nov 16, 2020
@jkotas
Copy link
Member

jkotas commented Nov 16, 2020

If we need compatibility for the existing bindings, we may also need to add "Special handling of nint/nuint/nfloat" in CoreCLR. Related: #4233 #13788

@marek-safar marek-safar self-assigned this Nov 20, 2020
@marek-safar marek-safar changed the title Xamarin/Blazor developers can target macOS with .NET 6 Xamarin/Blazor developers can target macOS UI with .NET 6 Jan 27, 2021
@AaronRobinsonMSFT
Copy link
Member

@rolfbjarne and @janvorli I have added a checkbox above for validating the signally logistics as they relate to customer crash collection mechanisms. I need to defer for how to validate these scenarios.

/cc @jeffschwMSFT

@jeffschwMSFT
Copy link
Member

This is also an area where coreclr and mono provide different experiences. For mono providing a hook so that textual traces would be produced was at the tip of possible. coreclr provides an x-plat post mortem diagnostic experience (out of proc). So this is likely an area where we can provide an enhanced experience in addition to the signal approach, but perhaps instead of that one as well.

@rolfbjarne
Copy link
Member

@jeffschwMSFT my main concern is that we don't prevent people from using custom crash-reporting mechanisms, and in that regard it's important to know if CoreCLR are using signals in any way right now (for instance: are NullReferenceExceptions implemented by handling SIGSEGVS like they are on Mono? And what out floating point exceptions such as division by zero / SIGFPE?)

Also on some platforms it's not possible to do anything out of proc (this is the case on iOS - which is currently not a target platform for CoreCLR, but may be in the future).

@janvorli
Copy link
Member

janvorli commented Feb 2, 2021

@rolfbjarne we use signals for handling hardware exceptions like SIGSEGV and SIGFPE on Linux, but not on MacOS where we use exception ports (I was planning to migrate to signals on macOS too soon). But we only handle them when they occur in our code (managed code for both and SIGSEGV also in a few related JIT helpers). When they happen at other places, we call the previously registered handler to give a chance to handle it e.g. in a custom host.
If a native shared library loaded after the runtime registers such handler, we currently rely on it behaving the same way - handling the signals only when they know the signal belongs to their component and calling the previous handler if they don't.
One important thing to note is that we register the SIGSEGV handler as using an alternate stack so that we can handle stack overflow and print full managed stack trace when it occurs. That might be something that the previously registered handlers may have a problem with. Our handler is able to run on both alternate stack and regular stack though in case some other component registers a SIGSEGV handler running on a regular stack and calls back to us.

@rolfbjarne
Copy link
Member

rolfbjarne commented Feb 2, 2021

@janvorli I think we'll have to come up with some solution then, because that will interfere with third-party crash reporters.

If a native shared library loaded after the runtime registers such handler, we currently rely on it behaving the same way - handling the signals only when they know the signal belongs to their component and calling the previous handler if they don't.

The purpose of a crash reporter is to detect and report crashes anywhere in an app, and they all assume that SIGSEGV/SIGFPE are bad and should be treated as a crash (rightfully so IMHO). They have no way of knowing that SIGSEGVs/SIGFPEs in certain parts of the app shouldn't be fatal.

The way we solved this with Xamarin was to let mono handle any signals first, and then chain to the previous handler (like CoreCLR doing) + add API to have third-party code (re)install mono's signal handlers, so that third-party code doesn't have to be initialized before mono (which is usually not possible).

This is described here: https://www.mono-project.com/docs/advanced/signals/

This use case is narrow enough that I don't think we have to provide an identical API in CoreCLR, but we should at least find a solution to the problem.

@jkotas
Copy link
Member

jkotas commented Feb 2, 2021

What are the third-party crash reporters that this is important to solve for?

@joperezr joperezr added this to the 6.0.0 milestone Feb 9, 2021
@marek-safar marek-safar changed the title Xamarin/Blazor developers can target macOS UI with .NET 6 Developers can target macOS UI with .NET 6 Feb 25, 2021
@rolfbjarne
Copy link
Member

@jkotas

What are the third-party crash reporters that this is important to solve for?

Crashlytics is one example of a third party crash reporter some of our customers use.

@bruno-garcia
Copy link
Member

bruno-garcia commented Mar 19, 2021

Sentry is another crash reporting tool with customers using Mono on iOS/macOS.

@jeffhandley jeffhandley added the os-mac-os-x macOS aka OSX label Aug 17, 2021
@danmoseley
Copy link
Member

@steveisok @marek-safar can we close this now? are any tasks remaining for the 6.0 release?

@joperezr
Copy link
Member

joperezr commented Sep 8, 2021

@steveisok @marek-safar friendly ping 😄

@marek-safar
Copy link
Contributor

We can close it if it's bothering you but this will be fully completed after GA

@joperezr
Copy link
Member

joperezr commented Sep 9, 2021

Not bothering for sure 😄 just doing bookkeeping on issues marked as 6.0 for our areas. If this will be completed post 6.0 but it's not finished yet, I'll just switch the milestone.

@mairaw
Copy link
Contributor

mairaw commented May 26, 2023

This issue title seems to be targeted at .NET 6 and I'm trying to clean up the .NET 6 project. Do we need to update the issue or create a new one?

@jeffhandley
Copy link
Member

This issue title seems to be targeted at .NET 6 and I'm trying to clean up the .NET 6 project. Do we need to update the issue or create a new one?

I defer to @marek-safar on this

@ghost ghost locked as resolved and limited conversation to collaborators Jul 1, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-Meta Cost:L Work that requires one engineer up to 4 weeks os-mac-os-x macOS aka OSX Priority:1 Work that is critical for the release, but we could probably ship without User Story A single user-facing feature. Can be grouped under an epic.
Projects
No open projects
Development

No branches or pull requests