WinUI3 XAML error messages are even worse than the vague UWP ones

[mrlacey]

Describe the bug

WinUI3 doesn't provide design or build time indication of invalid XAML. At run-time it just gives the unhelpful "XAML parsing failed." message.

Steps to reproduce the bug

Steps to reproduce the behavior:

1. Create a new blank WinUI3 app (UWP or Desktop)
2. Add this XAML to MainPage/MainWIndow

     <Pivot>
        <TextBlock />
    </Pivot>

3. Run the app
4. See the crash (unhandled exception)

Expected behavior

There should be build and design time indication when the entered XAML is invalid.

The only valid children of a Pivot control are PivotItems. The following is the nearest valid equivalent to the above.

    <Pivot>
        <PivotItem>
            <TextBlock />
        </PivotItem>
    </Pivot>

In a UWP (WinUI2) app, with the above repro, there is a designer warning that something is wrong, but the error message is not specific about the cause. There is also no build error and attempting to run the app will lead to a runtime error.

Code	Description
XDG0062	Failed to add TextBlock to ItemCollection. Element is already the child of another element.

While this may be a technically valid explanation of what the XAML parser is doing internally to try and build an object graph from the XAML string, it is misleading and could be improved in several ways.

A better experience will include:

• The designer indicates that the specified XAML is incorrect by underlining the invalid text and having an error list entry with a meaningful description.
• Invalid XAML prevents the build from completing successfully.
• An error description that includes specific details that help address the issue. For example: "It is not possible to directly add a TextBlock to a Pivot."

Making these changes will:

• Help developers find and fixes issues more quickly.
• Make debugging easier.
• Improve satisfaction and remove frustration with the tooling.

Screenshots

Version Info

NuGet package version: Microsoft.WinUI 3.0.0-preview4.210210.4

Windows app type:

UWP	Win32
Yes	Yes

Windows 10 version	Saw the problem?
Insider Build (21296.1010)	Yes
October 2020 Update (19042)
May 2020 Update (19041)
November 2019 Update (18363)
May 2019 Update (18362)
October 2018 Update (17763)
April 2018 Update (17134)
Fall Creators Update (16299)
Creators Update (15063)

Device form factor	Saw the problem?
Desktop	Yes
Xbox
Surface Hub
IoT

Additional context

[StephenLPeters]

@fabiant3 and @RealTommyKlein FYI

[sigmarsson]

#3625

[billhenn]

I ran into #3625 myself just now and luckily found that issue via Google. Otherwise I would have had no idea what was wrong.

Debugging anything in UWP XAML was always an awful experience due to lack of information on problems compared to what you got in good old WPF XAML. Please make sure that WinUI XAML error messages are at least as detailed and specific as what you find in WPF. It's critical if you want developers to adopt a platform.

[WINMAN174]

I second that motion. I'm converting a large WPF app to WINUI. With the designer not working as well I'm spending every waking hour of the day compiling, running and building to see what horror I will find next.

I'm watching "Planet of the Apes" right now to give me some perspective. At this point riding off on a horse with Nova into the forbidden zone seems like a good idea.

[markolbert]

There ought to be rule at Microsoft -- punishable by being publicly mocked at weekly staff meetings -- for developers who think reporting "something went wrong!" is a reasonable error message :).

What I find fascinating about this issue is it's pervasive within Microsoft. It's not just XAML parsing. It's everywhere. I don't know if it's right hand not telling left hand what's going on, or just not caring about anything that doesn't keep someone from being able to tell their boss, "Yep, got that implemented, with error reporting!"...even though the error reporting is, in practice, useless.

It'd be fascinating to see an estimate of how many developer hours have been wasted by people using Microsoft tools on just this issue alone. I bet it's in the millions.

[ttustonic]

And, obviously, this is not important enough to fix, after more than a year. Wasted hours keep piling up, projects become more expensive than they should be, frustration rises... but, who cares. Microsoft certainly doesn't.

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[mrlacey]

