XAML F12 on SDK and NuGet types: consider a docs link or synthesized declaration

Summary

F12 in XAML markup currently does nothing for types and members that come from compiled metadata — WinUI SDK controls (Button, Grid), NuGet/toolkit controls, and SDK properties reached through {TemplateBinding …}, Setter.Target, and Storyboard.TargetProperty.

This is deliberate today and is documented in the README under Where Go to Definition works. The smoke suite asserts these as graceful null results at the metadata boundary (for example definition(TemplateBinding 'Background'): null (framework member, graceful metadata boundary)), so it is a designed limit rather than an accident.

The question raised in review was whether this is the right ceiling. This issue records the research so we do not have to redo it.

Why it happens

ResolveDefinitionAsync resolves the symbol correctly, then filters for a source location:

var (symbol, _) = await ResolveNamedSymbolAsync(p).ConfigureAwait(false);
var location = symbol?.Locations.FirstOrDefault(l => l.IsInSource);
return location != null ? ToLspLocation(location) : null;

For a metadata symbol every Location is IsInMetadata, so the filter yields nothing. The symbol resolution is not the problem — we have the ISymbol in hand. What is missing is a document to navigate to.

We are at parity with Visual Studio

Worth stating plainly, because it sets the bar:

• VS 2022, WinUI 3 XAML markup — F12 on an SDK control does nothing. Metadata-as-source navigation is available from C# files, not from XAML markup. The same is reported for WPF XAML.
• C# Dev Kit in VS Code — does support metadata-as-source / decompiled navigation, but again only in C# files.

So this is not a gap against the incumbent tooling. It is a gap against what the C# language experience does in general, which is why it feels wrong.

Options, roughly in cost order

1. Documentation link for SDK types (cheap, high value)

We already enrich hover with XML doc <summary> text for framework types and members (asserted by the round-66 smoke scenarios), so the data is in hand. Adding a View documentation link to hover — the learn.microsoft.com URL is derivable from the fully-qualified type name — answers the underlying user need ("what is this and what can it do") without any navigation machinery.

This is probably the best value for effort and does not require F12 to change at all.

2. Synthesized declaration document (medium)

Generate a read-only C# declaration buffer from the ISymbol and return a Location into it.

• Roslyn's own IMetadataAsSourceFileService lives in Microsoft.CodeAnalysis.Features, which is not supported public API for outside consumers and carries no compatibility guarantees. Not a good dependency for a shipping extension.
• The supported path is to synthesize it ourselves with SyntaxGenerator (Microsoft.CodeAnalysis.Editing), which we already have transitively via Microsoft.CodeAnalysis.CSharp.Workspaces 4.14.0 — no new package reference required.
• Needs a client-side story: a custom read-only URI scheme plus a TextDocumentContentProvider in the extension, and a decision about where the buffer lives.

Note this only ever produces signatures, not implementations — which for a XAML author is arguably no better than hover.

3. Defer to C# Dev Kit (cheap, partial)

We already recommend C# Dev Kit for code-behind. It resolves metadata navigation in .xaml.cs. This does not help someone sitting in markup, so it is a talking point rather than a fix.

4. Source navigation into WinUI (fragile)

WinUI 3 is open source, so a control type could in principle link to microsoft/microsoft-ui-xaml. Version-to-tag mapping and the fact that the projected .NET surface is generated make this brittle. Not recommended.

Recommendation

Do 1 (docs link on hover). Treat 2 as a larger piece of work worth doing only if there is real user demand, since it delivers signatures rather than implementations and requires client-side plumbing.

Out of scope for PR #50

Recorded as follow-up. The current behaviour is intentional, documented, and matches Visual Studio.

Start at ResolveDefinitionAsync and the README section “Where Go to Definition works”; review the smoke scenarios covering metadata-bound XAML members and the documented options. Determine whether the recommended hover documentation link or synthesized declaration is the intended follow-up, then define completion around the chosen navigation or documentation behavior and its client-side implications.