Troubleshooting Silverlight Designer Load Failures
Microsoft Silverlight will reach end of support after October 2021. Learn more.
The Silverlight Designer for Visual Studio includes a sophisticated and extensible visual designer that renders XAML. If your XAML file does not load in the designer, there are several things that you can do to try to understand what is going wrong. This topic describes some tips and techniques to help you troubleshoot these load failures.
.gif "Note") Note: |
|---|
Many of the techniques in this topic also apply to Expression Blend. |
Debugging a Load Failure
Use the Visual Studio debugger to step into your code at design time. You can use a second instance of Visual Studio to debug load failures. For more information, see How to: Debug a Designer Load Failure.
Troubleshooting Steps
The following steps can help you troubleshoot the Silverlight Designer load failures.
Read any exception messages you receive.
This may seem obvious, but if you get an exception, clearly read the message. In some cases, it can help you quickly diagnose the problem. For more information, see Error Message Reference for the WPF Designer and Error Handling.
Determine if the problem is in your implementation.
Build and run your application to determine whether the problem is the result of your implementation only, or an interaction with the Silverlight Designer. If the application builds and runs, the design-time error is likely caused by your implementation.
Determine if the problem is a loading error.
If Design view fails to load because of an exception, the problem is likely a loading error. If you have custom code that is loaded at design time, and you experience exceptions or load failures at design time, see the Writing Code for Design Time section in this topic.
Review your code that is loaded at design time.
There are two approaches to writing code that also runs at design time. The first approach is to write defensive code by checking the input parameters to classes. The second approach is to check whether design mode is active by calling the GetIsInDesignMode method. For more information, see the Writing Code for Design Time section in this topic.
Review other areas of your code. Make sure you have followed best practices in the remainder of your code.
If you are adapting your code from a WPF application, review differences between Silverlight and WPF. For more information, see XAML Processing Differences Between Silverlight Versions and WPF and WPF Compatibility.
If you still have problems, you can use the WPF Designer forum on MSDN to connect with other developers who are using the designer to create Silverlight applications. To report potential issues or provide suggestions, use the Visual Studio and .NET Framework Feedback site.
Writing Code for Design Time
Ensure that your code runs at design time, as well as run time. If your code runs at design time, do not assume that Application.Current is your application. For example, when you are using Expression Blend, Current is Expression Blend. Typical operations that cause a custom control to fail at design time include the following.
Casting Current to your custom subclass of Application.
Not checking whether Application.Current has returned a value that is null. If Visual Studio does not create an application object, then Application.Current may return null.
There are two approaches to writing code for design time. The first approach is to write defensive code by checking the input parameters to classes, such as value converters. The second approach is to check whether design mode is active by checking the IsInDesignTool property.
Checking input parameters for some implementations is necessary because the design environment provides different types for some inputs than those provided by the runtime environment.
Style selectors and value converters usually require one of these approaches to run correctly at design time.
Value Converters
Your custom IValueConverter implementations should check for null and for the expected type in the first parameter of the Convert method. The following XAML shows a binding to Application.Current that fails at design time if the value converter is not implemented correctly.
<ComboBox.IsEnabled>
<Binding Converter="{StaticResource specialFeaturesConverter}">
<Binding Path="CurrentUser.Rating" Source="{x:Static Application.Current}"/>
</Binding>
</ComboBox.IsEnabled>
The binding raises an exception at design time because Application.Current refers to the designer application instead of your application. To prevent the exception, the value converter must check its input parameters or check for design mode.
The following code example shows how to check input parameters in a value converter that returns true if two input parameters satisfy particular business logic.
public object Convert(object[] values, Type targetType, object parameter, System.Globalization.CultureInfo culture)
{
// Check the values array for correct parameters.
// Designers may send null or unexpected values.
if (values == null || values.Length < 1) return false;
if (!(values[0] is int)) return false;
int rating = (int)values[0];
// If the user has a good rating (10+) special features are
// available.
if (rating >= 10)
return true;
return false;
}
The second approach to writing code for design time is to check whether design mode is active. The following code example shows a design-mode check instead of the parameter check shown previously.
public object Convert(object[] values, Type targetType, object parameter, System.Globalization.CultureInfo culture)
{
// Check for design mode.
if ((bool)(DesignerProperties.IsInDesignModeProperty.GetMetadata(typeof(DependencyObject)).DefaultValue))
{
return false;
}
int rating = (int)values[0];
// If the user has a good rating (10+) special features are
// available.
if(rating >= 10)
return true;
return false;
}