Debugger.Break() and Silverlight 2.0 projects
Posted by petermcg on May 13, 2008
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.
Sorry, the comment form is closed at this time.