Add support for Avalonia .axaml File Extensions

[jtbrower]

Avalonia uses the "axaml" extension within Visual Studio to avoid clashing with Microsoft's tooling. That means that my favorite XamlStyler will not format documents as I have grown to love with WPF.

Describe the solution you'd like
A Configuration property that gives users the option to list file extensions that the XamlStyler should handle.

[grochocki]

It appears all the issues leading to the file extension change are with VS itself (AvaloniaUI/Avalonia#4102). I am trying to understand if there are any "gotchas" with just processing .axaml files as .xaml files. If Avalonia === XAML, then that should not be a problem, but I am worried about the introduction of "non-standard XAML" which could introduce compatibility issues. As long as we can continue to process files exactly the same, then I think I would be open to this.

[jtbrower]

@grochocki I agree with you fully. Maybe @grokys @danwalmsley from the Avalonia team can give some insight. I see it as even if there are compatibility issues I would prefer to have your tool beautify my xaml and then I would manual fix any issues.

[maxkatz6]

@grochocki
I actively use XamlStyler in Avalonia projects for last months, and it works good enough.
Avalonia XAML is not a "non-standard XAML", it's still very similar to WPF XAML but with some specific features.

Actually I noticed only one problem. XamlStyler forces replacing > with > inside of string values.
In Avalonia we use CSS-like selectors syntax for styles, so it is pretty common code:

<Style Selector="RadioButton > TextBlock">
  <Setter Property="Foreground" Value="{DynamicResource RadioButtonForegroundPointerOver}" />
</Style>

Although code with > will be compiled successfully, I need to replace it back for better readability.

[jmacato]

in a nutshell, AXAML is still your good ol' XAML we were forced to rename because VS tooling isnt up to snuff lately...

[yannduran]

@maxkatz6 how are you enabling XamlStyler to process axaml files? I see nowhere to do that.

@jmacato do you have plans to use .xaml instead of .axaml at some point?

[jmacato]

@yannduran we supported and still supports xaml files.. axaml is just some kind of alias file extension since VS XAML tooling team isnt too cooperative with us.

[maxkatz6]

@yannduran as @jmacato said, I use .xaml instead of .axaml.

[jtbrower]

@yannduran @maxkatz6 but the risk of using xaml instead of axaml is that Visual Studio does what it wants to your xaml and project files. I renamed everything to use axaml to avoid the Visual Studio headaches. If the XamlStyler team would recognize that extension or allow for us to enter that extension in configuration and acknowledge that we could run into issues, that would be great. I miss this tool but after tasting Avalonia hope I won't be using much WPF for new projects.

[maxkatz6]

@jtbrower it's true about Visual Studio, but I am used to it and keep my project files clean manually. So I don't really need another file extension. And probably some day Microsoft will fix it on their side.
Although, I agree with you, that right now axaml is more preferable for most users.

[yannduran]

@jmacato sorry I asked the wrong question. i should have asked "do you have plans to support .axaml any tme soon?", as per this feature request.

@maxkatz6, @jtbrower thanks!

[jtbrower]

@yannduran it would actually be @grochocki who is with the XamlStyler team. @jmacato is with Avalonia. But I am with you! Hoping I can soon use it with axaml file extensions even if I have to correct things like changing &gt to > after running it. I have really been missing it lately.

[jtbrower]

@maxkatz6 I have a lot of confidence in most all Microsoft Engineers as individuals, but when it comes to Visual Studio related tooling I have much less confidence. Working with xaml for 13 years using their tooling has predisposed me to think negative thoughts, LOL. Before I renamed xaml to axaml, it was mucking with my csproj files. I hate that because I too keep mine really tidy. Especially with Directory.Build.props and targets files for us to use.

[grochocki]

Sorry for the long delay in responding to this issue -- we would like to add support for Avalonia. To help capture any possible quirks, we would like to explore adding support behind an opt-in setting.

Proposal:

• Display Name: Enable Experimental Avalonia Support
• Property: EnableAvaloniaSupport
• Category: Miscellaneous
• Description: When set to true, XAML Styler will treat files with the .axaml extension like those with the .xaml extension and make small behavioral changes to accommodate the Avalonia XAML dialect. Please see project documentation for additional details.
• Default: false

#302 addresses the only lingering issue with handling the CSS-like selectors syntax. While this syntax does go against how special characters are typically treated in XAML, it also seems to be fundamental to styling in Avalonia, so would not make much sense to add support for .axaml but not support this syntax. Instead of exposing a new setting for this, we'd like to fold this into this one setting for Avalonia support, and only for the Selector attribute.

Moving forward, we can capture any additional quirks behind this EnableAvaloniaSupport setting, assuming they can be cleanly isolated. I think we would be unlikely to modify the defaults or add any additional Avalonia-specific settings, but we can also treat any "big" things that may come up on a case-by-case basis if/when they arise.

[jtbrower]

@grochocki Happy New Year and thank you! I agree that your approach is acceptable.

[maxkatz6]

@grochocki thank you for the response!
Note, that Avalonia works with *.xaml too, so we shouldn't detect Avalonia syntax basing on file extension.
Probably it makes sense to check root namespace in the xaml file.

On other hand it's possible to have file with user defined namespace
<local:Control xmlns:local="..." />
And it will be hard to detect framework on this point.

[grochocki]

Added with #321.

[ArchLeaders]

Is this feature added to the 2022 version?