.NET & Funky Fresh

Syndication

News

  • <script type="text/javascript" src="http://ws.amazon.com/widgets/q?ServiceVersion=20070822&amp;MarketPlace=US&amp;ID=V20070822/US/bluspiconinc-20/8001/8b68bf4b-6724-40e7-99a5-a6decf6d8648"> </script>
Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Silverlight Problems That Affect Me

I've blogged previously about inconsistencies between SL 2 Beta 1 and WPF.  In my previous post I mentioned a few critical things that I felt would make it hard for WPF developers to move code between the two platforms.  Most of my complaints were not addressed in the updated Beta 2 of Silverlight, but I didn't expect them to be.  Some issues were just too complicated to try and fix that quickly.

The purpose of this post is to mention a few more things I have found.  This list of "issues" comes directly as a result of my work in creating a common code base for Caliburn, for both the WPF and Silverlight platforms.  While many of these issues will be felt more painfully by developers trying to migrate their skills from WPF to Silverlight, most of them will also affect developers with no previous experience in this area.  Some of these problems are obscure.  In those cases, I will try and give some explanation of why it is important and how if affects the bigger picture of developing RIA's with Silverlight.

  • DepencencyObject, UIElement, and FrameworkElement all have internal constructors.

For some reason (probably due to Silverlight's unmanaged goop) none of these fundamental base classes can be extended through inheritance.  They all have internal constructors.  The problem with this is, often times a developer has a need for a simple object with dependency properties.  In WPF I would just inherit from DependencyObject but in Silverlight the lowest level base class I can inherit from is Control.  But, I don't want a control!  This limitation also means that it's impossible to create lightweight UI components.

  • No Visual base class.
  • No Freezable base class.

These base classes are not directly worked with by WPF developers most of the time.  But, their affects are felt nearly all the timeVisual, for example, is the base class that represents all renderable elements in WPF.  This plays an important role in everything.  They've gotten around this in Silverlight mostly by merging its functionality into other base classes.  Two areas related to Visual that represent functionality missing from Silverlight are printing and rendering to bitmap.  Freezable is an interesting class because it allows non-FrameworkElements to hook into the logical tree.  Thus things like transforms and brushes can be databound in WPF, but not in Silverlight.  The absence of Freezable and to a greater degree the absence of a logical tree has the most limiting and far reaching negative affect on Silverlight.  This is also the source of Silverlight's stunted databinding features, including the lack of ElementName binding.

  • IsEnabled does not exist on UIElement.

This feature alone is enough to make it very difficult to build any real world business application with Silverlight.  Of course there are workarounds, but that would be painful.  The issue is that you cannot disable any part of the UI in Silverlight like you can in WPF.  With WPF, all UIElement descendants can be disabled; this includes panels, text boxes, buttons, etc.  With Silverlight the property exists only on certain classes (ContentControl, Slider and Thumb of all things).  This means I cannot disable things like TextBox and ListBox and I cannot disable an entire panel of controls.

  • FrameworkElement is missing the IsInitialized property.
  • FrameworkElement does not have an IsLoaded property.
  • FrameworkElement is missing the Unloaded event.

The absence of these properties is not that big of a deal to me.  But, I'm used to them being there, and taking that for granted I was robbed of several possible "simple" solutions to some of the problems I was trying to solve.  Of most importance is the Unloaded event.  In combination with Loaded it enables developers to write specific code that responds to the addition and removal of an element from the visual tree.

  • No Selector base class.

By itself this isn't major.  Indeed, at present, there aren't many things in Silverlight that could derive from Selector.  Mainly ListBox, but if they ever add a ComboBox (I can't believe this control is missing...) it should derive as well.  The overarching theme here is that the entire class hierarchy greatly differs between WPF and Silverlight.  No Visual, Freezable, or Selector.  Base classes can't be inherited (due to internal constructors) and important properties are missing.  As long as you stick to simple applications, this is fine.  But the minute you try some form of generic programming, often necessary in real applications....BOOM!

  • Exception (and its derivatives) have non-visible serialization constructors.

Again, not a major deal.  Just know that if you are used to providing serialization constructors for custom exceptions, you won't be able to in Silverlight.  The serialization constructor of the base class is internal and there is no binary serialization in Silverlight either (which is perhaps the bigger issue).

  • DependencyProperty does not allow a way to declare metadata for a property.

Normally in WPF you can declare more information about a dependency property, but Silverlight does not allow this.  Some examples are the default binding mode and whether or not a property affects layout or rendering.  I'm guessing that somewhere under the covers Silverlight is making some serious assumptions.

  • There is no LogicalTreeHelper and more importantly, no logical tree.
  • No name scopes.

Though many WPF developers may not deal directly with these two pieces.  Their presence governs so much of the way that WPF behaves at runtime.  Not having these seemingly fundamental pieces has caused copious hair pulling and screaming.  This is also related to the absence of Freezable.  (Frankly, I'm still not sure how Silverlight works at all without these pieces.)

  • No custom markup extensions.

Annoying!  I always use custom extensions and it is exceedingly important if you want to build any type of framework on top of Silverlight that eases common tasks.  Why are the existing markup extensions hard coded?

  • Some of the assembly names are different between .NET and Silverlight.

This is not a big deal, and I attribute it more to WPF's poor assembly naming convention, because Silverlight actually does it more the ".NET way."  You'll need to know about this if you do multi-targeting though.

  • There are differences in the runtime behavior of the dynamic method API.

Again, not a big deal.  But, it's confusing when there are public methods that you can call that will always throw an exception at runtime.  Pay attention to the words SECURITY CRITICAL in the intellisense.  If you see this, don't bother.

  • You cannot represent a class in Silverlight Xaml with a Name property.

Weird.  Ok, to see what I'm talking about, follow these steps:

1.  Create a new Silverlight project.

2.  Add the following class definition to the project:

 

3.  Change the markup for Page.xaml to match the following (make sure the namespaces match your project):

 

4.  Make sure you add the event handler for the button to the code behind.

5.  Set a break point in the click handler.

6.  Run the application and click the button.  Using the debugger, drill into the Content property of the Button and examine the Name property.  You'll  see that the Name property is null even though you set it.

  • Binding is severely lacking.

Let's just face it.  Silverlight data binding shouldn't even be compared to WPF databinding.  Silverlight's version is so stunted that it's embarrassing.  There's no element name binding, for starters.  This is one of the most important features in WPF data binding.

In conclusion, I'd like to reiterate that I actually like Silverlight.  It has a lot of potential.  I just wish more attention would be given to the foundations.  If you get the core right, I can do anything.  Otherwise I'm limited to what Microsoft can imagine in their highly rushed dev cycle.


Posted 07-26-2008 6:58 PM by Rob Eisenberg

[Advertisement]

Comments

Silverlight Problems That Affect Me - .NET & Funky Fresh wrote Silverlight Problems That Affect Me - .NET &amp; Funky Fresh
on 07-26-2008 8:27 PM

Pingback from  Silverlight Problems That Affect Me - .NET &amp; Funky Fresh

samcov wrote re: Silverlight Problems That Affect Me
on 07-26-2008 9:38 PM
You said, In conclusion, I'd like to reiterate that I actually like Silverlight. It has a lot of potential. I just wish more attention would be given to the foundations. If you get the core right, I can do anything. Otherwise I'm limited to what Microsoft can imagine in their highly rushed dev cycle. There it is, the best summation I've seen on this problem. Te only thing that bothers me more is the lack of any dates for releases we can depend on. I understand the sticky situation they're in, but we also have to answer to management and customers as well. It's hard to plan a rollout when there isn't ONE date you can say is good and hard set.
John &quot;Z-Bo&quot; Zabroski wrote re: Silverlight Problems That Affect Me
on 07-27-2008 12:31 AM
I mentioned your post in a thread on the Silverlight forums http://silverlight.net/forums/t/12220.aspx
John "Z-Bo" Zabroski wrote re: Silverlight Problems That Affect Me
on 07-27-2008 12:44 AM

@samcov

My opinion on Silverlight 2's beta cycle is summed as, "The Olympics are a huge problem for Micro-ISVs."  It took me a month after Beta 2 was released to really be able to assess all the changes and re-analyze the direction of Silverlight 2.  I shouldn't have to do this.  Microsoft DevDiv should tell me.

What is frustrating is that I keep getting stonewalled when I ask questions.  I know it is nothing personal, and that the problem is that the Olympics are two weeks away.  Still, it is frustrating and makes me wonder if there will be forward incompatibilities between Silverlight 2 and WPF 3.0+.  This would be a huge mistake when you stack Silverlight/WPF up against its competitor Flex/Tamarin, which is only getting more and more support through the ActionScript Message Framework.

I also filed a bug pointing out IMHO a rather significant public API design flaw in Beta 2 that wasn't in Beta 1: silverlight.net/.../20972.aspx  This is IMHO a huge mistake since it differs from WPF, and I've gotten no feedback from Rob Relyea or anyone on this.  I meticulously explained why it was not only incompatible with WPF but also a bad way to write code, and didn't even get a "Won't fix" reply.

It's a shame, because we're writing the kind of business apps Silverlight appears to be intended for.

ScottGu wrote re: Silverlight Problems That Affect Me
on 07-27-2008 1:31 AM

For the Silverlight 2 RTM release several of the things you mentioned above have been added/addressed.  A few changes I know of (there might be more I don't know about):

--- DepencencyObject and FrameworkElement will have protected constructors, allowing you to subclass from them.

-- IsEnabled will be on Control.  In addition to allowing you to disable individual controls, you can also set this on a parent and have all children of that control force inherit it (disabling all of them).

-- The ComboBox control will be in the final Silverlight 2 release.  Both ListBox and ComboBox will derive from a Selector base class that encapsulates selection logic.

-- The DependencyObject metadata property will support default values (so that you don't need to set them in constructors).  

Note that one of the core features of Silverlight is that it is easy to deploy (especially on older, downlevel machines) and that it works cross platform.  The internet deployment friendly aspect requires a small, tight download (currently 4.6MB for everything, and less than 7 seconds to install) - which obviously means that not every feature in the full .NET Framework (70MB) or full WPF (nearly 20MB just by itself) can fit into it.

Over time more features in the full WPF will get added (for example: element to element data binding will show up in the next release).  We are trying to keep the core Silverlight 2 release as tight as possible though so that we don't end up growing it so big as to impact deployment, or increase the size with so many "nice to have" features that would make it hard for us to add more "must have" features in the future without running into size problems.  

Hope this helps,

Scott

Dew Drop - July 27, 2008 | Alvin Ashcraft's Morning Dew wrote Dew Drop - July 27, 2008 | Alvin Ashcraft's Morning Dew
on 07-27-2008 9:11 AM

Pingback from  Dew Drop - July 27, 2008 | Alvin Ashcraft's Morning Dew

Rob Eisenberg wrote re: Silverlight Problems That Affect Me
on 07-27-2008 10:13 AM

@Scott

Thanks for addressing my comments.  I'm sure many people will find this information assuring.  I know the SL team has a difficult job and I'm definately on board with the product.  I want to see it become the best it can.

Neil Mosafi wrote re: Silverlight Problems That Affect Me
on 07-27-2008 7:46 PM
Hey Rob, I definitely agree with most of this, and can understand that the need to keep things lean and mean is making it painful for WPF developers to adopt Silverlight. I will also add that the lack of event tunnelling is hurting me (I need to capture events before they hit the target element so I can, for example, block them or change them). Also no OnVisualParentChanged template method, and no ICollectionView interface for sorting/filtering when binding to collections seem strange to me! Oh, you might be interested... I have made a solution for element name binding - http://neilmosafi.blogspot.com/2008/05/silverlight-2-creating-bindings-between.html
Reflective Perspective - Chris Alcock » The Morning Brew #145 wrote Reflective Perspective - Chris Alcock &raquo; The Morning Brew #145
on 07-28-2008 3:11 AM

Pingback from  Reflective Perspective - Chris Alcock  &raquo; The Morning Brew #145

Cristian Merighi wrote re: Silverlight Problems That Affect Me
on 07-28-2008 8:38 AM
"...in Silverlight the lowest level base class I can inherit from is Control..." Try with FrameworkTemplate...
Rob Eisenberg wrote re: Silverlight Problems That Affect Me
on 07-28-2008 11:23 AM

@Cristian

True.  But I don't want a template either.  However, it looks like this problem will be mostly solved in the RTM.

Joe wrote re: Silverlight Problems That Affect Me
on 07-28-2008 3:21 PM
@Scott, I think too much emphasis here is being placed on size vs compatability. If you sit down and realy think about it, you would hardly have anyone using the .NET Framework in general if size were an issue. In my opinion, the importance placed on size is severly restricting the Silverlight feature set. Personally, I think this whole thing is headed for disaster. We have completely stopped pitching Silverlight to our customers because of the hack/wish washy architecture of Silverlight. Every time we try and do something we only end up frustrated. It's a shame too because we were looking forward to Silverlight. You cannot easily port between Silverlight and WPF, the markup is different, the whole ControlTemplate/Part Model thing is a joke in Silverlight. We are just waiting to see whats next on the list of things to try for that aspect. I really don't care about what's coming, the framework/markup should have been the same since day 1. How you can decide to port WPF to the web and leave fundamentals out like such as x:Type and Triggers is beyond me.
samcov wrote re: Silverlight Problems That Affect Me
on 07-29-2008 5:13 AM
@Scott, is SL2B2 going to be the version used at the Olympics? If so, does that mean any future versions will be backwards compatible? Actually, this is a question that doesn't have a good answer, unless it's that another version is coming out before the Olympics. Sorry to ask a tough one, but we're running out of Silver Bullets and credability with customers defending the SilverLight platform, and comitting to realistic project timelines. In short, we're in the dark, the mushrooms are tainted, and the other stuff really smells.
Ezequiel Jadib’s Blog » Silverlight & Composite Application Guidance (Prism): Spike published wrote Ezequiel Jadib&#8217;s Blog &raquo; Silverlight &amp; Composite Application Guidance (Prism): Spike published
on 08-06-2008 2:49 PM

Pingback from  Ezequiel Jadib&#8217;s Blog &raquo; Silverlight &amp; Composite Application Guidance (Prism): Spike published

Ezequiel Jadib wrote Silverlight & Composite Application Guidance (Prism): Spike published
on 08-06-2008 3:10 PM

Weeks ago we shipped the Composite Application Guidance for WPF and with the Prism team we started to

Flavien wrote re: Silverlight Problems That Affect Me
on 08-07-2008 9:50 AM
Things that affect me: - No DataTemplateSelector - No multi-selection for the ListBox

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)