[Feature]: Visual Studio WinUI designer extension on the shared design-time protocol

Depends on: shared design-time protocol and devtools support (microsoft/winappCli#636)

Summary

Build a Visual Studio extension that provides the WinUI designer experience in one place: the visual designer and its live visualizer / tree inspection surface.

This is the Visual Studio-specific client for the same shared design-time base that powers the CLI devtools proposal and the VS Code extension. The first release should be experimental, with a clear path to harden it and potentially inbox it into Visual Studio later.

Problem

Visual Studio already owns some XAML tooling, but the missing designer experience still lives outside the standard editor flow. At the same time, the shared design-time work we want for VS Code, Copilot, and other clients should not be rebuilt separately for Visual Studio.

Without a shared base, we either duplicate the designer stack or end up with incompatible feature sets across editors.

Goals

• Deliver the WinUI designer as a Visual Studio extension
• Combine the visual designer and visualizer into one extension experience
• Reuse the same shared design-time engine and protocol as the CLI devtools surface
• Start as an experimental extension, then harden based on feedback
• Keep the Visual Studio surface aligned with the VS Code and agent clients

Non-goals

• Rebuilding Visual Studio's existing XAML language service
• Replacing Visual Studio's run/debug/hot reload features
• Creating a separate protocol just for Visual Studio
• Shipping a full Visual Studio replacement or a general UI editor

Proposed behavior

Extension shape

• Ship as a Visual Studio extension (VSIX) first.
• Initial release should be clearly experimental / opt-in.
• The extension should live alongside the shared extension codebase so the Visual Studio and VS Code surfaces can reuse the same core pieces.

Designer experience

• Provide a WinUI designer surface inside Visual Studio.
• Include the visualizer / preview surface and the ability to inspect the running UI tree.
• Reuse the shared protocol for attach, tree enumeration, property inspection, and supported edits.

Shared base

• Visual Studio should be a client of the same design-time engine, not a fork of it.
• The extension should share protocol contracts, core state handling, and UI semantics with the VS Code extension where practical.
• Only the host shell should be VS-specific.

Key implementation constraints

• Keep the engine and protocol shared across editor surfaces
• Avoid duplicating the designer logic in Visual Studio and VS Code
• Make the experimental release easy to validate and iterate on
• Keep the extension focused on designer/visualizer scenarios, not every VS feature

Migration path

1. Ship the extension experimentally in Visual Studio.
2. Validate that the shared design-time base serves both VS and VS Code cleanly.
3. Harden the extension and decide whether it should remain a VSIX or become inboxed as part of Visual Studio.

Success criteria

• A developer can open a WinUI app in Visual Studio and use the new designer extension
• The designer and visualizer work on top of the same shared protocol as the CLI devtools surface
• VS and VS Code clients stay aligned instead of diverging
• The extension proves out a path to eventual Visual Studio inboxing

Why this matters

This is how the designer reaches Visual Studio without becoming yet another isolated implementation: one shared design-time core, one Visual Studio shell, and one roadmap.