Silverlight is a browser plug-in that enables browser-based applications to display rich, XAML-based UIs, execute managed code, and leverage the .NET Framework Base Class Library. Thus it may come as a surprise to some that in Silverlight 3, applications are no longer restricted to the browser.
Silverlight applications that run outside the browser are commonly referred to as out-of-browser applications, or OOBs for short. You install an OOB by running a Silverlight application in your browser, right-clicking the Silverlight control, and selecting “Install appname onto this computer” from the context menu. A dialog box like the one below appears and offers to place a shortcut for the app on the desktop, in the Start menu, or both. If you click OK, the app is installed locally on the host PC.
When executed, an OOB application starts up in a window of its own (not a browser window) and is hosted in a process named sllauncher.exe (the “Microsoft Silverlight Offline Launcher”). As the name implies, an OOB doesn’t require an online connection; it launches locally, just like any app installed on your computer. However, if a connection is available, an OOB goes back to the server the moment it’s launched to check for updates. If an update is available, an event fires so the app can notify the user that a newer version is available. The newer version is automatically downloaded and then executed the next time the OOB is started. In Beta 1, there is no option for declining the update, but don’t be surprised if that changes in a future release.
Those are the basics; now here are some of the details. First, there is one step that you, the developer, must take if you wish for your application to support being installed locally and run out-of-browser. That step involves a change to the application manifest, which is generated from the AppManifest.xml file in your Silverlight project. Here’s an AppManifest.xml that supports OOBs:
<Deployment xmlns=“http://schemas.microsoft.com/client/2007/deployment“
xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml>
<Deployment.Parts>
</Deployment.Parts>
<Deployment.ApplicationIdentity>
<ApplicationIdentity
ShortName=“SLOOB“
Title=“Silverlight OOB Demo“>
<ApplicationIdentity.Blurb>
<!– Insert description here –>
</ApplicationIdentity.Blurb>
<ApplicationIdentity.Icons>
<Icon Size=“16×16“>Icons/Icon16.png</Icon>
<Icon Size=“32×32“>Icons/Icon32.png</Icon>
<Icon Size=“48×48“>Icons/Icon48.png</Icon>
<Icon Size=“128×128“>Icons/Icon128.png</Icon>
</ApplicationIdentity.Icons>
</ApplicationIdentity>
</Deployment.ApplicationIdentity>
</Deployment>
Note the new <Deployment.ApplicationIdentity> section, which contains key information used when a Silverlight app is installed locally, including:
-
The short name, which appears in the shortcuts created for the OOB
-
The title, which appears in the title bar of the window that hosts the OOB
-
The blurb, which provides a more detailed description of the OOB
-
An optional set of application icons in varying resolutions used in shortcuts, in the title bar, and in the Install Application dialog. If you don’t provide icons, a set of default icons is provided for you. Note that when you add the icons to your Silverlight project, you must change their build action from “Resource” to “Content” so they’re packaged in the XAP file as loose resources.
It is the presence of an <ApplicationIdentity> element that prompts Silverlight to include an option for installing an app locally in the right-click context menu.
There are two ways that a Silverlight app can be installed locally. First, the user can right-click the Silverlight control and select “Install appname onto this computer.” Second, the application itself can call the new Application.Detach method:
Application.Current.Detach();
Detach displays the same Install Application dialog as the “Install appname” menu item and returns a bool indicating whether the application was successfully detached–that is, installed locally. Detach fails if the app has already been installed locally, if OOB support hasn’t been enabled through the application manifest, or if the user cancels the install. It also fails if it wasn’t called in response to a user action such as a button click.
Since an OOB application can be launched even if there is no network connection available, it might want to determine at run-time whether it’s running in a connected or disconnected state. There’s no sense in trying to call a Web service, for example, if you’re not even connected to the Internet. One simple call is sufficient to determine whether a network connection is currently available:
if (NetworkInterface.GetIsNetworkAvailable())
{
// App is connected
}
else
{
// App is not connected
}
The NetworkInterface class is new in Silverlight 3; it belongs to the System.Net.NetworkInformation namespace. Another System.Net.NetworkInformation class is NetworkChange, which, through its NetworkAddressChanged event, notifies interested parties when the network status changes–for example, when a network connection becomes available or goes away:
NetworkChange.NetworkAddressChanged += Network_NetworkAddressChanged;
…
void Network_NetworkAddressChanged(object sender, EventArgs e)
{
if (NetworkInterface.GetIsNetworkAvailable())
{
// App is connected
}
else
{
// App is not connected
}
<
p class=”MsoNormal”>}
These calls work in Silverlight apps hosted in the browser, too. And they’re useful in both places. An application running offline could, for example, elect to store data locally in isolated storage rather than submit the data to a service if it finds it has no network connection. Incidentally, the moment an application is detached, its isolated storage quota is automatically increased to 25 MB in Beta 1. This affects both the detached version of the app and instances of the app hosted in a browser.
Can an application that has been detached determine at run-time whether it was launched or in a browser or in a stand-alone window? You bet:
if (Application.Current.RunningOffline)
{
// Launched in sllauncher.exe
}
else
{
// Launched in a browser
}
The new Application.RunningOffline property returns true or false indicating whether the app was launched in a browser (false) or in a separate window (true). This is useful because some Silverlight features that are available to browser-based application instances aren’t available to OOB instances. HTML DOM support is one such feature. An OOB app can’t interrogate the browser DOM or call JavaScript functions because outside of a browser, these features do not exist. In Beta 1, an application running outside the browser has limited control over the environment in which it is executing. It cannot, for example, change the size of the window in which it is hosted. This may change before final release in response to feedback from developers.
One final tidbit regarding out-of-browser applications is that the Application class now exposes a public property named ExecutionState. Among other things, this property can be used to determine whether an updated version of an app launched outside the browser is available. Each time an app is launched outside the browser, it sends a request to the server to determine whether a new XAP file is available. If the answer is yes, the XAP is automatically downloaded. (Again, in Beta 1, there is not an option for declining the update). The new version isn’t executed automatically; instead, it’s executed the next time the app is started outside the browser. An OOB can use the new Application.ExecutionStateChanged event to learn when a newer version is available and prompt the user to restart the app to launch the new version:
Application.Current.ExecutionStateChanged += Application_ExecutionStateChanged;
…
void Application_ExecutionStateChanged(object sender, EventArgs e)
{
if (Application.Current.ExecutionState ==
ExecutionStates.DetachedUpdatesAvailable)
MessageBox.Show(“An updated version of this application is available. ” +
“Close the application and restart it to run the new version.”);
}
I have been mostly unsuccessful in getting the automatic update feature to work in Beta 1, but I suppose that’s why they call it a beta.
For more on Silverlight 3’s out-of-browser application support, see Tim Heuer’s excellent blog post on the subject.