4

I'm looking for a general practice/approach of debugging XAML errors. Normally C# errors are fairly easy to look up and specific enough to find information on. However, XAML appears to just throw a generic XAML Parsing failed error:

enter image description here

I'm looking for a generalized way of approaching these errors and narrowing down what file, line number or any other information that may be useful to the errors being thrown.

James Mertz
  • 8,459
  • 11
  • 60
  • 87
  • The line and position are in the file where the error occurred. This should be whatever file you're editing typically. – N_A Oct 15 '12 at 20:14
  • @mydogisbox how do I determine what this file is from the error though? What if by chance I was working on multiple files, or a change was made into the repo that I didn't know about and happens to corrupt my current files? It would be nice to find out the specific file where the error is occurring. – James Mertz Oct 15 '12 at 21:02

3 Answers3

3

Here's a neat method I use to identify the file causing a XAML error when it's not clear...

Open up all the XAML files with resource dictionaries one by one, add a blank after the opening root element. Run in the debugger again up to the point of failure, when the line number increases by one you've found the file.

Nobody can justify this behaviour. I can only imagine the framework resource loading method is called with a stream so has no idea what the name of the file it is reading is, just the position within.

It needs to be improved. The part of the framework which calls the resource loading method should emit a debug message or pass the name in a context of some sort so the lower parts of the framework can emit sensible error messages.

Tony Wall
  • 1,382
  • 20
  • 18
1

Note: I plan on expanding this as I move along and learn more. If you would like to contribute to this answer, I will change this to CW and in the mean time feel free to make any changes you seem fit

Smaller changes == Smaller scoped errors

In general, just as @DenDelimarsky has stated, making small changes and running/debugging the code is a good start. That will, most of the time, narrow down the scope of the error to just the areas that you've been working in.

However here are a few other tips that you can use to narrow down the issues:

Search for the Class:

Your specific message for exception e states this:

Failed to assign to property 'Windows.UI.XAML.ResourceDictionary.Source' (emphasis added)

This means that the class ResourceDicionary is having complications assigning the property Source. Perform a search first within the scope of the files you've edited and then, if no errors are found, within the entire solution for this class and look for any errors that may be present.

Community
  • 1
  • 1
James Mertz
  • 8,459
  • 11
  • 60
  • 87
0

Actually, what you are seeing is a normal way to work with XAML errors. More than that, you are actually seeing a problem outside StandardStyles there. Besides, if you follow the regular debugging practices and debug often after modifying the XAML, it is usually fairly easy to narrow down the problem.

Den
  • 16,686
  • 4
  • 47
  • 87
  • 2
    This is actually a pull from my repo. Works on my computer at home, but my laptop isn't working correctly, but again, the idea to create a generalized practice of how to debug XAML specifically. – James Mertz Oct 15 '12 at 20:37