Expose Runtime Crash Reporting (MERP) capabilities in .NET Core

[alexischr]

The API for MERP telemetry in Mono is currently located exclusively in
https://github.com/mono/mono/blob/master/mcs/class/corlib/Mono/Runtime.cs#L101-L270

We will need to reintroduce this Mono-specific code in System.Private.Corlib or elsewhere, at least the subset needed by VS4Mac telemetry.

[alexischr]

@stephentoub @marek-safar This will be a required API for VS4Mac on .NET 5.0 - it is how VS4Mac provides telemetry to Microsoft Error Reporting. How do you propose we reintroduce it?

The solution of least friction would probably be to put the API in Mono's System.Private.CoreLib.dll. We can also try to unify the API CoreCLR's, or create a new one to serve both.

[jkotas]

These APIs look very proprietary to Microsoft. APIs with names like SendMicrosoftTelemetry are not ever going to make it as public .NET Runtime API. There is actually a real risk of very bad PR from APIs like this. We had a few of those over the years. It was never a fun to deal with it.

What would make sense as public .NET Runtime APIs are policy-free APIs that let you register callbacks for interesting events, such as fatal crash, unhanded exception, etc. Visual Studio for Mac can then use these APIs to register callbacks to their own implementations that implements hookup to Microsoft telemetry pipeline.

.NET Framework had APIs like this (e.g. https://docs.microsoft.com/en-us/dotnet/framework/unmanaged-api/hosting/iclrerrorreportingmanager-interface). These APIs were exposed via COM that is not necessarily the most friendly cross-platform way to do it. I think we would want to have a plain-vanilla C callbacks instead. But it is something we can look at as prior art.

[marek-safar]

The existing internal APIs are not something we would like to add to netcore but starting point for hopefully publicly exposable better version. Right now this API is internal, accessible via reflection only, specific to Mono, etc all this should be avoided in net5.

@jkotas who should lead the design work for net5?

[jkotas]

These internal APIs are only needed for VS Mac. Is that correct?

If it is the case, this falls into embedding APIs required to support VS Mac theme. This theme was de-prioritized for .NET 5, so I do not think we are going to spend cycles on designing public APIs and harmonizing this between CoreCLR and Mono in .NET 5.

If we need to start experimenting with VS Mac on .NET 5 Mono, we can keep using whatever mono/mono had to make it work - until we get the harmonizing this class of APIs between CoreCLR and Mono.

[jkotas]

If you would like to see this API happen in .NET 5 as public .NET Runtime API, I think somebody from the VS Mac on .NET 5 virtual team needs to write the initial API proposal. The hard part is to figure what a good public API shape for this should be.

[SamMonoRT]

@marek-safar - I believe it is now ok to remove this from the 5.0 milestone ?

[lambdageek]

We will look at other alternatives to the in-proc mono crash reporting code for a future release.