Elevated Trust in Silverlight 4

Richard Costall brought us up to speed on getting Silverlight to run beyond the browser, and now he's giving us a crash course in how to use the new Elevated Trust mode available in Silverlight 4 to give your application even more customisations and permissions on your users' machines.

Most people are familiar with how Silverlight behaves within browsers and, In my last article, I covered how you can take a Silverlight application and install it Out-Of-Browser on the local user’s machine in order to access additional functionality, check for updates and manage network connectivity changes. In this article, we’ll be looking at how Silverlight 4 provides us with additional features, with the introduction of Elevated Trust mode.
With Elevated Trust, we gain access to additional local resources, and gain the ability to do much more with our Silverlight application, such as:

  • Apply custom chrome;
  • Directly access selected directories on the file system;
  • Use COM Interop to open up a whole range of features, including;
    • Running windows applications;
    • Integrating with Microsoft Office products;
    • Access to the Windows Speech API.
  • Relaxed user consent on Clipboard, WebCam and Microphone access
  • Full Screen Keyboard support
  • Cross Domain network calls, without the requirement for a Client Access Policy.

I’ve included a demonstration project with this article, which you can download and use to follow along with the code as we go through.

Setting up Elevated Trust

Elevated Trust mode in Silverlight 4 is only available when the application is running Out-of-Browser, and is activated from a checkbox on the Out-of-Browser dialog. You can get to the dialog by right-clicking on the Silverlight project file and selecting Properties from the context menu.


Fig 1. Require Elevated Trust when running outside the browser Option on the Out-of-Browser.

These property settings are stored in the OutOfBrowserSettings.XML file, which actually gets built into the AppManifest file that’s held with the XAP package. In fact, you can even see the elevated trust setting near the end of the OutOfBrowserSettings XML below:

Listing 1. Out-of-Browser XML Configuration in OutOfBrowserSettings.xml


Once you have the Silverlight application, complete with appropriate settings, running in the browser, you can right-click on the application and select the install option. If you compare the resulting dialog between versions of the application running both with (fig. 3) and without (fig. 2) elevated trust, you’ll immediately notice a marked difference.


Fig 2   – Non Elevated Trust Silverlight Application

As you can see below, the install dialog for the Elevated application is a bit more intimidating than the standard one, and you’ll also have noticed our custom icon is missing. To avoid spooking your users with an imposing warning message, a best practice here would be to sign your XAP with a certificate. This is also the only way to ensure an elevated application’s custom icon is displayed.


Fig 3 – Elevated Trust  Silverlight application

With the basics taken care of, let’s take a look at what new functionality you’ll have access to with Elevated Trust.

Custom Chrome

The first feature which we’ll examine is the ability to customise the chrome around the Silverlight application. By default, Out-of-Browser applications use the standard windows chrome, but with Elevated Trust we can now remove the chrome, or remove the chrome and have rounded corners.

The Chrome settings are applied from within the Silverlight Project properties dialog, via the Window Style Dropdown shown at the bottom of Fig 1., and there are three relatively self-explanatory options available.
Default mode uses the standard windows chrome around the application (fig 4.).


Fig 4 – Default Chrome

Borderless mode has no chrome at all (fig. 5), and could be useful if you wanted to create an application to run on something such as a kiosk with a touch screen. On that note, it’s also worth bearing in mind that Silverlight now provides full keyboard support for Elevated Trust applications that are running in full screen mode.


Fig 5 – Borderless Chrome

Borderless Rounded Corners mode allows us to subtly change the aesthetics of our application, by applying rounded corners to it, although unfortunately there’s no configuration setting to change the roundedness of the corners.


Fig 6 – Borderless Rounded Corners

Having these options is, at face value, excellent, but when you run the application in anything other than the Default mode, you’ll soon notice a shortcoming with this approach: The lack of chrome restricts you from resizing, minimizing, or moving the window. This is not really the best user experience, and it’s something we’ll now move on to address.

To start, let’s now add the ability to drag the window around the screen.


Fig 7 – Out Custom Chrome Title Bar

To make it easier for the user to move the application window around the screen, we can add in a title bar, which will act as a grab handle on the application. When the user clicks on the Border in the XAML sample below, the MouseLeftButtonDown event will be handled by our DragWindow handler:

