Semantic/Syntax model for XAML files??

[amine-aboufirass]

I've been experimenting with the Roslyn syntax and semantic models and found them to be quite powerful in identifying things like dependencies between projects and types in large solutions.

I'd like to ask whether it's possible to take advantage of either of these APIs to manipulate and glean information from WPF XAML files? These files also can refer to .NET namespaces and types via bindings or other mechanisms and it would be great to be able to include these in my code analysis.

Thanks in advance.

[CyrusNajmabadi]

@mgoertz-msft ?

[mgoertz-msft]

I'm afraid there is no such thing at the moment. The XAML language service is closed source in Visual Studio, but I would also love to have the ability to leverage more of the Roslyn infrastructure, at least syntax trees for XAML files, since the syntax representation within the VS language service is read-only. This would make analyzer and code fix/refactor development for XAML much easier for us as well.

[amine-aboufirass]

The XAML language service is closed source in Visual Studio,

That's a shame. I know that Resharper does somehow map dependencies between XAML and source files. Have they just created their own closed-source language service, or do they have some sort of agreement with Microsoft that allows them to use the one in Visual Studio?

Are there currently any efforts to open up the language service to XAML files as well?

[mgoertz-msft]

That would have to be their own implementation since there is no public extensibility API for the XAML language service.

Are there currently any efforts to open up the language service to XAML files as well?

Currently? No.

[CyrusNajmabadi]

I think it would be good to get into specifics about what is being asked for. For example, how would the semantic model map specifically onto xaml.

It's not a hypothetical API. It's a real API with very clear semantics. Do those semantics work for xaml in the first place?

[mgoertz-msft]

The semantic model behind XAML is literally the Roslyn one since we get all of our type information, or perhaps I should say INamedTypeSymbol information, from the project's Compilation. The only thing that the XAML language service does is add some extra platform-specific rules for how the XMAL maps to the Roslyn symbols.

Take this WPF XAML for example:

<Window x:Class="WpfApp1.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="450" Width="800">
    <Grid>
    </Grid>
</Window>

The Window tag maps to the type symbol for System.Windows.Controls.Window and we know that because the System.Windows.Controls CLR namespace, amongst others, has been registered with the default XML namespace via the XmlnsDefinitionAttribute in one of the project's reference assemblies for WPF. The Title attribute in XAML is simply a property on Window (or one of its base classes).

Of course, then there are some more complicated rules for attached properties, resources, bindings, etc., but almost everything you see in XAML maps back to a Roslyn type symbol in one form or another.