| Comments

One of the features we are introducing in Silverlight 4 is a ‘silent install’ mechanism for out-of-browser applications.  Currently every out-of-browser application (trusted or not) starts from an in-browser mechanism.  In some instances where you want to deploy the app via managed desktop software or perhaps via CD-ROM, you don’t want to have to tell the user to start on an HTML page first.

Now I’m not going to write here about the merits of why you might want to do this other than to point out what I believe to be the 2 prominent scenarios: managed desktop deployment and CD/DVD distribution.  I know some of you might be thinking Well if it is a managed desktop environment, why not just use WPF then? – and I would pose the same question to the customer as well first.  But again, this post is to merely outline the capabilities and I’ll let you all debate the reasons :-)

The function still requires the Silverlight plugin to be installed (and requires Silverlight 4).  It would also require the ability to install out-of-browser applications (there is a possibility for an administrator to disable this feature).  Given those two requirements, the key tool at your disposal is sllauncher.exe.  This is installed with the plugin and is located at %ProgramFiles%\Microsoft Silverlight on the machine.

NOTE: The features I’m describing here are for Windows machines.  Out-of-browser applications on OSX are actually deployed as ‘apps’ (.app) versus how just the XAP is deployed on a Windows machine.  I’m investigating how to do something similar here with scripting on OSX, but I’m unfortunately not a Mac developer :-).

Let’s take a look at the required steps and a scenario.

The Setup

You’ll need to ensure that the plugin is installed as I mentioned earlier.  You’ll also want to have a copy of the XAP handy that you’ll want to be installing.  This would be the main XAP and would be the same one that would be in the Source parameter of the <object> tag where you normally would host this.

NOTE: Because “Program Files” is different on 32- and 64-bit machines you’ll want to make sure your script/installer can handle the determination of where the sllauncher.exe program will be.  Since it isn’t a native 64-bit app, it will be in “Program Files (x86)” on a 64-bit machine.  This sometimes can cause confusion because the %ProgramFiles% environment variable on 64-bit is the native program files directory and *not* the x86 one.

Your Silverlight XAP will already have to have been configured for out-of-browser and have the appropriate manifest information within it.

Once you have those you can move on to understanding the parameters.

The Options for Install

The sllauncher.exe program for install require at a minimum 2 options and I’ll suggest that you always use all 4 I will describe here.

/install:”path-toXAP-File” – this is the first and points to the XAP file you are wanting to install.  This might be on a network share, on the CD, or in an installer.  This is required.

/origin:”URI-to-origin” – this is the ‘origin’ of the XAP and is required.  Even though you might not be using auto-update features, etc. you must set this.  I actually recommend being smart about it and having the XAP on a real URI endpoint as well so that your origin is actually real.

/shortcut:desktop+startmenu – while this is optional, it actually seems silly not to include at least one – or your users will have a hard time launching your application!  You can use: desktop, startmenu, or desktop+startmenu (my recommendation).

/overwrite – this option confirms the XAP you are installing will overwrite any existing version currently there.  This is optional, but again, I think you should use it.

Let’s assume the following scenario using the Silverlight Client for Facebook application as an example.  I have the XAP (Silverface.xap) that I want to deploy.  I would use the following command:

   1: "%ProgramFiles%\Microsoft Silverlight\sllauncher.exe" 
   2:     /install:"Silverface.xap" 
   3:     /origin:"http://www.silverlight.net/content/samples/apps/facebookclient/ClientBin/Silverface.xap" 
   4:     /shortcut:desktop+startmenu /overwrite

This assumes that I’m calling this command from where the Silverface.xap is currently.  Notice that the origin parameter points to the XAP origin and not the site hosting it.  This is important.  This above command would install the app and create shortcuts.

Automatically Launching the App

