The biggest frustration in my Silverlight development is debugging errors in my XAML code.  Since our app uses Prism, there are often three different .xaml files involved in any one change to the app: App.xaml for global styles, Shell.xaml for the main layout and a .xaml file for whatever view I’m working on.  If something goes wrong, knowing what file it’s in is half the battle.

Unfortunately, the errors that Silverlight throws when you have malformed XAML can be pretty obtuse.  Through trial, error and a little intuition I’ve figured out that there are some patterns:

• If nothing at all renders, the problem is likely in App.xaml.  That gets loaded first, and if something goes wrong then you get bupkus.  Check for syntax errors in App.xaml.
• If the only thing that renders is the spinny loady thing (I actually don’t know if this is a Silverlight default or a StockTraderRI thing) then I think that usually means the problem is in Shell.xaml.  App.xaml has loaded at this point, but something is keeping the rest of it from going.  Often this can happen if you’re referencing something in App.xaml that’s syntactically valid but semantically nonsense.  Check especially for mis-spelled values inside Setter tags, or badly structured ContentTemplates.
• If the full page loads except for one piece, then the problem is probably in the view that supplies the markup for that piece.  Check both for syntax errors in whatever .xaml document didn’t render, or for errors in the styles it references in App.xaml.
• Another problem I ran into recently happened when I refactored my shell.xaml to inject a view into a different part of the page, and then deleted the Grid that it used to inject into.  Unbeknownst to me, there was a Storyboard on the page that referred to the Grid by name, and deleting the Grid caused different parts of the page to stop rendering in interesting ways.  Whenever you delete a named control, do a quick search to see if there’s anything that references it.

Sometimes Visual Studio gives warnings when I’m about to try to run some bad XAML code, but just as often it compiles and attempts to execute, with the results you see above.