Silverlight 2.0 Unhandled Exceptions

It can be difficult to debug exceptions in a Silverlight applications in Visual Studio 2008 in certain scenarios at present.  If you’re having trouble tracking down where an exception is occurring in your Silverlight application and find it awkward dealing with the yellow exclamation :

Don’t forget you’ve got the Application events to help you out.  An event handler for the UnhandledException event of the Application class is wired up by default for new Silverlight Applications.  If you set a breakpoint here you can get a call stack back to where the problem is occurring :

Debugger.Break() and Silverlight 2.0 projects

I ran into a minor problem recently where Visual Studio 2008 was closing unexpectedly with the message that it had encountered a user-defined breakpoint.

I believe the problem occurred when the Silverlight 2.0 XAML parser encountered some XAML for a custom control and hit a System.Diagnostics.Debugger.Break() statement in the handler for a dependency property’s PropertyChangedCallback.  This dependency property was part of a custom control which I had referenced and declared in Page.xaml in my main Silverlight Application project.

The steps to recreate the problem include having Page.xaml open in Split View or Designer view (XAML view does cause the error but only intermittently it seems) and finally performing a build; whereupon you receive the message :

The next step is either that Visual Studio restarts itself only to encounter the same error when it starts again, this can happen several times until you get the message…

…or, that you get the following error :

In which case after you click Close Program, Visual Studio’s UI is grayed out while an error reporting .exe does it’s work, sometimes necessitating user action to kill the process using task manager.

Note that the reason for posting this issue and previous issues on my blog is purely to provide feedback, as Silverlight 2.0 is still in Beta 1 problems are to be expected.

Currently, the debugger does not suspend execution at present even if you do successfully start debugging a Silverlight solution containing this statement.  Surrounding the statement with a conditional directive also does not solve the problem so to avoid this issue simply avoid using the System.Diagnostics.Debugger.Break() statement, and use breakpoints instead for now in Silverlight 2.0 projects.