WPF vs. Silverlight - Part 10 - XAML Parser Differences

See intro blogpost here.

The XAML parser for WPF and Silverlight are not one and the same, and this also means that there (for whatever reason) are differences in how they interpret the xaml (as kinda hinted at in part 7).

MSDN has a pretty good description on those differences, so I won’t repeat the entire thing (please go read it!), other than point to a couple of important items:

  • Silverlight 4 introduces a XAML parser that behaves differently than Silverlight version 3 and is closer to the WPF XAML parser implementation.  Silverlight includes a XAML parser that is part of the Silverlight core install. Silverlight uses different XAML parsers depending on whether your application targets Silverlight 3 or Silverlight 4. The two parsers exist side-by-side in Silverlight 4 for compatibility. (read: You are more likely to hit issues porting an SL3 app to WPF than from SL4)
  • In some cases, the XAML parsing behavior in Silverlight differs from the parsing behavior in Windows Presentation Foundation (WPF). WPF has its own XAML parser (read: We made a new XAML parser for Silverlight, and cut some corners...)
  • Object elements inside a ResourceDictionary in Silverlight may have an x:Name instead of or in addition to an x:Key. If x:Key is not specified, the x:Name is used as the key. (read: Always use x:Key since this works in both)

Most of the other differences are things supported only in WPF, which is to be expected since Silverlight is a subset. Again this is why I recommend starting with Silverlight and then porting to WPF.

Other things worth noting:

WPF v3.5 does not have a VisualStateManager. Silverlight “invented” this and WPF 4 added it. If you build for WPF 3.5, you can use the WPFToolkit, which adds this support to 3.5.

Compiler conditionals in XAML

As demonstrated in many of the previous parts, you can use compiler conditionals in code-behind (ie. #if SILVERLIGHT...) to write code specific to the platform. Unfortunately you don’t have that luxury in XAML. If you need to have different xaml for the different platforms, I haven’t found a way around duplicating the entire piece of XAML in each project. So no, this won’t work Sad smile :


Next: WPF vs. Silverlight - Part 11 - Silverlight on Phone vs. Browser

Comments (4) -

  • Thanks for the suggestion on mc:Choice. I hadn't seen that before, and it's pretty awesome. Unfortunately it's only supported in WPF, so it doesn't really help in this scenario.
  • Why are Silverlight and WPF so different in the first place? I understand that SL runs in the sandbox with a tiny runtime so I would expect SL to be a subset of WPF. OK, the parsers are different so there are some corner cases. But for example you other post "WPF vs. Silverlight - Part 5 - XAML Control Instantiation" - where does that difference come from? If I understand correctly SL was started after WPF beta was nearly completed, does it means that SL makes some things better then WPF?

  • Mikhail: I'm not sure but my theory is that this simply happened because of two things: 1. Simplify the runtime to make it a smaller download, and 2. They screwed up a little Smile
    AFAIK Silverlight and WPF doesn't share the same code-base, so they had to re-do WPF from scratch, and probably missed some things here and there.

Pingbacks and trackbacks (2)+

Add comment