Jordan
Jordan

Reputation: 9911

Why does Visual Studio 2010 crash when I add a binding to a TextBlock?

When I change my code from:

<TextBlock x:Name="HeaderText" Style="{StaticResource HeaderTextStyle}" 
           Text="My Page Header"/>

to:

<TextBlock x:Name="HeaderText" Style="{StaticResource HeaderTextStyle}" 
           Text="{Binding Path=ModuleStrings.Package_Name, Source={StaticResource ResourceWrapper}}"/>

Every single time! If I change it outside of the IDE, it crashes when I load up the file.

Context:

I'm using Visual Studio 2010 and .Net 4.0. I'm writing a Silverlight application using the Silverlight Business Application template. I have several modules that I'm discovering using MEF and downloading dynamically. This code exists in a Silverlight RIA Services Class Library that I'm using as a module.

enter image description here

Edit:

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name: devenv.exe
  Application Version:  10.0.30319.1
  Application Timestamp:    4ba1fab3
  Fault Module Name:    unknown
  Fault Module Version: 0.0.0.0
  Fault Module Timestamp:   00000000
  Exception Code:   c00000fd
  Exception Offset: 0fd84cf0
  OS Version:   6.1.7600.2.0.0.256.1
  Locale ID:    1033

Additional information about the problem:
  LCID: 1033

Upvotes: 1

Views: 1278

Answers (1)

Seven
Seven

Reputation: 4425

In order to provide a preview of the UI the XAML editor actually executes the coding of your bound getter within VS2010. If your getter depends on other software components which are not correctly initialised because the application is not actually running, your getter will possibly throw an exception.

Normally VS2010 will show this exception together with its stack trace in a yellow header line above the UI designer. In many cases VS2010 seems not capable to cope with this exception, with the result that the whole IDE crashes.

My approach in these cases is to surround the whole coding of the getter (in your example ResourceWrapper.ModuleStrings.Package_Name) with try/catch and show an Exception through via MessageBox.Show(). So you will at least be able to see the original cause of the error after a rebuild. (There is also the possibility to debug VS itself with a second instance of the IDE...)

Then, when I located the error, in most cases it help to exclude some coding during design-time (i.e. when running in XAML editor and not as application)

// Detect if this coding is run by the IDE or within an actual application
bool inDesignMode = (bool) DesignerProperties.IsInDesignModeProperty.GetMetadata( typeof(DependencyObject) ).DefaultValue;

if(!inDesignMode)
{
    // ... We are running as application ...
}

HTH

Upvotes: 1

Related Questions