Hello!
I'm wondering if there's any way to get the XAML file and relevant line to show when printing error messages, to make the errors easier to debug. For example with an error message such as this: It can be quite difficult to know where to look. We can easily get the line in C++ code base where it is printed from with a macro, but since the error is probably in XAML, it would be much more useful to know where in XAML the error is caused. With the current information the error message is giving, the error could be caused just about anywhere.
Is there any way to print such info, or something similar? I realize that this is not trivial since it might involve a lot of metadata, but it would be immensely useful so I thought I'd ask at least.

In Noesis 3.1, errors from XAML follow this pattern: path/filename.xaml (line): message
In Noesis 3.2, errors from XAML follow this pattern: path/filename.xaml (line,col): message

Noesis 3.2 also added a new error handler (ErrorHandler2) with information about the line and number (without having to parse any string) that can be set using SetThreadErrorHandler

Interesting, we're currently on version 3.1.4. Perhaps there's something we haven't set up correctly, given that our Noesis error messages print in the format I pasted above (with no information about XAML file). We have a log handler set via Noesis::SetLogHandler.

If you are not getting XAML and line information it is because the error is not happening when parsing the XAML. For example, in your case, bindings are applied after parsing (there is a ticket to improve this #2222). WPF is doing exactly the same in this case, but we could provide a better solution.

Also many improvements were implemented in our VSCode extension (this is using 3.2 too) for better error information.

Ah yep, that makes sense then! Indeed, having that information for bindings would be amazing. I get that WPF also doesn't solve this, but any improvements you could find for this would be very appreciated. Nice to hear that there's a ticket for it already. :)

Haven't tried the VSCode extension yet, only been using Blend for that so far. Guess that's also something to look into after we update to 3.2.