Running User Code in the XAML Designer: Blend and VS 2012

The XAML designer in Blend & VS is a projection of a running application (see Mysteries of XDesProc–Revealed!), but unlike a full-fledged app, usage of certain programming constructs and resources might cause the designer to crash or behave in an unexpected manner. Note: This post and the examples shown are written in the context of the XAML Metro style app designer, but some of them apply to Windows Presentation Foundation (WPF), Silverlight, and Windows Phone designers as well. First, a quick overview of what code runs in the designer and what doesn’t.

• The code-behind of the instances of user controls and custom controls in the active XAML page are run in the designer.
• WINRT or CLR types that you declare in XAML as resources are instantiated in the designer process.
• Events dependent on CoreWindow and Input events will not be fired in the designer.

Keeping the above statements in mind, let’s review some things that might cause the designer to crash or behave unexpectedly.

Using [DependencyObject].Dispatcher

As the designer process is basically a WPF Application that hosts XAML runtime components, types like CoreWindow and CoreDispatcher are unavailable. CoreDispatcher is generally used to marshal an operation from a non-UI thread to the UI thread or schedule it for later execution on the UI thread. Since there is no CoreWindow in the designer process, CoreDispatcher objects in the designer will always evaluate to NULL. Hence, any user controls and custom controls that use this construct in their code-behind might not work correctly in the designer. When we detect that an instance of a user control or custom type cannot be created, we catch all resulting exceptions and wrap them in an error report linked to that specific instance, and continue creating the rest of the document.

 

Read the entire article here.