So what if you wanted to also automatically launch the app after installing (i.e., the CD/DVD ‘autorun’ scenario).  You again would use sllauncher.exe to do this for you after you’ve installed the app.  Using our same sample above here would be the command:

   1: "%ProgramFiles%\Microsoft Silverlight\sllauncher.exe" 
   2:     /emulate:"Silverface.xap" 
   3:     /origin:"http://www.silverlight.net/content/samples/apps/facebookclient/ClientBin/Silverface.xap" 
   4:     /overwrite

Notice the emulate command.  This is the launcher.  Now you’ll notice that this isn’t the same command-line options if you looked at an installed applications’ created shortcuts.  Because the folder where the XAP gets installed is pretty random, we use the origin as the hint to the sllauncher.exe program to find the right app for us and start it up.  I’ve found that using /overwrite will also give a more consistent behavior.

Uninstalling the App

What if now you want to uninstall the app?  Perhaps the managed desktop admins deprecate an application or you want the CD/DVD experience to be a non-transient one and clean up when done.  The command again is simple:

   1: "%ProgramFiles%\Microsoft Silverlight\sllauncher.exe" 
   2:     /uninstall 
   3:     /origin:http://www.silverlight.net/content/samples/apps/facebookclient/ClientBin/Silverface.xap

Instead of the install parameter you use the uninstall parameter.  Again, notice the use of the origin parameter – this is critical in all these tasks.  The above command would remove the application and essentially does the same thing as the right-click Remove this application context menu option in Silverlight.

Using these commands in Installers

While I think those that actually have a need for this option will be using scripts and batch files, I do think some may want to include this in an installer experience.  The only option I can see for this is because you are also deploying some additional items along with your XAP (perhaps assets to the user’s document store that the app will use later like plugins or something).  Other than that if you are creating an installer simply to wrap the above methods, it might not seem wise.

Why, you ask?  Well if you think about it, your installer itself will stamp an entry into Windows as an installed application and Silverlight will also stamp an entry.  In our Facebook example, the Add/Remove Programs would show 2 “Silverlight for Facebook” entries (assuming we named our installer that as well).  This would likely confuse the user.  I’m not saying it isn’t impossible to do this nor is it difficult to manage, I just think it looks odd.

Regardless, if you are using something like InstallShield (FYI look for InstallShield LE in Visual Studio 2010…it’s very good) or the Visual Studio Setup projects, you can include a Custom Action to these installers.  The process would be a custom action *after* the install is complete because you need to locate the XAP to install.  Most setup programs are easy to use and provide pre-configured platform-specific environment variables you can use to map to things like the correct Program Files directory.

In the ideal situation you’re batch file/installer should check for the presence of Silverlight (and the correct version).  These can be done using file path verification or registry checking, both of which are outlined in the deployment guide whitepaper.

What about redistribution of Silverlight?  Right now we do not have broad redistribution rights for Silverlight.  You will still need to point users to where they can get the plugin so that they can be presented with the EULA and get the correct version for their platform.

If you do use the installer route, make sure that you account for clean un-installations as well!

Other insights and summary

You may be asking yourself if the user will be prompted here to install the application?  The answer is no.  Since this is essentially a command-line execution, the trust is implied here.  The user first has to knowingly type the command (not likely) or knowingly execute your install mechanism (batch file, installer, whatever).  These commands cannot be automatically run from the browser, for example.  For managed desktops, sure, these may be silently installed.  This is intended because in a managed desktop environment the software is, well, managed.  An elevated or normal-privileged application will install just the same using these methods.

As to the shortcuts (the /shortcut parameter being optional).  I think we’re going to fix that in some update.  Again, it’s a bit foolish to not provide one so consider it required :-).

If you find yourself in a situation needing this, hopefully it will come in useful.  I really think this is a helpful tool, but also a niche tool.  Those of you creating general consumer applications/sites will not benefit here really because you’ll likely start with an in-browser instance anyway.  But for those using managed desktop environments, or thinking about CD ‘autorun’ type situations, hopefully this information will come in useful.

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

| Comments