Listing 2 – Our Title bar XAML, with DragWindow Handler

To enable the window to be dragged around the screen, we need to handle the MouseLeftButtonDown event in our code behind:

Listing 3 – With Dragmove, the user can now move the window around the screen.

As you can see, this is an easy problem to fix, but we need to remember that this application can still be run In-Browser, in which case our new title chrome is not required. To cater for this eventuality, I’ve given the Border a name and set it’s visibility property to be collapsed. We can then make the new title bar visible through code, when the application is started up, after checking against the HasElevatedPermissions property which Silverlight provides.

Listing 4 – Code to show the custom chrome when running in Elevated Trust mode.

So, we’ve now got an application that can be dragged around the screen when running Out-of-Browser, complete with custom Chrome. Let’s now extend the functionality of the custom title bar to include Close and Minimize functionality.


Fig 8 – Our Dialog complete with minimize and close controls

Listing 5 – XAML showing our Close and Minimize buttons

The XAML sample above shows the reworked title bar controls, which now include buttons for closing and minimising the application, right-aligned on the title bar itself. You’ll notice I’ve used pre-templated resources for the controls to make them look like traditional Minimize and Close buttons. The xaml for the button templates  is included in the source code.

Listing 6 – Code sample to implement Minimize and Close

As you can see from the code sample above, we can now create handlers for the click events on the buttons. For the Minimize functionality, we simply set the WindowState property to a value from the WindowState enumeration (Valid values are Minimized, Maximized and Normal). For the Close functionality, we simply call Close on the MainWindow. As a side note, Silverlight 4 now has support for the closing event, which allows you to intercept the closing of the application, prompt the user, and potentially stop the close happening (if necessary).

The last task we need to accomplish, to make this application behave like a real Window in the name of usabilty, is to allow the user to resize the application. We’ll do this in our sample application by adding a rectangle in the bottom right hand corner to act as the resizing handle, and colouring it in a subtle bright yellow.


Fig 9 – Implementing a resize handler for our custom chrome

The rectangle will be hidden when run inside the browser (much like the title border), has a handler for MouseLeftButtonDown, and also changes the cursor as appropriate to show that the area is a drag handler.

Listing 7 – Custom Chrome Resize XAML

The code behind handler begins the mouse drag operation for a given WindowResizeEdge. In this instance, we are passing BottomRight from the WindowResizeEdge enumeration:

Listing 8 – Drag Handler for resizing the Chrome


Fig 10 – The Resized Chrome

We now have a Silverlight application with a custom chrome which behaves like a normal window, complete with a title bar and, Close, Mimimize, and Resize functionality. We can also set the Silverlight application to be the top window by setting the TopMost property of the MainWindow object to true.

Local File Access

Let’s now look at another feature of elevated trust mode; the ability to access the local file system. If Silverlight is running within the browser or Out-Of-Browser in normal mode, then file access is limited to usage of the OpenFileDialog and SaveFileDialog controls. In both cases, the user is presented with a prompt to load (or save) a file, and the Silverlight application only has access to the file’s stream containing it’s data, not to the file structure itself.

However, now that we have our application running in Elevated Trust mode, We have full access to selected folders on our users’ machines, namely MyPictures, MyDocuments and MyVideos. What is also special about these folders is that they have equivalents on the MAC, so access to these folders is a cross-platform feature of Silverlight.

While we can only access selected folders, the access to these folders is itself unrestricted; we can create, open and delete files (and directories) with no restrictions on the amount of disk space an application can use.
In our sample application, we’re just going to find the first picture in the MyPictures directory and show it in the application. In Elevated Trust, we can do this without any need to present the user with a dialog for selection or confirmation.


Fig 11 – Automatically loading a picture from the MyPictures folder.

The good news is that working with the My[whatever] folders in Silverlight works the same as in any .NET application. We have access to standard classes such as FileInfo, found in the System.IO namespace, and you’ll need to add a reference to System.IO in order to use these classes:

Listing 9 – Loading a default picture

