First time here?

You are looking at the most recent posts. You may also want to check out older archives. Please leave a comment, ask a question and consider subscribing to the latest posts via RSS or email. Thank you for visiting!

One of the features that a lot of developers seem to enjoy is the out-of-browser feature in Silverlight.  This is the feature that allows you to take your Silverlight application and run it like a desktop application (without some of the trust levels right now).  If you aren’t familiar with the feature, take a moment and familiarize yourself with it…here’s some info:

Now that you have some basis of understanding, allow me to share a thought I’ve had.  I’m seeing a few people wanting to force the out-of-browser (OOB) experience.  That is to say, they want their application to be only run in OOB mode. 

NOTE: If you feel you want this, you should understand the limitations in OOB mode.  Namely the HTML bridge features and certain network implications might affect your applications depending on your needs.

Honestly I am not sure I entirely see the value in that (forcing it), so if you have one, please enlighten me (maybe gaming I suppose).  After all, IsolatedStorage is shared between OOB and in-browser Silverlight applications from the same source.  But I digress. 

The Problem

One thing that I’ve seen is folks asking for a method on how they can force the OOB mode in their app.  One of the security features of OOB is that the Install action must be user initiated.  This means it must be from the end-user action…not automated.  So you can’t just send a URL to someone and have it suddenly install the application OOB.  So how would you go about this?

A Solution

Easy, I think.  Here’s the pattern that I think might work.  I’ll note that this is just my opinion of a solution…not the defacto in all situations.  By all means please consider your own scenario needs before blindly adopting.  That being said, I think it might be helpful to explore.  This solution involves leveraging the OOB APIs available to the developer and creating some different views in your application.

Step 1: Create some views

What you’ll need here really is two views (for lack of a better term at this point – if you want to call them controls, that is fine too) in addition to your main application.  I’ve called one Installer and the other Installed.  The purpose of Installer is that this will be the view shown when a user does not have the application installed OOB.  The purpose of Installed is that it will be the view shown when a user does have the OOB application installed *and* is attempting to view the application in-browser.  The third “view,” your application, is what will be rendered when the user views the OOB application.  Put Installer and Installed wherever you’d like in your app.  I created a folder called Views and stuck them there. 

For Installer, you’ll want to put some UI in here for the Installer “badge.”  I highly recommend putting some time into this using Expression Blend to make it all look great and perhaps add any visual states you may want.  Remember, this is your user’s first impression.  This is still a Silverlight application, so go nuts with styling and using controls.  But you don’t need to make these the same size as your application.  For my example, my OOB application is 800x600, but my Installer app is only 300x162.  This Installer control/view will contain your actual install logic.  So somewhere here you need to have a button or something that the user can initiate as an action that you can call the Install method.  A button is easiest and easy to style.  In the Click event all you have to do (in simplest form, of course you’d want to add some error handling) is add the API call to install:

   1: Application.Current.Install();

For Installed, you’ll do the same thing, except make the UI/UX for the experience of letting someone know they already have it installed.  This could be something as simple as a text message, or complete instructions, etc., whatever.  You decide.

When you are done with this step you should have two XAML UserControls: Installer.xaml and Installed.xaml both for their specific purpose.

Step 2: Wire up the application startup logic

What I’ve chosen to do is take control of the App_Startup logic to determine the state.  I felt it would be better here based on the scenario I’m trying to accomplish rather than to load a default UserControl and have to do some funky app logic to swap out the RootVisual.  What I’ve chosen to do is to check the state of the trigger to run and follow some logic:

  • If the app is installed and the user is running in-browser: Show Installed
  • If the app is not installed and the user running in-browser: Show Installer
  • Else: Show App

The logic finds the correct state in a simple if…elseif…else statement and decides which RootVisual to show.  Here’s the complete code:

   1: private void Application_Startup(object sender, StartupEventArgs e)
   2: {
   3:     if ((App.Current.InstallState == InstallState.Installed) && (!App.Current.IsRunningOutOfBrowser))
   4:     {
   5:         this.RootVisual = new Installed();
   6:     }
   7:     else if (!App.Current.IsRunningOutOfBrowser)
   8:     {
   9:         this.RootVisual = new Installer();
  10:     }
  11:     else
  12:     {
  13:         this.RootVisual = new MainPage();
  14:     }
  15: }