There are other issues (some linked) that have been closed with the note that this issue is still open, so the issue is "on your radar".

Please don't close this.

I understand that you're closing inactive issues so that your work is easier (by having fewer issues to manage), but you'll make the lives of the developers trying to use the SDK easier if you can give them useful messages when something goes wrong or isn't used in the way that it's intended.

[ivanlabsii]

@mrlacey , I agree in general, but as I think that this is unlikely to be fixed I think it is more honest to be closed. So that no one can hope that it will get better. That will make it easier for devs that consider whether to give up on WinUI 3 or not.

[mikernet]

+1

Debugging anything in WinUI is a frustrating nightmare. I have spent 2 hours trying to figure out why I can't template a radio button without getting some generic HRESULT error.

The result when it's working is pretty but dear lord, the process can be frustrating as hell.

[garrettpauls]

IMO this is the single most important issue to address in regards to long-term adoption. I've worked around many, many bugs in the framework and I can live with that. The horrible error messages (and overall poor development experience) is what drove me to never use WinUI for a personal project, and only suffer through it at work when I have to.

I don't want to despise this product, I really don't, but that this has seen no noticeable improvement in over two and a half years and I still get "XAML parsing failed" errors regularly with no means of debugging short of commenting out all the changes and step by step adding things back until it blows up again, does not leave me feeling optimistic for the future of this technology.

[garrettpauls]

It is inexcusable to throw an exception that has a message "Unspecified error" and no stack trace. I did not realize .NET could have exceptions with a null stack trace, but WinUI surprises me again.

Unfortunately it's not as funny as it could be, because every time one of these errors crops up I end up wasting time trying to track down what caused it, before inevitably reverting my current changes and re-implementing them in a different way. I dread the day one of these crops up in production code instead of active development and we have to figure out why.

It is immensely frustrating to work with a technology stack that gives you no help whatsoever in troubleshooting many of its errors. At this point I don't expect this situation to improve, but for anyone searching "Unspecified error" and finding this: you are not alone, it's not just you this happens to. Good luck.

[kmgallahan]

I did not realize .NET could have exceptions with a null stack trace

WinUI/WASDK wasn't built with .NET. It is a C++ framework that allows you to interop with it using C# if so desired.

[garrettpauls]

WinUI/WASDK wasn't built with .NET. It is a C++ framework that allows you to interop with it using C# if so desired.

I realize that, however that still doesn't explain a .NET exception without a stack trace. At minimum I would expect an error generated by native code and thrown as a .NET error would contain a stack trace starting at the point in the .NET code where it interops into native code. That would at least give me some idea of what the problem is or where it's coming from. But I'll grant that may be a deficiency with .NET itself as opposed to WinUI.

[kmgallahan]

There are 3 things that can help:

• Enable mixed-mode debugging to see native exceptions when they occur, although this will unleash a torrent of vexing exceptions
• Add a handler for Application.UnhandledException
• Wrap all InitializeComponent() calls in a try/catch block:

try {
    InitializeComponent();
}
catch (XamlParseException parseException) {
    Log.Fatal(parseException, "Unhandled XamlParseException in SettingsPage: {ExceptionMessage}", parseException.Message);
    foreach (var key in parseException.Data.Keys) {
        Log.Fatal("{Key}:{Value}", key.ToString(), parseException.Data[key]?.ToString());
    }
    throw;
}

[garrettpauls]

Honestly, I'll take anything I can get at this point, so I'll try mixed-mode debugging next time one of these crops up.

We already have an UnhandledException handler which is where we see some of these bubbling up to, but unfortunately the lack of both useful error message and sometimes stack trace makes it pretty useless. Perhaps logging more information about the sender itself may be helpful though if we can at least get the sending object's type (provided there is one), so I'll shore that up a bit.

Wrapping all InitializeComponent calls feels a bit heavy handed, but next time this happens I may look into it as an option.

I appreciate the suggestions!