Locating binding errors

Question

I'm dealing with a large WPF application that is outputting a large number of binding errors. A typical error looks like this:

System.Windows.Data Error: 4 : Cannot find source for binding with reference 'RelativeSource FindAncestor, AncestorType='System.Windows.Controls.ItemsControl', AncestorLevel='1''. BindingExpression:Path=HorizontalContentAlignment; DataItem=null; target element is 'MenuItem' (Name=''); target property is 'HorizontalContentAlignment' (type 'HorizontalAlignment')

Problem is I don't know where in the app this is coming from. Searching the entire solution for AncestorType={x:Type ItemsControl} doesn't necessary help since I still don't know which result is the culprit. I've tried setting PresentationTraceSources.DataBindingSource.Switch.Level = SourceLevels.All; but the extra information doesn't help locate the problematic bindings. File names and line numbers is really what I need. Is there anyway to get this information? The only other solution I can think of is to assign names to the canidates then narrow it down from there. In that vein, is there a way to automatically assign a unique x:Name to all namable elements throughout the solution?

Answer 1

When do you see these binding errors? Only during startup (or loading of a new AddIn, or new View, etc.).

In those cases, I've found that these errors are often "false positives," in that they are thrown before the object being bound to is initialized. It's annoying, for sure, but if everything in your application seems to be bound correctly (here, for instance, your menus seem to have a proper HorizontalContentAlignment), then I wouldn't worry too much.

Answer 2

I generally set a breakpoint on the code that actually writes the error message. When the breakpoint is hit I inspect the visual tree of the object that had the binding error using a Visual Studio visualizer. This almost always tells me exactly where in my code to find the binding and fix it. (You can figure out where to set the breakpoint by installing a custom trace listener and breaking in it, then checking out the call stack.)

I also design my application to minimize the number of "false positives" by making sure bindings will always be valid when the source is present at all.