UPDATE: Silverlight 4 is RELEASED!  READ HERE!

Silverlight 4At MIX10, Silverlight 4 released an update, the Silverlight 4 RC (release candidate).  A few things have changed since the beta which was released in November.  If you haven’t read my guide to Silverlight 4 you may want to check that out.  The features still exist, but there are some changes to the implementations of some of the features as well as some new ones.  Please go read the previous post to familiarize yourself with the features.  This post will be complimentary to that and identify new/changed.

First let’s get you going with the tools:

And since sometimes people just want to get going with learning resources here’s my top suggestions:

So here we go, here’s my brain dump of some key areas of what you’ll be seeing in the Silverlight 4 RC.  This is not all-inclusive, but I think a list of some that most will want to know about.


A quick note about Visual Studio 2010 RC

The Silverlight 4 tools linked above target the RC release of Visual Studio.  There have been 2 patches to Visual Studio 2010 RC since it’s release.  It is recommended that you have these two patches installed prior to installing the Silverlight tools.  Information about these patches (and links to them) is available here.

RichTextBox (the control formerly known as RichTextArea)

Silverlight 4 introduced a new control for enabling editing and display of rich text.  (See original details here for RichTextArea.)  A few things have changed here, one key one being the name: RichTextBox.  This was to be more consistent with WPF and also based on your feedback.  Additional improvements were also enabling the ability to get the XAML that makes up the underlying runs and paragraph of the rich text.  This is helpful for saving off the data and re-hydrating later if desired.  It’s a simple property on the RichTextBox control (assuming the control name is ‘MyRichContent’):

   1: string richText = MyRichContent.Xaml;

In addition to that, there are also some new text selection and position APIs to enable you programmatically select text and/or know where the current position of the text is located.  This is best demonstrated in the ‘Silverlight Notepad’ sample application in the hands-on-lab area where you can see examples of it being used.

^ back to top

WebBrowser control

The beta provided us with a mechanism for hosting HTML content within an out-of-browser application.  This is still available to us, however some APIs have changed.  The HtmlBrush is now called the WebBrowserBrush to be consistent in naming and what it actually does.

You can view a video on using the WebBrowser control here.

^ back to top

Printing API enhancements

The printing API was enhanced to help developers query for the printer page size and the printable area.  Another change was where the ‘document name’ is provided.  It is now required and a part of the Print() method.  Before:

   1: PrintDocument doc = new PrintDocument();
   2: doc.DocumentName = "Sample Document";
   3: doc.Print();


   1: PrintDocument doc = new PrintDocument();
   2: doc.Print("Sample Document");

You can view a video on using the printing APIs here.

^ back to top

Native automation (COM interop)

API changes in the naming of the native integration (COM interop) feature for trusted applications.  Before:

   1: dynamic excel = ComAutomationFactory.CreateObject("Excel.Application");


   1: dynamic excel = AutomationFactory.CreateObject("Excel.Application");

Simple, but will catch you in a recompile :-).  You can view a video on using native integration here.

^ back to top

Language/script support

Silverlight now has extended language support, including Thai and Vietnamese.  Additionally we added support for multiple Indic scripts.  The following Indic scripts are now supported:

BengaliBengali, Assamese, Manipuri
DevanagariHindi, Marathi, Sanskirt, Konkani, Kashmiri, Nepali, Sindhi

^ back to top


In the beta, socket ports were still being restricted in trusted applications.  In this release, the port restriction for socket ranges in trusted applications is removed.

Additionally, the client networking stack (ClientHttp) has been enhanced to enable UploadProgress reporting and caching support.

^ back to top

User consent dialogs (webcam/clipboard/etc.)

We call those dialogs that require user permissions ‘consent dialogs.’  Your users will see these whenever code requires things like requesting device access for webcam/microphone, clipboard access, or quota increase for IsolatedStorage.  In the beta we showed these dialogs always and didn’t have a mechanism for enabling the user to determine if they wanted their consent preference saved.  That has changed in this release.  Consent dialogs now give the user the option to remember the setting which is persisted to their preferences only for that application and is in their control.  Here’s the new consent dialog for clipboard, webcam and full-screen pinning:

