Profiling: capture is cross-platform from 1.0.7; be precise about what still needs .NET Framework Capturing a plug-in profile no longer uses a bundled .NET Framework helper — the extension starts and stops profiling over the Web API — so the Windows-only framing across these pages was wrong. Also corrects a claim that was never right: Requirements said replaying a run under the debugger 'works everywhere'. The generated test lives in a plug-in test project targeting net471, so dotnet build compiles it anywhere but dotnet test needs the Framework test host (on Linux it aborts with "Could not find 'mono' host"). That is now stated once, precisely, on each page that mentions it. Adds what capture actually does — clone the step, move its images, disable the original — since that explains both why naive Web-API step edits never fired it and why a step can be left disabled if a session is interrupted.
Wiki: how-to only, and a results screenshot with real rows Dropped the rationale and the "what it doesn't do" discussion — the .fetchxml-versus-in-code section, the service-worker explanation, the why-inheritance-works reasoning — and the notes about where the screenshots come from. The pages now say what to click and what happens. The results screenshot showed an empty grid, because the sample query filtered on an account id that matched nothing. The query now filters on state, so the frame shows ten accounts with name, number, telephone and created-on, and the suite fails if the query comes back with no rows.
Refresh the profiling frames; correct the Locals caption All twelve frames re-captured after fixing the screenshot helpers: they had been leaving every previously-clicked button outlined, so a frame for one button appeared to highlight three others too. Each frame now highlights exactly the control its step is about. The Locals caption promised more than the frame showed — the Variables pane's scopes are collapsed when a session pauses, so it showed the call stack and an empty Locals. The prose now says what is there and tells you to expand Locals for the captured Target; the suite also logs a warning when Locals has not populated, so that caption cannot silently drift again.
Profiling a Plug-in Run: rewrite for users; document both buttons and the breakpoint flow Replay & debug now replays under the debugger, so the walkthrough covers setting a breakpoint, replaying, and what you get when it stops (the captured Target and derived values in Locals, a call stack into the plug-in). Generate Replay Test is documented as the separate commit-and-CI job. New screenshots throughout, taken from the end-to-end suite against a plug-in that does real work (validate the name, derive a region and code, trace it) rather than a probe that traced an id. Drops the two caveats that are now fixed: the CodeLens can stop profiling, and Run/Debug Test at Cursor works for plug-in tests.
Add a step-by-step "Profiling a Plug-in Run" walkthrough with screenshots Covers the whole capture → download → replay loop, with the button, dialog or picker used at each step outlined in the screenshot. Both ways of choosing which step to profile are documented: the panel's Profile next run, and the per-step Profile CodeLens on the [CrmPluginRegistration] attribute. The frames are captured by the end-to-end suite while it drives the real UI (DVPT_E2E_SHOTS=1), so they cannot drift from the product without the suite noticing. The org name and URL are redacted. Two current limitations are stated rather than glossed over: stopping profiling from the Profile: On lens does not work (pete-mc/dataverse-powertools#251, use the Active profiles list), and Run/Debug Test at Cursor plus gutter icons do not work for plug-in tests (pete-mc/dataverse-powertools#252, use the Testing view). Linked from the sidebar and from Debugging Plugins.