Simple, isn’t it?  You can see that the “app” that gets run is the correct starting point given the state.

Step 3: Configure your OOB settings

Visual Studio 2008 adds a dialog feature for you to easily generate the OOB settings.  You can read more about that here and see some screenshots: Silverlight Out-of-browser Settings Dialog.  Once you’ve done this, when you compile your application it enables it for OOB install capabilities.

Step 4: Deploy

That’s really it.  Of course the harder part is your own application :-), but that’s for you to figure out, not me.  In the end you could then embed your application somewhere within a web page.  It will show your Installer if the user doesn’t have it, or remind them it’s already installed if they do.  Here’s a working example based on this pattern (Silverlight 3 required to run this application):

This is just a stub example app, no working functionality in the main application.  The purpose is just to show this pattern.  As you can see, when the application runs, it runs at the desired 800x600 application width that I want for my actual application, game, whatever.  All this while I minimize the impact visually to show the messages of the Installer and the Installed controls.


This is just a sample pattern that you may want to implement if the need (or desire) is there to force your applications to be run OOB.  Again, OOB in general should be understood before blindly going in and assuming 100% of what you have will run in this mode.  But if it will and this is something you want, you may consider using this pattern to make a smaller visual impact on the installer and providing the end user with a better user experience to get it installed.  Or at least it was an experiment for me.

Hope this helps!

This work is licensed under a Creative Commons Attribution By license.

8/12/2009 9:56 AM | # re: An out-of-browser install pattern for Silverlight
I can think of one scenario where forcing OOB makes sense. Using Silverlight OOB for Second Life.
8/12/2009 10:34 AM | # re: An out-of-browser install pattern for Silverlight
Tim, the sample application on this page, is the source available anywhere? And keep the good stuff comming. Great job!
8/12/2009 10:37 AM | # re: An out-of-browser install pattern for Silverlight
One problem with this Tim is if the user deletes (or their profile gets corrupted, etc...) their shortcut to the app. There is no good way to restore it, yet the browser-hosted version will still think it is installed (it is, just unreachable). Any solution like you suggest should keep this scenario in mind and allow the user to re-install to get their shortcut back, otherwise they'll be unable to use the app at all. (I think this is only a problem on Windows, as on the Mac it actually creates an app bundle).
8/12/2009 11:32 AM | # re: An out-of-browser install pattern for Silverlight
saswtr - the core code is basically in the blog post -- are you wanting to see the XAML for the elements? There isn't much there :-)

Jason -- it's a good point. If the user deletes their shortcut, they don't have an easy way to "reinstall" the app. Running .Install again would throw an exception because the runtime thinks it is still installed. I think this is a pain point of the feature that I know we're aware of. The "Installed" control that I speak of in this post should take that into consideration for now as a workaround and instruct the user 'hey it is already installed. if you can't find it, right-click here and uninstall it then re-install' -- not ideal but works.
8/12/2009 11:37 AM | # re: An out-of-browser install pattern for Silverlight
Cool post.. look my open-source project Silverlight OOB Extension on codeplex. Silverlight OOB extension is for offline data caching.. Perfect for the offline use of Silverlight applications out of Browser.. http://oobextension.codeplex.com
8/13/2009 2:45 AM | # re: An out-of-browser install pattern for Silverlight
As to the motivations to have a forced OOB, the best I could think of is the usual - customers not wanting to work in a given environment & dev's not wanting to change their platform. :)

From experience, a tiny group of customers will not (capital-letter, shouting, spittle-slinging will nots) work on anything in a browser. Or allow their underlings to work in a browser constantly, as they fear they may not have the moral fiber to abstain from browsing the internet in their corporate time if its in their face all the time. :)

Perhaps its an attempt to reduce bandwidth consumption of large SL apps.
It could also be great fun to force OOB a fake Messenger or Office Communicator and get your credentials. Forced OOB and Ad networks could be the spawn of the evil one.

In my view Forced OOB should require administrator approval of source domain or URL or the package - LUA style/Group Policy.
8/17/2009 12:56 AM | # Why you might want to force OOB
Maybe one the reason you might force OOB:

If you don't and you have a large app and customers blame you every time their cache expires and the xap file needs to be downloaded again.

