Avalonia: RFC: Changing our default file extension for XAML files.

[grokys]

As you've probably realized, each release of VS seems to break our support for XAML files a little more. An example of some issues:

AvaloniaUI/AvaloniaVS#159
AvaloniaUI/AvaloniaVS#157
AvaloniaUI/AvaloniaVS#142
AvaloniaUI/AvaloniaVS#153
AvaloniaUI/AvaloniaVS#95

This all seems to come down to one root cause: despite Visual Studio advertising support for different dialects of XAML, and XAML theoretically being a format that can be used by any framework, Visual Studio essentially treats the XAML file extension as if these files will only come from MS.

We have a two possible solutions to this

1. Continue using the .xaml extension and wait for MS to fix their XAML support. There may be some movement on this as recently I managed to get in touch with a couple of people who might be able to fix some of the problems
2. Use our own extension by default (e.g. .axaml) - Avalonia XAML files with the .xaml extension will still be supported but our templates will create .axaml files. Note: the .xaml file extension will still be supported by the XAML compiler and the rest of our tooling (and probably by Rider IDE).
   The question is mostly about the templates and defaults

What do people think would be the best solution? For reference there was a recent discussion in the WinUI repository about such a move: https://github.com/microsoft/microsoft-ui-xaml/issues/1438

👍 or 👎 ?

[myblindy]

The linked discussion goes quite in depth as to why the normal extension (.xaml) is better, because the language used to describe the UI is XAML, while the framework the language links against can be WPF, UWP, WinUI or Avalonia.

Personally I'm with them, keep the extension, work on VS support for different namespace support (same problem WinUI is facing and trying to fix).

[grokys]

From https://developercommunity.visualstudio.com/content/problem/1066497/vs-opens-incorrect-xaml-designer.html

Ideally the XML chooser would check the default namespace too before the final falling back. Unfortunately, this is old legacy code with no real active owner (I think it belongs to the SQL team), and hasn't been touched in years AFAIK.

That doesn't sound promising, so it looks like the best course might be best to move to our own extension.

[jtbrower]

Coming in from 13+ years WPF here. Although it would be ideal if file extensions were not an indicator of the framework being used, I can certainly appreciate concern that you might be fighting an uphill battle regarding anything Microsoft touches with Visual Studio. I don't mean to sound like a jerk here, but I have banged my head against the wall for a decade plus, always trying to please the XAML designer and I ask myself, for what reason? Historically, turning the XAML designer on crashes Visual Studio with large projects and at best might render what your XAML looks like one month/year and the following month or year without any code changes it won't show a WPF view of the XAML.

Trying to keep the XAML Designer happy is akin to writing XAML for two unique platforms. The Designer and WPF / UWP Runtime. I always wanted the designer to work properly because I had less explaining to do when my customers used my source to design their own systems. Yet its impossible to keep the design tooling happy for anything behind hello world.

The fact that each release breaks your support for XAML files is of no surprise because they continually break my designtime experiences as well. I have finally given up, have come to the point where I have realized that it is an utter waste of development dollars just to assure the designer can render those views. Especially since Hot Reload came out.

My opinion is that I would love nothing more than for all XAML frameworks to stick with the same XAML extension, but is that really practical outside of Microsoft? Avalonia team trying to keep up with Visual Studio's continual unpredictability is going to be a very difficult challenge IMO. Maybe changing it and getting the heck out of their madness is the best thing to do.

Reading comments about this regarding WinUI, I agree that I wouldn't want and glad the WinUI team didn't change the extension. They have the power to coordinate internally and at any given point can make a change that breaks what your team has implemented. Some people mentioned how changing the extension can break third party tooling like R#. Changing to Roslyn broke R# a long time ago; as much as I love the tool you have to buy a new CPU fan just to keep the processor cooled down when using it. If Jetbrains provides support for XAML it will be a fabulous day! I have voted for Avalonia support as well as XAML support in general.

Visual Studio and third party .targets and .props files have a really bad habit of making changes to my csproj files that are often not needed OR they end up hiding files from the solution sending me wonder what project I accidentally moved it to. Eventually I see a "None Remove" line in the project file. One time Visual Studio kept telling me that a type did not exist. I knew vary well I had just created the control, but the compiler couldn't find it. I was tired and again, didn't realize that a "None Remove" was added. I bet you will constantly be fighting an uphill battle with all of the third party code analyzers and Code Rush and Resharper and etc. etc. If you make your own file type you define the rules.

However, from a past comment by @grokys in the WinUI repo, he did explain the troubles that were presented historically by using paml.

I guess I am saying that I forgive you no matter what direction you choose, because you won't be right no matter what you do. Well, except for allowing both like your documentation says you currently do. Since you allow both, I just renamed all of my XAML files to AXAML in hopes that Visual Studio won't muck with my work or what your providing us in tooling.

[grokys]

Going to close this as we did end up changing our file extension, at least for Visual Studio.