Silverlight consent dialog

And if you look at the Silverlight configuration dialog you’ll notice a permissions tab now where these permissions are set for the user, which they can change or delete:

Silverlight permissions dialog

This consent dialog ‘remember my preference’ setting is not available for IsolatedStorage quote increase however.  It doesn’t make sense to enable that really for that scenario.

^ back to top

XAP Signing for trusted applications

We think trusted applications (or elevated privileges applications) will be a widely used feature for this release.  We changed the install prompt dialog for trusted applications.  These are different dialogs than the typical out-of-browser install prompt as we need the user to have more information provided about them.  One key feature of a trusted application is the ability to code-sign the XAP file.  Here’s a trusted application install prompt from an un-signed application:


Unsigned trusted application on Windows

Mac OSX:

Unsigned trusted application on OSX

And here is one from a code-signed one:


Signed trusted application on Windows

Mac OSX:

Signed trusted application on OSX

Which would you feel more comfortable installing?  Notice that in signed applications your custom icon will show as well (even if you have the icon settings set up, if the app is unsigned they will not show).  The process of code signing is very simple and although I expect the tooling for Silverlight to improve on this, it is as simple as adding a post-build event task (or a task for automated builds) that uses the signtool.exe (installed with Visual Studio) to sign the XAP.  Here’s my post-build event task:

   1: "%ProgramFiles%\Microsoft SDKs\Windows\v7.0A\Bin\signtool.exe" sign /v 
   2:     /f c:\users\timheuer\documents\authenticode\timheuer.pfx 
   3:     /p "MYPASSWORD" 
   4:     /t TIMESTAMP_URI_FROM_PROVIDER $(TargetName).xap

The PFX file is an exported certificate with my private key and password protected.  You can acquire code-signing certificates (normal Authenticode ones) from providers.  We were thankful to get assistance in testing this feature from the following providers who can provide you code-signing certificates for your organization:

All of the above provide Authenticode code-signing certificates and are trusted certificate authorities (CA) on Windows.  A trusted CA means that their root certificates are already a part of Windows verification.  The process of obtaining one is not instant so plan ahead.  There is a specific organizational verification process that occurs which may require documentation of proof of the organization and a few phone calls.  Once you have these certificates you will be on your way to providing even more trusted applications to your users.

NOTE: Thawte code-signing certificate requests should be made from a Windows XP machine as their current process does not support Windows Vista or Windows 7.  If you use Vista/7 you will not be able to export to a PFX file for automated build or to have your certificate stored on other machines.  Read each instructions carefully.

You can also sign your XAP using self-signed certificates.  If you do so, it is likely that you are not a trusted CA on machines and would have to instruct your users further.  In my opinion, it is better to acquire a trusted CA cert for external applications.  Take a look at Jeff Wilcox’s epic post on Code Signing 101.

A special note on trusted applications…please read!  If you want to take advantage of using the update features of Silverlight for your application (aka CheckAndDownloadUpdateAsync), then your application must be signedIf you do not sign your XAP for a trusted application it cannot auto-update.  Self-signed works here to, but don’t get your application in a state where it cannot be updated automatically!

You can view a video walk-through of XAP signing here.

^ back to top

Custom window chrome

One of the more requested features of trusted applications is the ability to customize the ‘chrome’ around the window.  The chrome area refers to the standard OS-specific border and title bar that a typical out-of-browser application will receive.  In this release we give you the ability to customize this for your users.  The Visual Studio tools also build in the capability to make this easier for you:

Window Style setting options

You can see there are a few options to choose from for window types.  Right now we do not support transparent windows or irregular shapes but are aware of the desire to have these.  Here’s an example of the Facebook client before:

Silverlight Facebook Client (beta)