The above code sample uses a LINQ query to extract the first picture from the MyPictures Special Folder as a FileInfo object. It’s worth noting that the SpecialFolder enumeration contains many values, above and beyond the ‘MY‘ folders. Using any of these other values, such as Program Files or System, will throw a “SecurityException – File Operation Not Permitted” error. Apart from that, Silverlight’s Local File Access gives the developer complete control over a small selection of folders, on both Windows and MAC platforms.

This newfound power opens up a few interesting possibilities in terms of what kind of applications developers can consider building (or rather, building in a way that is user-intuitive). Imagine, for example, a Silverlight picture-editing application; We could use Local File Access to automatically load the thumbnails of all the pictures into the application. The user could then apply effects to a given image, and that image could then be automatically saved back to the MyPictures directory.

COM Interop

This is the part of the article where sirens start going off and lights start flashing. That’s right, it’s time to cover COM Interop.

When running in Elevated Trust, Silverlight has the ability to call COM components, which reside on the local machine. It’s worth noting up front that this feature is emphatically NOT cross platform, and is only supported on the Windows platform. However, this doesn’t stop us from deploying our application to MAC OS/X; we’ll just need to ensure that functionality degrades gracefully when it isn’t supported.

We can easily check for support for COM Interop with the AutomationFactory.IsAvailable property. This is the preferred approach over using System.Environment.OSVersion.Platform, which is used to check for a specific platform:

Listing 10 – Checking if we can use COM Interop or not

Whilst COM Interop can be seen as a controversial feature, it fundamentally opens up Silverlight to a powerful set of functionality which would otherwise be unavailable and, for some people, is seen as an essential part of building rich, interactive business applications. Here’s some examples of things you could do using  COM Interop:

  • Gain full access to the local file system via Scripting.FileSystemObject;
  • Read and Update the windows Registry;
  • Integrate speech into your application using the Windows Speech API;
  • Connect to a Database through ADO, using ADODB.Connection;
  • Directly run applications on the local machine using WScript.Shell;
  • Have your application run on startup of the computer;
  • Integrate your application with the Microsoft Office suite and other applications.

Let’s just take a couple of examples and add them to our application; in the first example, we’ll fire up an instance of Calculator. To do that, we’ll first need to add a reference to Microsoft.CSharp.dll, using the Add References option in the Silverlight project.


Fig 12 – Calling up the Calculator application from Silverlight.

As you can see in Fig. 22 and the code below, I’ve added a button which is only visible if AutomationFactory.IsAvailable is set to true, and wired up the click event to code behind:

Listing 11 – COM Interop sample to run Calculator

We use the CreateObject method to get our instance (in this case of the Windows Scripting Shell Library), and the dynamic keyword allows our object to be late bound and resolved at runtime. The only downside to this process is the lack of any intellisense – once you’ve lost that, you’ll know you’ve entered the world of COM Interop.

As a second example, I wanted to show how we can integrate with Excel and populate some cells:


Fig 13 – COM Interop sample to run and populate Excel

Listing 12 – COM Interop code sample to run Calculator

This process follows the same pattern as the first example, except that it creates an instance of excel, and works with Excel’s object model to populate and calculate cells. If you implement the code in fig. 25 and, once excel has fired up, select a cell and press Ctrl+V, you’ll see that the cells are populated with the text taken from our Silverlight application.

It also rather neatly demonstrates that Silverlight has access to the Clipboard API and, in Elevated trust mode, does not need the user to agree to its usage.

This just scratches for surface of what is possible, and if you’d like to do some further reading, I can recommend a great blog post from Justin Angel, which highlights some of the things you can do with COM Interop.


In this article we’ve covered how Elevated Trust Silverlight applications provide a great degree of configurability for your application, through custom chromes, and window management. We’ve also looked at how we can access the local users file system, before moving on to give an introduction to COM Interop and how to use it.

Now, when you create a Silverlight 4 application, you can choose between In-Browser, Out-Of-Browser, and Elevated Trust. All three have their disadvantages and advantages, but between them they provide an incredibly flexible base for building rich interactive applications to suit almost any situation.

Silverlight 5, the beta of which was released at Microsoft’s Mix11 Conference, takes all of this one step further, bringing Elevated-Trust back inside the browser. We’ll cover this in the next article.

Useful Links

Simple Talk – Beyond the Browser Part 1

John Papa’s Article on signing your XAP package

Justin Angel’s COM Interop Post