Unexpected changes from Silverlight 3 Beta to RTW, The Good and The Confusing

By now, everyone should know that Silverlight 3 is official. Born on July 10th at a big launch event in San Francisco, Silverlight 3 completes the 9 month cycle of improvement that kicked-off immediately after the official release of Silverlight 2 in October of 2008.

If you are at all interested in Silverlight, you probably participated in the Silverlight 3 beta. It was a great beta program that gave developers a solid look at many of SL3’s new features, but as with all betas, there were changes in the final Release To Web (RTW). Actually, there were a lot of changes, many of them “breaking,” though I’ll be quick to acknowledge that you’re “allowed” to make breaking changes during a beta cycle. You can find a complete listing of changes and how you should address them on MSDN:

http://msdn.microsoft.com/en-us/library/cc645049(VS.95).aspx

So far, so good.

In fact, some of the changes in the RTW are good breaking changes.

• Out-of-Browser API Breaking Changes
  During the beta, this API had some less than intuitive names that lead to some awkward programming. For instance, during the beta, the idea of taking a Silverlight application OOB was considered “detaching” it from the browser. When running in a “detached” state, the Silverlight app was said to be “RunningOffline.” Confusing, since an OOB Silverlight app can still be connected to the Internet and running “online.”
  
  In the RTW, the API names are much better. You now “Install” a Silverlight app to take it out of browser (instead of “Detach”), and you can detect OOB apps by checking the “RunningOutOfBrowser” property (instead of “RunningOffline”). Much better…
• Assembly Caching Changes
  During the beta, there were two problems with Assembly Caching (a.k.a Transparent Platform Extensions): it only worked with Microsoft assemblies and it required that the assemblies come from Microsoft.com. With the RTW, both problems are fixed. Now any assembly (including 3rd party assemblies, like Telerik’s RadControls) can be cached and by default the assemblies will come from your own domain (though apparently you can still use the Microsoft.com downloads if you want them).
• URI Mapper Changes
  Less breaking change, more RTW improvement, the URI Mapper (used in Silverlight Navigation to define URL routes) is now part of the default “Silverlight Navigation Application” Visual Studio template. In RTW, the Navigation routes include a “pattern matching” convention by default (instead of hard coding all links), which I think is going to make it a lot easier for people to discover the path to “clean” Silverlight deep-linking URLs.

Not all breaking changes in the RTW are good, though. And I’m not complaining about changes that are just frustrating because they break code. I’m talking changes that actually made me pause in confusion and wonder if Microsoft made the right choice in their design decision.

• The ASP.NET Silverlight Controls Are Dead
  This is the most shocking and confusing change to me. In the Silverlight 3 RTW, Microsoft has officially “killed” the Silverlight ASP.NET server controls (<asp:silverlight… and <asp:mediaplayer…). These weren’t complicated controls. They were simple wrappers that automated the somewhat tedious process of adding all of the HTML object embed tag code required to place a Silverlight application on a page. I, for one, found them convenient.
  
  To make matters more confusing, Microsoft isn’t making very clear why they killed them- only that the new guidance is to write the Silverlight embed HTML yourself (or use the new VS templates). You can continue to use the “old” version of these server controls, and you can even download the source and enhance them. But I’m still left wondering why these controls were abandoned.
• More Controls Removed from the Silverlight SDK
  I get that Microsoft wants (needs?) to keep the Silverlight plug-in size small. I was happy to hear at MIX 09 that after all the new features in Silverlight 3 that the plug-in size got smaller. But with the Silverlight 3 RTW, Microsoft has moved 10 controls back out of the SDK and in to the Toolkit. And what does that mean…
  
  It means your application XAPs just got bigger if you use any of these controls. Frankly, I’d rather have a 1% bigger core install and save all apps from delivering these controls.
  
  And should we really have to use the Toolkit for basic layout controls like WrapPanel and DockPanel? I know the Toolkit helps controls get updated faster, but these seem like staples that belong in the core- where they started in Silverlight 3 beta!

Silverlight 3 is a huge improvement over Silverlight 2. I think it is the version that is going to really make more people attempt serious application development on the RIA platform. The feedback from the Beta program obviously had a real and noticeable impact on the RTW- I’m just not sure all of the impacts are good.

What do you think?