RNW instances using Hermes should support direct debugging in release builds

[aeulitz]

Summary

Today, Hermes integration in RNW uses build-time switches to exclude direct debugging features in RNW release builds. Direct debugging should work in both debug and release builds.

Motivation

Assuming RNW releases are build-flavor-paired with RNW host apps (e.g. Word, Excel), the current limitation prohibits direct debugging in release versions of RNW host apps and thus diminishes the dev experience which could be particularly relevant for service-delivered (out-of-box) packages.

Basic Example

No response

Open Questions

Direct debugging requires inclusion of Hermes inspector components which are bound to increase the size of the binary. We should measure the size increase and decide whether that's an acceptable perf hit.

[chrisglein]

Having release builds avoid the debugging cost is a defensible position. Apps can opt into this with a compile-time switch, correct. Is the proposal to change the default? Or to better document this so apps know what they are choosing?

[jonthysell]

I think it's reasonable that, if a developer enabled direct debugging in their release app, that it would work.

The template should still enforce the default that it's enabled for debug builds and disabled for release builds.

But is this still an issue though? The release binaries for RNW must include all native code necessary to support direct debug, because new RNW apps, even when they build as debug, use release RNW binaries from NuGet.

[chrisglein]

@aeulitz , this is assigned to you. Is it still on your radar?

Per Jon's comments above, for how binaries are structured for new architecture apps, this means that new architecture apps won't have direct debugging even if set up as a debug app.

Direct debugging is blocked for other reasons too, but once those are resolved this will be a blocker.