RNW app e2e debuggability and developer engagement

[asklar]

Today an app can take RNW, modify its source, and ship it as part of their package. In the future they will likely take a drop of the RNW dlls.
Consequently, the app package that ends up in the Store, has no symbols for the app, and may not even have symbols for the RNW dlls. This is in contrast to .net UWP apps where we get symbols. It is similar to Games and other native UWP apps.

The result of this is that whenever we have a reliability bug, functionality regression, or appcompat bug, we won't be able to debug it:

• We don't have app symbols. If the app is 1st party we can pass the bug on to them. Otherwise we rely on the developer/ISV to discover this since there doesn't seem to be an outreach program that's set up.
• Even if the developer ends up getting the bug, they may not be able to debug what's going on. They'll have symbols for their own app, hopefully, as well as symbols/source for RNW. However they won't have symbols/source for WUX.

It is not unreasonable to assume that some portion of the bugs in RNW apps will be in how the RNW dll uses WUX and Comp. This is in contrast to .net UWP apps which have "rails" since they're using a well-tested mature framework like .net and there isn't much logic in .net (it just exposes the UWP apps and types), whereas RNW dlls have a bunch of logic to adapt between the WUX and RN APIs and controls.

So, as it is, my concern is that

• There is no engagement & outreach channel for RNW developers (incl access to Watson)
• Even if there were, we don't have the infrastructure in place to make these bugs actionable/debuggable.

Some of this goes away when RNW moves onto WinUI3, however that may not happen for some time.

[chrisglein]

I think the app developer's story is okay, or at least par for a XAML app. They get all their app symbols and the RNW symbols (because we ship as source). That's parity with a XAML app in that they don't get XAML symbols/source.

For us, yeah we get less, since we're shipping as source. Relief here probably looks like this:

• Shipping as binaries, so we can get concrete symbols to match
• Shipping on WinUI3, where the XAML we're built on is open source and has clear source/symbol pairings

In the meantime, I don't think we need any immediate action, putting this as a discussion topic on the backlog.

[vmoroz]

We are currently planning start working on implementing DLL-based deployment model in Q2 CY 2020 (2nd quarter of calendar year 2020). The debuggability in such scenario is quite important. Based on our previous experience we typically need to provide PDB files and related source files.

The PDB files are easy: they can be part of the developer Nuget package. Alternatively, it would be great if we can publish them to a symbol server. I wonder if the Microsoft symbol server has public access for that.

Accessing source files corresponding to a build is a tricky one. We typically ask to checkout a specific label from the GitHub repo. It is not a simple or intuitive process. I wonder if we can utilize the Microsoft Source Server for that. Alternatively, there might be a service that allows to pull right files from the GitHub. We would need to post-process our PDB files to point to the source server to get the access to sources.

Do we know someone who has more experience with publishing PDB/source for debugging out of GitHub open source projects?

[aeulitz]

@vmoroz "Re: Accessing source files corresponding to a build is a tricky one ... there might be a service that allows to pull right files from the GitHub"

PDB source links?