XAML: two activation events load the extension in workspaces that never use it

[chiaramooney]

Follow-up from the PR #50 review. Two activation events load the extension host in workspaces that never use it. This supersedes two earlier, wrong versions of this issue — see the correction note at the bottom.

workspaceContains:**/*.xaml — its purpose was deleted, the event was not

4ad4295 ("Accelerate staged XAML IntelliSense loading") added this event for a real performance reason. Early activation let the extension findFiles a XAML file, call startClient, and send winui-xaml/warmUp so the expensive .NET + Roslyn + MSBuild project load completed before the user opened a XAML file.

fdeb42d ("Start XAML server on document open") removed that whole mechanism — src/xaml/workspacePreload.ts, the warmUp notification in doStart, and the speculative startClient branch in activateXaml — so IntelliSense always resolves the project for the document the user actually opened. It did not touch activationEvents.

What the event does today: hoists extension-host activation to VS Code startup. activateXaml creates an output channel and a status bar item, registers ~8 commands and some event handlers, and returns. hasOpenXamlDocument is false, so no server starts.

That hoist is close to worthless:

• onLanguage:xaml is also an activation event, so opening a XAML file activates the extension anyway, and VS Code awaits activation before delivering the open event. Time-to-IntelliSense is unchanged.
• Nothing user-visible appears beforehand. renderProjectContextStatus (src/xaml/xamlLanguageService.ts:814-849) hides the status bar item unless a project context status exists, and those only come from a running server.
• workspaceContains:**/[Aa]ppx[Mm]anifest.xml, **/*.appxmanifest, and onLanguage:xml are already activation events, so a packaged WinUI workspace activates at startup regardless. The marginal cost of the .xaml glob lands mostly on WPF and UWP projects that have XAML but no app manifest — precisely the workspaces that never use this extension.

Why it was not simply removed in PR #50: src/test/xaml-workspace-activation.test.ts:11 asserts the event is present in package.json. That test was added by the same commit that removed the event's purpose, and it only asserts the string exists — a change detector, not a behavioral guarantee. Removing the event is a deliberate decision that must also update that test, so it did not belong in this PR.

onLanguage:csharp — one gated notification

Added by c33a99c ("Recommend C# Dev Kit for XAML code-behind") solely to trigger that recommendation. CsharpDevKitNotificationGate.shouldShow (src/xaml/csharpDevKitNotification.ts:16-28) returns false unless the path ends in .xaml.cs.

Opening any .cs file in any C# project activates the whole extension — debug configuration provider, debug adapter factory, manifest custom editor, manifest IntelliSense, XAML client registration, output channel, status bar item — to test a filename suffix and usually do nothing. It buys the ability to suggest Dev Kit when a user opens code-behind with no XAML file open.

Timing

Only workspaceContains is evaluated during VS Code startup. onLanguage:csharp activates later, on first C# document open — a real cost, but not a startup-time one.

Suggested work

• Remove workspaceContains:**/*.xaml and update src/test/xaml-workspace-activation.test.ts to assert the intended behavior (no activation without an open XAML document) rather than the presence of a string. Confirm with code --prof-startup on a WPF workspace first.
• Decide whether onLanguage:csharp earns its cost, or whether the Dev Kit recommendation should fire from the XAML path instead (e.g. opening a .xaml with a sibling .xaml.cs), accepting that it would no longer fire for code-behind opened alone.

Correction history

An earlier version of this issue called the .xaml glob "vestigial" with no evidence. A second version overcorrected and called it an intentional warm-up, on the strength of the test alone. Neither was right: the commit history shows a deleted purpose plus a retained line, and the test locks in the line rather than any behavior.

[chiaramooney]

Fixed in 877ae0d on nmetulev/winui (PR #50) — onLanguage:csharp is removed.

Only that one event was removed. Investigating the fix overturned this issue's claim that workspaceContains:**/*.xaml does nothing.

The Dev Kit recommendation is gated to paths ending in .xaml.cs (csharpDevKitNotification.ts:16-28). Any workspace containing a .xaml.cs also contains the .xaml it is code-behind for — so workspaceContains:**/*.xaml already activates the extension in every workspace where that gate can pass. onLanguage:csharp could only add activation in C# workspaces with no XAML, which is exactly where the gate always returns false. Strictly redundant, removed with no behavior change.

The glob is the opposite: it is what registers recommendCsharpDevKit in the first place. Removing it would silently kill the recommendation for anyone who opens only code-behind in an unpackaged WinUI project (packaged ones still activate via the appxmanifest globs). My earlier analysis missed this because I traced the server-start and status-bar paths but not the notification path.

So the accurate summary is:

• onLanguage:csharp — redundant, removed.
• workspaceContains:**/*.xaml — load-bearing for the Dev Kit recommendation, kept. It still does not speed up time-to-IntelliSense (onLanguage:xaml covers that, and VS Code awaits activation before delivering the open event), and its warm-up purpose from 4ad4295 was indeed deleted by fdeb42d. But "no longer speeds anything up" turned out not to mean "does nothing."

src/test/xaml-workspace-activation.test.ts no longer asserts a package.json string. It now states the invariant — activate for XAML-containing workspaces, do not activate on plain C# — so the next person to touch this gets a real signal.

Remaining open question, if anyone wants to pursue it: move the Dev Kit recommendation to a XAML-driven trigger (e.g. opening a .xaml with a sibling .xaml.cs), which would free the glob to be removed as well, at the cost of not firing for code-behind opened alone. Tracked in the architecture doc as review question 9. Closing this issue since the redundant event is gone.

Full unit suite green: 1089 passing, eslint 0 errors.