Silverlight Fully Trusted Out of Browser

Certainly the most buzz generated in Silverlight 4 is its Fully Trusted Out of Browser (OOB) capability.  In my opinion this is the most exciting and significant feature, and it’s also the most misunderstood.  So, this month’s column will be dedicated to attempting to clear up some of the confusion and to discuss the power and implications.

Silverlight 4 OOB Defined: a Bridge from Web to Desktop

Firstly, what does OOB mean?  Well, put in the simplest terms I can describe, it means running a Silverlight application natively in Windows or on the Mac, without the dependency of a browser. In this regard it looks, feels, behaves and has many of the features of a native, Windows Form, or Windows Presentation Foundation (WPF) application (on Windows).  And because it doesn’t have the dependency of the browser it also means it has no access to the HTML DOM.  Consequently, in a Silverlight 4 OOB application you do not have access to NTML and JavaScript. Because of this, a new network stack was added to support Silverlight OOB. When you add the ability for your Silverlight 4 application to run fully trusted in the OS, you have some real potential for power. But, with power comes responsibility.

The scenarios are compelling. Imagine providing a Silverlight web application that runs cross platform in the browser as a “free” or “light” version and allowing the user to install the fully licensed “Professional” fee based version OOB.  Imagine a company’s portal run in “regular” browser-dependent Silverlight for when outside the firewall or corporate VPN and providing a fully trusted fully featured Silverlight 4 OOB version when inside the firewall or VPN. I could keep going. The point is that Silverlight OOB provides a number of new application scenarios we didn’t dream of doing just a couple years ago and added some more significant complexity to the solution architect’s job.

Silverlight 4 OOB Application Capabilities

Access to data is paramount in Silverlight 4 OOB applications, just as it is with the majority of applications.Silverlight 4 OOB applications can talk to the exact same web services you are used to in regular Silverlight applications.  But, because SL4 OOB applications are provided 25MB of isolated storage (by default; it can be configured: http://silverlight.net/blogs/msnow/archive/2008/07/17/tip-of-the-day-20-how-to-increase-the-isolated-storage-quota-for-your-app.aspx) you have the capability of local storage and along with it offline, disconnected ,and automatic data synchronization capabilities. With Silverlight 4’s OOB isolated storage you can serialize your data to XML so that you can write, read, and query it with LINQ.

Now with full trust comes access to a number of resources of the machine—software and hardware. Scott Guthrie told me a while back that in Silverlight 3, the number one requested feature was programmatic access to the computer’s video camera device. And with Silverlight 4, we have that access and to other hardware devices. But, we also have access to software resources like COM. With Silverlight 4 fully trusted OOB, COM access gives us the capability to do things like embed office components like Outlook or Excel into our Silverlight 4 applications. If you think this through, there are some potential impacts that can be interpreted as negative for that type of power:

You will end up doing a Mac version of your app and a Windows version of your app. Or equivalently doing some form of coding like this:

switch (Platform)

\{

  case Platform.Windows:

    //...

    break;

  case Platform.Mac:

    //...

    break;

\}

It inherently means you are going to be able to things in SL4 in Windows that you cannot do in SL4 for the Mac.

I personally think the simple fact that our Silverlight applications run at all on the Mac is cool and powerful. But, I am guessing as Silverlight 4 applications proliferate at the end of the year, and we start to see diversification between Mac and Windows versions of the same SL4 app, there is going to be some fodder in the discussions in the blogs (and in the bars).

Simple Guidance for the Solution Architect

If you are looking for a feature rich desktop version to an existing Silverlight application, Silverlight 4 OOB more times than not will be the way to go. Chances are you will not have to fork your code base and will be able to leverage a ton of code in the existing application structure.  If you are simply looking for a desktop application, more times than not WPF would be the logical choice over Silverlight 4 LOB. WPF is rich and elegant, and as far as its API is concerned it dwarfs its little Silverlight brother. Although magnificently feature-rich there is only so much you can do within the constraints of the lightweight 4.2MB runtime that is Silverlight.

Where to Go Next

For more information Tim Heuer of Microsoft has done a detailed video on how to code an SL app for OOB. It’s hosted on Silverlight.net at http://silverlight.net/learn/learnvideo.aspx?video=187318.

For an example of fully trusted Silverlight 4 OOB applications check out the application we (InterKnowlogy) built for Snapflow that was highlighted in Scott Guthrie’s keynote demo at the PDC in October:  http://microsoftpdc.com/Sessions/KEY02 .