Yes they could install the app OOB but if they are not forced to do it, some of them won't (and still blame the developer for the delay).
10/5/2009 12:45 PM | # re: An out-of-browser install pattern for Silverlight
Where is the source code of the sample animation available?
10/7/2009 7:56 AM | # re: An out-of-browser install pattern for Silverlight
can we get a source code for oob application you mentioned here? its very nice ui as well as effects.
10/20/2009 2:33 AM | # re: An out-of-browser install pattern for Silverlight
How to uninstall the OOB application?
10/26/2009 5:53 AM | # re: An out-of-browser install pattern for Silverlight
12/23/2009 4:21 PM | # re: An out-of-browser install pattern for Silverlight
This is awesome, thanks Tim!
1/24/2010 2:54 PM | # re: An out-of-browser install pattern for Silverlight
There doesn't appear to be any way for the web UI to launch the app OOB if it's already installed. When the user installs the app it launches automatically, but if it's already there, the web UI doesn't seem to be able to kick it off.

This looks like it's still true in the Silverlight 4 beta right now. And that seems like a problem - Silverlight 4 gives you more reasons why you might always need to run OOB because some of its new features are only available OOB. (Anything requiring elevation, for example.)

Right now we have a pretty horrible usability story for users who tried to use the app by the same path they followed last time. "Hello, yes, I know this is the same route you followed last time, but we're not going to let you in this door. Yes I know this is the door you came in last time, but we're going to hand you some instructions and force you to go and find a completely different door, and then we'll let you in."

Users could reasonably respond "You let me in this door last time - why can't I come in this way again?" (ClickOnce works just fine here IIRC - if you click on a link for an already-installed app, it'll just launch the installed app as far as I can remember.)

Unless I missed some way of doing it, I'm guessing it's to late to fix this for Silverlight 4, but I'd like to request that there be a way to do this in Silverlight 5. Since we now have situations where we unavoidably have to force the user to run the OOB version, it seems like it should be possible for the way the user ran the app first time round always to work.
1/26/2010 11:28 PM | # re: An out-of-browser install pattern for Silverlight
Hi Tim,
Great feature here, I am able to integrate OOB in my Ruby On Rails. so, I guess should be problem. However, when I turn autoupdate feature on, it looks like application kept saying a new update available.

I don't have workaround of this problem yet, but guessing this should be good info for you.

2/3/2010 3:16 PM | # Problem with Out Of Browser installa
Hi Tim,

I am trying to have an Out Of Browser respresentaion of a pretty basic clock that I implemented in silverlight. I was able to make those changes in my code and run it in browser. When I right click I do get the option to install and I can see it installed on my machine. But when I try launching it it says "searching for sllauncher.exe" and this eventually fails asking me to remove the shortcut from machine. Am I missing something?

2/3/2010 3:42 PM | # re: An out-of-browser install pattern for Silverlight
Shubham - Wow, that is weird. So you were able to successfully install the application? Can you look at the properties of the shortcut created and let me know what it says? email me offline so we can debug (timheuer at microsoft dot com)
2/8/2010 8:16 PM | # re: An out-of-browser install pattern for Silverlight
Hi Tim
This post is awesome. I am new to silverlight. Any chance you could share out the entire code alogn wiht XAML for me to understnad how they work altogether please. Hihgly appreciate if you could do so. Thanks
2/22/2010 1:52 PM | # re: An out-of-browser install pattern for Silverlight
Hi Tim, thanks for the article! I am probably going to need to do something similiar with an app I'm currently building. Basically the need is for a user to go a website and "click to install" the application, but the application itself isn't really part of the site but just a feature that's offered through the site.

The technique you have works well for this in that the UI to install the app is just a small box with a button on it and the app itself would be much larger or even full screen. And when users return to the site they can see that they already have this feature installed.

One thing I'd like to ask you about, would it be possible for the the Installer UI to be a separate XAP from the Application's XAP? The reason being if the full application ends up being quite a large download, say like 100Mb+, then wouldn't the user have to wait for the whole app (Installer + Installed + Actual Application) to download just to see the tiny Installer UI that would sit on the web page? I dont see how this could work because it seems like you'd have to ask one app to install another, but all this stuff is new to me so just wondering if you had any insight on this?


2/22/2010 2:06 PM | # re: An out-of-browser install pattern for Silverlight
Dan -- the app that gets installed is the XAP that is loaded in the application domain. You can have a light-weight XAP that uses dynamic XAP loading though to reduce your initial footprint.
3/11/2010 11:11 AM | # re: An out-of-browser install pattern for Silverlight
Hi Tim,

I have a problem and thought of seeking your expertise. My goal is to use silverlight 3 to create an app which would be integrated into outlook. Either by replacing the Outlook today screen or by some other way however possible. The reason I want to use Silverlight 3 is that this app would also be used in the web. (XBAP is also an option, but I really have not considered it so far)

I have two questions:
a) Does Silverlight 3 (or just silverlight) work with Outlook at all? I created a silverlight app with a supporting ASP.NET page and hosted it in local IIS. And when I browse this page using the outlook "address bar", it works fine. But when I set this URL as the 'today' screen, the silverlight app loads (right clicking shows 'silveright' context menu), but no UI is displayed. Not sure why it works when browsed from "address bar" and not when set as "home page" in outlook today screen.

