Debugging Silverlight XAML

Microsoft Silverlight will reach end of support after October 2021. Learn more.

Because XAML is a markup language, some of the typical strategies for debugging within Visual Studio are not available. For example, there is no way to set a breakpoint within a XAML file. This topic describes how XAML works in the Silverlight architecture while in a debugging context, and provides some strategies for eliminating problems in Silverlight XAML during the design and development phase.

XAML Parse Exceptions

When there are problems with a XAML file, the most typical result is that your application will raise a XAML parse exception. Whenever there is a XAML parse exception, the XAML loaded by the XAML parser failed to create a valid object tree. In many cases, such as when the XAML represents the first "page" of your application that is loaded as the RootVisual, the XAML parse exception is not recoverable. This results in your application being shut down by the Silverlight run-time, and in fact, the run-time itself will shut down.

If you get a XAML parse exception during the development phase of your application, pay close attention to the line number information that is conveyed by the LineNumber property of the exception. That line number should correspond to the line of source XAML that has a problem. You can then use the XAML editor in Visual Studio (or any other text editor that you use to edit XAML) to go to that line in the XAML source.

XAML at Design Time

XAML is often edited within an integrated development environment, notably either in Visual Studio or in Microsoft Expression Blend. In order to provide assistance, such environments often provide design-time validation and error checking of a XAML source as you edit it. For example, consider the following invalid XAML:

<UserControl x:Class="SilverlightApplication1.MainPage"
    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
>
    <Grid x:Name="LayoutRoot" Background="White">
        <Application/>
    </Grid>
</UserControl>

This XAML is invalid for Silverlight because Application is not a UIElement, and thus cannot be a child element of Grid. If you attempted to load this XAML at run time, a run-time XAML parser exception would be thrown. To provide assistance at design time, Visual Studio does two things at design time if this XAML is loaded in the XAML text editing surface:

• The <Application/> tag appears with a blue underline as soon as it is introduced. If you hover over that element, a tooltip displays more information about the specific error. This is an example of how Visual Studio is capable of examining the XAML schema context for Silverlight at design time, doing a preliminary type-mapping with reference assemblies, and using that information to identify invalid XAML before it is ever compiled or loaded by a project or application. Every time you make a change to XAML in the text editor that results in a design-time reload, the XAML is reparsed to check for new errors, or to verify that previous errors were fixed.

• If you ignore the design surface tooltips and attempt to build the application that references this XAML, you get a build error that appears in the Error List window. The build error will report the very same error that was indicated by the tooltip. However, if you look at the Output window, the application builds successfully. This is because Visual Studio is accurately reporting the role of XAML in the Silverlight application model; for this type of error, the XAML is not truly in error until the Silverlight run-time attempts to load it.

There are also XAML errors that will result in a failed build. This will happen if the XAML error results in a compile-time CLR error through some dependency. For example, the build will fail if you reference an object from markup and no backing type for the object exists, or if you map a nonexistent assembly. The build will also fail if the XAML markup-compile build action fails. This might happen if your x:Class classname and code partial class name do not match, XAML and code have non-matching access levels, or similar problems. For more information on the role of the markup compile step in the Silverlight programming model, see Code-Behind and Partial Classes.

Resource Reference Debugging

Static resource references are evaluated at XAML load time. The order in which individual XAML components are loaded is important. One common failure of resource lookup is making a forward reference: where the StaticResource reference to a key is made prior to the item definition of an item with that x:Key value. At design time, Visual Studio can show highlighting and place warnings in the error list for cases where a StaticResource reference does not resolve to an existing key in any resource dictionary. Visual Studio also accounts for application-level resources, so that references from a page to an application resource do not produce false warnings.

Note:
Resource reference lookup failures are warnings rather than errors because there are techniques available for populating a resource dictionary just prior to loading XAML. However, such techniques are not commonly used.