and with custom window chrome:

Silverlight Facebook Client custom window

You’ll notice that in the custom window mode that since you don’t have the OS-specific title bar with minimize/maximize/close that you’ll be responsible for doing that.  That also includes handling the window moving and resizing events.  We enable APIs for you to do all of this easily. 

You can view a video on customizing window chrome and handling resizing and moving here.

^ back to top

Pinned full-screen mode

Are you a developer with multiple monitor setup?  I’m jealous.  If you’ve used silverlight you’ve no doubt run into a situation where you’ve put something in full-screen on one monitor and anticipated being able to work on other stuff in the other monitor.  Maybe you’re watching a Netflix movie while working?  You’ve likely experienced the issue that the full-screen mode goes back to regular when activity occurs in the second monitor.

We’ve changed that to enable the developer to prompt for permission to 'pin’ the Silverlight application to the monitor.  This will prompt the consent dialog option (with preference remembering) to get the user’s permission.  The code is extremely simple:

   1: App.Current.Host.Content.FullScreenOptions = System.Windows.Interop.FullScreenOptions.StaysFullScreenWhenUnfocused;

Once that is implemented, the full-screen application will remain pinned until the user hits ESC key or until you change the IsFullScreen mode in the code for them.

You can view a video on using the full-screen pinning mode here.

^ back to top

ContextMenu control

In the beta we introduced the right-click event handling capabilities.  In most cases this would be used by developers to implement context menus.  The Silverlight Toolkit for March 2010 release now provides a ContextMenu control for you to use and wire-up for this event.  It’s similar to the one Jesse Bishop created for the beta, so if you’ve used that it should be familiar.  It also supports ICommand too!

You can get the ContextMenu control and other great controls by ensuring you download and install the Silverlight Toolkit March 2010 release.

^ back to top

SLLauncher silent installs

One of the features we added in this release was using the sllauncher.exe (which is the program that assists in out-of-browser applications) to provide silent install capabilities for your applications.  The primary scenario here would be something like CD-based installation situations.  Using a command like this:

   1: "%ProgramFiles%\Microsoft Silverlight\sllauncher.exe"  
   2:     /install:"D:\deploy\demoapp.xap"  
   3:     /origin:"http://foocompany.com/apps/ClientBin/demoapp.xap"  
   4:     /shortcut:desktop+startmenu  
   5:     /overwrite 

would enable you to deploy an application in this type of a situation.  Setting the origin flag here enables the application to determine where it would get future updates from if CheckAndDownloadUpdateAsync methods are called within the application.

^ back to top

WCF RIA Services Toolkit

If you read above you’ll know that installing the Silverlight 4 Tools for Visual Studio also automatically installs the WCF RIA Services framework for you.  This release the RIA Services team also has a toolkit of their own.  After installing the RIA Services Toolkit you’ll get:

  • LinqToSql DomainService
  • SOAP endpoint – enabling exposing a SOAP endpoint for your DomainService
  • JSON endpoint – enabling exposing a JSON endpoint for your DomainService
  • ASP.NET DomainDataSource – enabling your ASP.NET application to talk to your DomainService

This is a separate install that you must complete.  For more details on this toolkit, visit Deepesh’s blog.

If you aren’t familiar with WCF RIA Services, you can view an introductory video here.

^ back to top


It’s been a fast pace since getting the Silverlight 4 beta in your hands in November.  We’ve had a lot of work to do to finish things up and implement some new key features.  We are very excited about this release of Silverlight 4 for developers and look forward to seeing the great applications you build with it!

Be sure to visit the MIX10 site for video recordings of various Silverlight-related presentations as the event is happening and as reference later on!  I really encourage you to view the keynote to see some new consumer-facing application experiences built on Silverlight, like eBay, Associated Press (Windows Phone 7)

Hope this helps!  Be sure to subscribe here via RSS or email and if you’re on Twitter you can follow me there as well for Silverlight updates/resources

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