Debugging and XAML

Debugging and XAML

RoseMCP can debug a running .NET process and inspect and edit a running UWP or WinUI 3 app's interface, without Visual Studio and without loading the solution a second time. This is Windows only: the debugger is ICorDebug and the XAML provider is native.

There are three ways in, and they all drive the same session:

• Agents use the rose_debug_* and rose_xaml_* tools.
• The Rose panel is a toolbar inside the running app. Use it to point at an element, and to measure and magnify what the app draws.
• The inspector is a window beside the app, with the event tail, breakpoints, the stack and its values, threads, and the live visual tree.

An agent can attach, you can select an element in the app, and the inspector shows the element's properties: all three look at the same selected element. How the processes connect is on Architecture.

Starting a session

Tool	Use it to
rose_debug_launch	Start a .NET executable under the debugger, so its startup is observed.
rose_debug_launch_uwp	Activate a packaged UWP app by AUMID under the debugger, from its first line.
rose_debug_attach	Attach to a process that is already running, by process id. Local, same-user processes only.
rose_debug_list	List sessions, to recover an id you did not keep.
rose_debug_detach	End the session and leave the app running.

A session started by one agent client appears in the tray and the inspector, but other agents cannot drive it.

Debugging

Tool	Use it to
rose_debug_events	Read what happened since a cursor: exceptions with stacks, log output, module loads, hits.
rose_debug_add_tracepoint	Log each hit on a method and keep running, with an optional condition.
rose_debug_set_breakpoint	Stop on a method and record the stack and locals. The app resumes on its own after a safety timeout, 30 seconds by default, so an unattended stop cannot freeze it.
rose_debug_continue, rose_debug_step	Resume, or step in, over or out.
rose_debug_evaluate	Read a value while stopped: name, name.field.field, items[3]. Read straight from memory; no code in the app runs.

A location is Namespace.Type.Method, with Assembly! in front when the assembly name is not the namespace's first segment, for example Rose.ProbeApp.WinUi!Rose.ProbeApp.WinUi.MainWindow.Tick. The inspector can also stop the target where it stands (Pause) and hold a stop open while you read it.

Limits:

• Local names and line-by-line stepping need a PDB from the same build.
• Evaluation reads fields only. Property getters, method calls and ToString are not run, because running code inside a stopped app can hang it.
• Conditions are simple comparisons, name OP literal.

XAML

Tool	Use it to
rose_xaml_tree	Read the visual tree. Every element has a handle, a type, its x:Name where it has one, and an address such as #Pair/Border[1] that names it even where it does not.
rose_xaml_properties	Read one element's properties, what set each one (Local, Style, Inherited…), and the XAML file and line where known.
rose_xaml_selection	Read the element a person picked in the app, with everything stacked under the click.
rose_xaml_select_element	Select an element by handle, name or address, and outline it in the app.
rose_xaml_deselect	Clear the selection and its outline.
rose_xaml_apply	Apply what a XAML file now says to the running app: properties, added and removed elements, attached properties, keyed resources.

The first XAML call in a session loads the provider into the app and puts up the Rose panel; every call after that is a message to the provider already running there.

Live editing

rose_xaml_apply takes a file path, so the loop is edit the file, apply, edit, apply. Each call compares the file with what was last sent to the app and applies only the difference.

• The first call for a file only records it. What the app was built from is no longer on disk once you have edited the file, so there is nothing to compare against. Call it once before editing, or pass oldXaml with that first call.
• Failed edits are not retried, because resending an added element would add it twice. Each edit reports its own outcome.
• It is a live edit, not a reload. Changes land on the element objects that exist at that moment. Anything that rebuilds that part of the interface, such as navigating away and back or relaunching, gets the compiled markup again. Visual Studio's name for this is XAML Hot Reload.
• Elements added live cannot be given an x:Name. Address them by position instead.

Which framework an app runs is read from the modules it has loaded. UWP on modern .NET, classic UWP and WinUI 3, packaged or not, are all supported.