b) Since the above option does not work, I was trying the Out of Browser option. Does this help at all in displaying a silverlight 3 app "within" outlook as an "add-in"?

Appreciate your help and thanks very much in advance.
3/11/2010 11:15 AM | # re: An out-of-browser install pattern for Silverlight
Sorry, I forgot to mention that this application targets outlook 2003.
3/11/2010 11:30 AM | # re: An out-of-browser install pattern for Silverlight
Shankara -- look at http://www.redcritter.com
3/14/2010 1:58 AM | # re: An out-of-browser install pattern for Silverlight
Application.Current.Install(); is fantastic!!!

Is there a progammatic way that I can call the uninstall code? Currently I have to instruct the user to right click and remove application.
6/10/2010 5:35 AM | # re: An out-of-browser install pattern for Silverlight
> Dan -- the app that gets installed is the XAP that is
> loaded in the application domain. You can have a
> light-weight XAP that uses dynamic XAP loading
> though to reduce your initial footprint.

Hi Tim,

I have tried using the dynamic loading of XAP files techinique using MEF and Prism. The application once installed out-of-browser tries to get the modules from the internet and caches them. Every time the cache is cleared, the modules need to be retrieved from the internet. Which is not an ideal solution for an Out-Of-Browser application. Is there any way we could achieve the installation of a different XAP file from the one that is currently displaying content ?

6/10/2010 9:13 AM | # re: An out-of-browser install pattern for Silverlight
Nrupal - you could instead put your dynamic XAPs in IsolatedStorage instead of relying on the browser cache. Of course, now you'll have to manage some type of version checking yourself.
6/18/2010 11:18 PM | # re: An out-of-browser install pattern for Silverlight
Hi Tim ,I created an exe for my out-of-browser silverlight application.The size of my .exe file is 10 MB can it be reduced
4/29/2011 5:47 AM | # re: An out-of-browser install pattern for Silverlight
This is really mind blowing. I would love to get more information on this. Thanks a lot. pneumonia symptoms
4/30/2011 4:05 AM | # re: An out-of-browser install pattern for Silverlight
Wow, simply great. I like to be one of this. lupus symptoms
9/21/2011 6:27 AM | # re: An out-of-browser install pattern for Silverlight
This is the feature that allows you to take your Silverlight application and run it like a desktop application without some of the trust levels right now. hire a java programmer
11/16/2011 3:08 AM | # re: An out-of-browser install pattern for Silverlight
In my case, I'm using the Browser Control which is only works on OOB Mode. And also I don't want to instruct to right click every time I publish this program. That's why I have to force to install. Do you have any idea to display web inside Silverlight?
11/17/2011 4:34 AM | # re: An out-of-browser install pattern for Silverlight
How can we get WCF url passed to OOB application. As we do using Initparameter in Silverlight application.
1/17/2013 9:05 AM | # re: An out-of-browser install pattern for Silverlight
Hi --
Just came across this, and it looks very useful for what I'm working on today.
However, I can't figure out the transition from "Installer" to "Installed".
Any hints on how to do that?
Thanks --

Please add 2 and 3 and type the answer here:


The opinions/content expressed on this blog are provided "ASIS" with no warranties and are my own personal opinions/content (unless otherwise noted) and do not represent my employer's view in any way.