Blend has been getting more stable with frequent releases including SP1, Blend 2 etc but it still can’t render everything, even from an application that runs flawlessly at runtime. There are lots of things that can break the Blend renderer but tracking down exactly what broke your window/page/control can be difficult and time consuming. In some cases the location can be found by taking advantage of how Blend hosts applications. When Blend renders XAML it’s running the code just like at runtime and the code can be debugged in the same way. In cases where non-XAML Exceptions are breaking the renderer Visual Studio can attach to Blend itself and break to the exact location that’s causing the problem.
The primary reason errors occur in Blend that don’t show up at runtime is that Blend acts as a host for the application. This causes things that are evaluated relative to the running application like config files and certain types of relative resource references to look in the wrong place. The pack:application syntax in particular causes invalid references. The ResourceDictionary hierarchy is also different when running in Blend. In versions prior to Blend 2 Feb Beta App.xaml resources aren’t automatically resolved using StaticResource the way they are at compile time. Even the newest versions run into problems resolving references inside things like UserControls when rendered as part of a Window. XAML errors generally show up in the Blend errors window and can be linked to a specific line (with varying accuracy depending on the version) while errors deeper in code need Visual Studio debugging.
To debug an application inside Blend open the project in both Visual Studio and Blend at the same time. Before opening the broken component in Blend attach Visual Studio to the process with Debug->Attach To Process and select Blend.exe from the list. To make sure the Exception isn’t just swallowed by Blend set Visual Studio to break on all CLR Exceptions by selecting Thrown in the Debug->Exceptions for Common Language Runtime Exceptions.
Once you’ve tracked down an Exception in code you have a few choices. You can fix the error if it’s something that you determine shouldn’t be happening. If it’s due solely to the peculiarities of Blend and you want to leave the code as is, except when running in Blend, WPF provides a way to check whether Blend (or some other designer) is hosting the code. DesignerProperties.IsInDesignMode is set to True by Blend and can be accessed from anywhere in a WPF application with
Any code that breaks Blend can just be executed conditionally when this value is false.
One of the key advantages of using WPF is the promise of direct collaboration between designer and developer. Fixing Blend rendering errors will enable design and development of your application simultaneously without worrying about keeping application code and static designs from separate teams in sync.