Welcome to irritatedVowel.com Sign in | Help

POKE 53280,0: Pete Brown's Blog

Silverlight, WPF, Windows Client Development, Woodworking, .NET Programming, CNC, Nature, and other topics.

Subscribe

Subscribe to my feed
Add to Technorati Favorites

My Book

Order my upcoming book, Silverlight in Action, covering Silverlight 4, ViewModel/MVVM, WCF RIA Services, MEF and more

About Pete Brown

Pete Brown is a Microsoft Developer Division Community Program Manager, focusing on Windows Client Development as well as a former Microsoft Silverlight MVP and INETA Speaker. Pete writes on a number of topics including Silverlight, WPF, .NET, woodworking and working as a consultant in the DC area. read more

Community Events


who's online

AddThis Social Bookmark Button

Silverlight RC0 Debugging Tip – Check your VSM Styles

 

This tip is somewhat buried at the end of my RC0 introductory post. However, I can’t emphasis enough that the main reason you get initialization errors or the WSOD (White Screen of Death) in Silverlight 2 is problems in your visual states.

There are a few approaches and steps to debugging this.

  1. Open your project in Blend and look at the xaml files (start with app.xaml if that’s where most of your styles are located). Let Blend parse it and report errors. Fix what it finds and then run your app. Blend will catch many things Visual Studio will not.
  2. If that doesn’t remove the error, comment out the guts of your styles (not the outermost style tags) one by one, running each time. Yes, this is like how we used to have to debug undebuggable stuff like early ASP, but it is a tried and true approach. If you run after each time, you’ll be able to see which one was making your app bomb. Fix or recreate the offending style or get more granular with your commenting-out.
  3. If that doesn’t work, save a copy of your project and then remove all the “vsm:” prefixes from your styles. This isn’t step #1 because there may be cases where the “vsm:” prefix is required, and it will be next to impossible for you to find them after the fact. Just remember to back up the files before you do this. This problem usually manifests itself at design time

These are all artifacts of developing on beta software and then porting to a release. As an early adopter, this is not unexpected. Microsoft has given everyone a big old heads up by releasing the developer-only RC0, so I encourage you to use this time to get your apps ready for RTW.

If you run across any issues, please ping me here, or if you want a quicker response, post the questions on the forums over at silverlight.net

[Update: As I mention in the comments below, keep the vsm: in all the Visual* tags, and remove it from the other ones which are not vsm-specific. This makes perfect sense as the vsm: namespace prefix only needs to scope the items that are vsm-specific]

  Add to Technorati Favorites
Posted: Friday, September 26, 2008 2:16 PM by Pete.Brown
Filed under: ,

Comments

Community Blogs said:

Jeff Handley on Layout Cycle and ContentPresenter gotchas, Pete Brown on VSM Styles and SL2 RTM, Bill
# September 26, 2008 7:23 PM

Pete.Brown said:

Ok, latest recommendation (and this makes sense) is to remove the vsm: prefix from all style and setter tags, but keep it for all VisualState* tags (like VisualStateManager and VisualStateGroup), as those are actually in the vsm namespace.

Pete

# September 27, 2008 12:14 AM

Young Oh said:

Many thank Pete !!! After(not before unfortunately) wasting so many hours, I came to your advice and applied it. Bingo. It worked. Then I reconstructed the error to see where the error exactly was. As you said, vsm:Visual....were all ok. Also vsm:Style and vsm:Setter were ok as well. But was causing the problem with the following error message in my case. title: "XamlParseException occured" AG_E_PARSER_PROPERTY_NOT_FOUND [Line:99 Position:99]. So changing to fixed the problem. Again thanks a lot.
# September 28, 2008 3:18 PM

Vladimir said:

Pete thanks a lot!!! Many hours saved :) "remove the vsm: prefix from all style and setter tags" works very mice.
# September 29, 2008 12:27 AM

Community Blogs said:

By now, you probably heard that Silverlight 2 RC0 is out and available for download . While you’ll
# September 29, 2008 10:56 AM

Eric Willeke said:

#2 did it for me. Specifically, I removed the vsm: from from the Style and Setter tags, which cleaned up something very nicely. Oddly enough, #1 gave me a false negative, where it was telling me I couldn't put a Grid as the child of a Border. Oh well, never can tell ;)
# September 29, 2008 3:06 PM

Eric Willeke said:

Argh - reread before I post! Sorry for the spam, but it was #3 that did it, not #2
# September 29, 2008 3:07 PM

Eric Willeke said:

I'm not seeing this in the breaking changes list, but it seems the runtime is being much more aggressive in how it enforces duplicate x:Name usage. Before, it was essentially on a per-UserControl basis, as I could have (for example) an x:Name="CloseButton" in my root page, and other one in a user control that was loaded from that page. Now, it gives me "The name already exists in the tree: CloseButton"
# September 29, 2008 3:21 PM

Pete.Brown said:

@Eric, I'm running into problems with that in usercontrols too. It may be a bug.

Pete

# September 29, 2008 3:28 PM

Eric Willeke said:

I've not dug into it yet, but I've also seen an issue with changes to Layout and/or Measure throwing exceptions where they weren't before. It doesn't appear to be the infinite loop exception that is mentioned, but it could be related. Don't suppose anybody's seen a PagingStackPanel out there?
# October 1, 2008 9:24 AM

POKE 53280,0: Pete Brown's Blog said:

This is the second birth I’ve been privileged to witness this month, and if I made any more comparison
# October 13, 2008 1:46 PM
Leave a Comment

(required) 

(required) 

(optional)

(required) 

Enter the text you see in the image:

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS