Silverlight applications (as a general rule) are downloaded from a server and therefore the server must be able to serve up the application to the client via web server software. In addition (depending on the various needs of your Silverlight application), the application may place additional demands on the server to serve it up data. Let's look at the requirements that your Silverlight application may place on the server, and what it needs installed to meet these needs.

msiexec /i RIAServices.msi SERVER=true

The most primitive means of deploying your application to a server is by copying the required files to the required location (a process often referred to as xcopy, from the old DOS command), and configuring an Application in IIS to point to the folder that these files were copied to.

Copy all the non-code related files from the web project (the HTML file hosting the Silverlight plug-in, any JavaScript files, the web.config file, the ClientBin folder, the Bin folder, and so on.) to a folder on the server. This may be a new folder, or you can add to/update a folder containing an existing web site.

If you are creating a new web site, then you need to configure an Application in IIS. How you go about doing so will largely depend on the version of IIS that it will be running under, and the type of user interface available to you (i.e., either the Internet Information Services Manager, or a web-based user interface). Therefore, we will not go through a step-by-step process for this in detail, but it will follow the same process as configuring an ASP.NET 4 web site.

Visual Studio 2010 provides a feature enabling you to publish a web site in a myriad of ways to a server-both local and remote. Depending on the settings you are using, publishing a web site using Visual Studio will both copy the required files to a server, and create the Application for you in IIS (if it's not already configured). This feature makes it easy to deploy your project from right within Visual Studio.

Start by right-clicking on your web project in the Solution Explorer window, and select the "Package/Publish Settings" item from the context menu. This will open the Package/Publish Web tab in the project properties, and enable you to configure what will be deployed to the server as a part of the publishing process, and where on the server it will be published.

Once you have configured the settings appropriately, right-click on the web project in the Solution Explorer window again, and select the Publish item from the context menu. This will display the Publish Web dialog shown in Figure 15-1.

Figure 15.1. The Publish Web dialog

You can then configure how you want to publish your web site in this dialog, and click the Publish button to start the publishing process. It will copy the files used in your web project (that will include your Silverlight application), and will create the Application in IIS (if you have selected the "Mark as IIS application on destination" option in the Publish Web dialog.

Instead of publishing the web site directly to the server, you can instead create a web package, which is essentially a .zip file containing your web site and configuration files dictating how the web site should be created under IIS on the server. You can then take this package and import it into IIS (either using the Internet Information Services Manager, or via the command line using the msdeploy tool).

To create a package, right-click on your web project in the Solution Explorer window, and select the "Build Deployment Package" item from the context menu. This will immediately compile the web site into a package, using the settings configured in the Package/Publish Web tab in the project properties for the web project.

You can then open up the Internet Information Services Manager and import the package. This will install the files on the server, and create the Application in IIS. Alternatively, if you want to import the package via the command line, you can find instructions on doing so in a text file created in the same folder as the package.

If your application is to be a packaged product sold to companies who then install it on their own server, creating a setup program is the best way to provide it to your customers to install.

Add a new project to your solution, and use the Web Setup Project project template (you will find this under the Other Project Types > Setup and Deployment > Visual Studio Installer category).

In the Solution Explorer window, right-click on the setup project, and select Add

Select the setup project in the Solution Explorer window again, then go to the Properties window and assign values to the properties, as you require. Once you are done, you can compile the project.

You can test the setup program locally by compiling your project, then right-clicking on the setup project in the Solution Explorer window and selecting the Install item from the context menu.

Let's start by taking a look at what happens when the user attempts to run your Silverlight application, but doesn't have Silverlight installed. Let's assume that no version of Silverlight is currently installed on the user's machine, and that they have navigated to the URL for your application. The user will be presented with a blank page, containing the image shown in Figure 15-2.

Figure 15.2. The default image displayed in the browser when Silverlight is not installed

If you view the source of the HTML page that's used in your application to host the Silverlight plug-in (as was detailed back in Chapter 2: Getting Started with Silverlight), you will find the following lines of HTML in its body:

<object data="data:application/x-silverlight-2," type="application/x-silverlight-2"
        width="100%" height="100%">
    <param name="source" value="ClientBin/AdventureWorks.xap"/>
    <param name="onError" value="onSilverlightError" />
    <param name="background" value="white" />
    <param name="minRuntimeVersion" value="4.0.50401.0" />
    <param name="autoUpgrade" value="true" />
    <a href="http://go.microsoft.com/fwlink/?LinkID=149156&v=4.0.50401.0"
                                                    style="text-decoration:none">
        <img src="http://go.microsoft.com/fwlink/?LinkId=161376"
            alt="Get Microsoft Silverlight" style="border-style:none"/>
    </a>
</object>

If the browser does not know what the object is supposed to be (because the Silverlight plug-in hasn't been installed), it will ignore the object tag and simply display the content between the opening and closing object tags instead. The default HTML between the tags (in bold) simply displays the image you see in Figure 15-2, and when it is clicked on will download the Silverlight plug-in from the Microsoft web site.

You will also note the following line in the head section of the HTML file:

<script type="text/javascript" src="Silverlight.js"></script>

This script contains a number of helper functions, such as automatically reloading the page once it recognizes that the Silverlight plug-in is installed, and additional functions to enable you to create a Silverlight object in a web page via JavaScript.

Once the Silverlight runtime has been installed, the page will be automatically refreshed, and the application will begin to download from the server (and be displayed once the download is complete).

You saw in the previous section how easy it was to get set up and running with Silverlight on a clean PC. However, despite the ease that you can deploy your applications using Silverlight, the default experience isn't particularly ideal. Let's take a look at why you should customize the Silverlight installation experience, and how you can do so.

<a href="http://go.microsoft.com/fwlink/?LinkID=149156&v=4.0.50401.0"
                                                    style="text-decoration:none">
        <img src="http://go.microsoft.com/fwlink/?LinkId=161376"
            alt="Get Microsoft Silverlight" style="border-style:none"/>
</a>

One of the issues in deploying the Silverlight runtime (particularly in enterprise environments) is that the user will need to be a local administrator on their machine in order to install the Silverlight plug-in (as is the case with any plug-in). If the user doesn't already have the Silverlight runtime installed on their machine and does not have local administration rights, they won't be able to install the Silverlight plug-in (and hence run your application).

The Silverlight runtime can however be pushed out to users using the Microsoft Systems Management Server automated installation, or by setting up a group policy. Despite being for Silverlight 2.0, the Silverlight Enterprise Deployment whitepaper available from www.silverlight.net/learn/whitepapers/ is a very thorough and detailed guide for methods of deploying Silverlight in enterprise environments.

In Chapter 14: Out Of Browser Mode, and Interacting with the Operating System, we discussed how to install your Silverlight application to run outside the browser, in much the same way as a standard (native) desktop application. In some scenarios, you may find that web deployment of your application is not always suitable or even possible. In this case you will need to have a more traditional setup program that can be run on the client and install the Silverlight application as an out-of-browser application. You can do this using the silent install feature of the Silverlight launcher (sllauncher.exe).

The sllauncher.exe application accepts various command-line parameters, which can be used to install/uninstall/run a Silverlight application.

If you type the following line on the command line:

"%ProgramFiles%Microsoft Silverlightsllauncher.exe"

It will display the message box shown in Figure 15-3.

Figure 15.3. The SLLauncher command-line parameters dialog

This tells you what command-line parameters you can take advantage of to enable us to install the application on the machine. Of particular interest are the following options:

An example of installing an application using these options is below:

"%ProgramFiles%Microsoft Silverlightsllauncher.exe" /install:"AdventureWorks.xap" 

/origin:"http://localhost/AdventureWorks.xap" /shortcut:desktop+startmenu /overwrite

You can take advantage of this silent install feature in your own setup programs by adding the .xap file from your Silverlight project to your setup project, and creating a custom action to extract your .xap file to a temporary location and running sllauncher.exe with the appropriate command-line parameters to install it. A full explanation of this procedure however is beyond the scope of this book. Alternatively, a somewhat simpler option may be to deploy a batch file along with the application, which when executed, will install the application using the method described here.

To create your pre-loader, start by adding a new item to your web project, using the Silverlight 1.0 JScript Page item template (found in the Silverlight category), and name it AppPreloader.xaml. This template will actually create two files-a XAML file (with the name you specified in the Add New Item window), and a JavaScript file (with the same name as the XAML file, but with a .js extension).

Once the file has been created and opened, you'll note that there is no XAML designer support. However, if you close the file and open it again, the designer will appear (but will display an error due to it not supporting the referenced default namespace used by Silverlight 1.0).

Delete the contents of both the XAML file and the JavaScript file, as it's just the files you need-not their contents. You will be using a different default namespace than that used in the XAML file created for us, and trying to use the default namespace from the item template will end up just creating problems and confusion for you. Likewise, none of the contents of the JavaScript file are required-you'll add your own code shortly.

Now add the following XAML to the XAML file:

<Grid xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

</Grid>

Click the "Reload the designer" button in the designer. Attempting to compile the solution now will result in the following error: "Project file must include the .NET Framework assembly 'WindowsBase, PresentationCore, PresentationFramework' in the reference list". With the designer open now, you can have these references automatically added to your project by simply dragging a TextBox from the Toolbox into the designer. Alternatively you can simply type an open angle bracket (<) in the XAML editor (with the designer open), which will have the same effect. You should now be able to successfully compile the project.

Now that you have the required files properly configured, you can start adding the content you want to display in the pre-loader. One of the most important points when creating a pre-loader is to try and keep it very small. As a general rule, try to keep it less than 5 percent of your application's total size, and no more than 10KB so that it can download and be displayed to the user as quickly as possible, even on slow connections.

Almost all pre-loaders display an indicator to the user showing the current progress of the application download. This enables the user to be aware that something is actually happening, and how much longer it may take. The Silverlight plug-in raises an event at a regular interval (that you can handle in the JavaScript file), reporting the current progress of the application download. The pre-loader should also display some branding for both the company and the application (one of the main reasons for undertaking this exercise).

Figure 15-5 demonstrates the pre-loader you will be creating.

Figure 15.5. The custom pre-loader

As you can see, it displays an image with the company logo, tells the user what it's doing, and displays a progress bar and the progress as a percentage. The XAML required to create this pre-loader is below:

<Grid xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <StackPanel VerticalAlignment="Center">
        <Image Width="352" Height="111" Source="../Logo.png" />
        <TextBlock HorizontalAlignment="Center" Margin="0,10,0,5"
                   Text="Please wait - downloading..." />
        <Grid HorizontalAlignment="Center">
            <Rectangle Stroke="#FF5F91B4" Height="7" Width="454" />
            <Rectangle Fill="#FF5F91B4" Margin="2,0,0,0"
                    Height="3" Width="450" HorizontalAlignment="Left">
                <Rectangle.RenderTransform>
                    <TransformGroup>
                        <ScaleTransform x:Name="ProgressBarTransform" ScaleX="1"/>
                    </TransformGroup>
                </Rectangle.RenderTransform>
            </Rectangle>
        </Grid>

        <TextBlock Name="ProgressText" Text="0%"
                   HorizontalAlignment="Center" Margin="0,0,0,5" />
    </StackPanel>
</Grid>

Unfortunately the ProgressBar control isn't available for us to at this stage (as it's not in the core Silverlight runtime), so you need to create your own using the primitive controls available to us. You have a rectangle that forms the outer border of the progress bar, and an inner rectangle that is used as the progress indicator. The trick for this is that you create the progress indicator rectangle setting its width as it will be when displaying a value of 100 percent, but apply a scale transform that will be used to scale its width in proportion to the progress value it is indicating. By altering the transform's ScaleX property with values between 0 and 1 (in JavaScript code), you will be able to display the progress from 0 percent to 100 percent accordingly-providing an elegant way to implement the progress bar without needing to worry about calculating the required width in pixels in the JavaScript code. You've given the transform a name so you can refer to it in the code and adjust the scale accordingly (as you will see in the next section).

You will also note the use of the Image control. The Logo.png file it refers to is a file in the web project, and you are using a relative path to specify its location. Don't be concerned about the fact that the image doesn't appear in the XAML designer-it may not appear there, but it will appear when the pre-loader is being displayed at runtime.

Now that you have the visual aspects of your application pre-loader in place, you need to update the progress being displayed. This involves updating both the progress bar indicator's scale transform, and the text displaying the progress as a percentage

The Silverlight plug-in has two events it raises that you can handle:

The OnSourceDownloadProgressChanged event will be raised on a regular basis, and you can use the progress property of the EventArgs object passed into the handler as a parameter to determine the progress. This will be a value between 0 and 1, so you can assign this value directly to the ScaleX property of the progress bar indicator's scale transform, and multiply it by 100 to display the value as a percentage.

The code below should be added to your JavaScript file in order to update the pre-loader when the onSourceDownloadProgressChanged event is raised:

function onSourceDownloadProgressChanged(sender, eventArgs) {
    var progress = Math.round((eventArgs.progress * 100));
    var ProgressBarTransform = sender.findName("ProgressBarTransform");
    var ProgressText = sender.findName("ProgressText");

    if (ProgressBarTransform != null)
        ProgressBarTransform.ScaleX = eventArgs.progress;

    if (ProgressText != null)
        ProgressText.Text = progress + "%";
}

The OnSourceDownloadComplete event is called once the application has completed downloading but is rarely used, as the application will load immediately after it's raised.

You now have your application pre-loader's design in place, and the code to update it when the application download progress changes, but now you need to actually wire both of these things up so that the Silverlight plug-in knows about them.

Start by opening up the HTML page that hosts the Silverlight plug-in. In the head tag, add the following reference to the JavaScript file:

<script type="text/javascript" src="AppPreloader.js"></script>

Now locate the Silverlight plug-in, and add the following two parameters to it:

<param name="splashscreensource" value="AppPreloader.xaml"/>
<param name="onSourceDownloadProgressChanged"
       value="onSourceDownloadProgressChanged" />

These two parameters connect everything together, and you're now ready to test it all.

Testing the application pre-loader may initially seem like a simple enough task, however it's a deceptively complex process. The issue is that when running your application locally, the download process will generally be extremely fast, and the pre-loader will not have time to actually be displayed (or will be displayed only momentarily). This obviously makes it difficult to test and debug. However, there are some tricks you can use to slow its display down. Let's take a look at some of these.

this.InitializeRootVisual();

Using Fiddler

Fiddler is a web debugging proxy that intercepts all incoming and outgoing HTTP/HTTPS connections, enabling you to log and modify the traffic. You can use Fiddler to slow down the downloading of the application, giving us time to view and test the pre-loader.

Note

You can download Fiddler for free from www.fiddler2.com

When you open Fiddler, it will immediately start capturing the traffic. Select both the Simulate Modem Speeds and the Disable Caching options from the Rules

Unfortunately, simply running your application is not enough for this all to work. Fiddler bypasses capturing local traffic, but there is a trick that you can use to ensure that it intercepts your application. Change the use of "localhost" in the URL in your browser's address bar to "127.0.0.1." (the localhost loopback IP address, including the final dot). This will trick Fiddler into capturing the traffic, and you will find that the application now downloads slowly enough for you to adequately test your pre-loader. Once the application has loaded, you can simply refresh the page to have it downloaded again (as it will not be cached).

The first step you should take is to look at the size of your .xap file and decide on how acceptable its size is. You may want to use the feature of Fiddler, discussed previously, to simulate modem speeds in order to determine how acceptable the time it takes to download may be to various users.

The next step is to ensure you aren't referencing any assemblies or assets not actually being used by your application. If your .xap file is still large then it may be worth analyzing its contents (by changing its extension to .zip and unzipping it, as discussed previously in Chapter 2: Getting Started with Silverlight). Look for the largest files and determine if you can remove them or replace them with a suitable alternative.

One thing that you can do to partition you application into smaller pieces is to turn on assembly caching for your application. You will find this in the "Reduce XAP size by using application library caching" option in the project properties for your Silverlight project. What this will do is instead of creating a single large .xap file containing all the assemblies required by your application (that aren't a part of the core Silverlight runtime), it will move all the assemblies (that have an accompanying extension mapping configuration file, discussed shortly) out of this file and into separate .zip files, as you can see in Figure 15-6.

Figure 15.6. The ClientBin folder when using assembly caching

<?xml version="1.0"?>
<manifest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <assembly>
    <name>System.Windows.Data</name>
    <version>2.0.5.0</version>
    <publickeytoken>31bf3856ad364e35</publickeytoken>
    <relpath>System.Windows.Data.dll</relpath>
    <extension downloadUri="System.Windows.Data.zip" />
  </assembly>
</manifest>

Enabling Your Own Assemblies to be Cached

If you inspect your .xap file's contents (by changing its extension to .zip and unzipping it, as discussed previously in Chapter 2: Getting Started with Silverlight), you may find that not all the assemblies have been packaged as external parts (excluding the core assembly for the application), and are still packaged in your .xap file-particularly assemblies that you created yourself. In order for an assembly to be cached, it must be signed with a strong name, and have an external part manifest file (as described in the previous section).

To sign your assembly with a strong name, open up the project properties for the project, and open the Signing tab. Select the "Sign the assembly" check box (as seen in Figure 15-7), select <New...> from the drop-down list, and enter a name and password for the strong name key file in the dialog that appears. The next time your application is compiled it will then be signed.

Figure 15.7. Configuring the strong name for the assembly

The next step is to create the external part manifest file. The easiest way to create this is to use the DevCorner ExtMap Maker Utility tool created by Alex Golesh, which you can download from http://blogs.microsoft.co.il/blogs/alex_golesh/archive/2009/07/16/small-utility-extmap-maker.aspx. This is a command-line utility that you can point to your assembly (passing the path to the assembly as its command-line parameter), and it will create a corresponding external part manifest file for you in the same path as the assembly is located. For example:

emm MyControlLibrary.dll

Put this in the binDebug and binRelease folders of your assembly before adding the reference to it to your Silverlight application, and then recompile the Silverlight application. You will find that the assembly is now created as a separate package for download.

Another way you can partition your application is by breaking it up into modules, each in their own assembly. These can be excluded from the main .xap package (minimizing the size of your main application), and downloaded only when (and if) they are required. For example, you may like to have separate modules for each functional area in your application, where users may only have permission to access one or two of those functional areas. Likewise, you may like to split the administrative functionality into another module, as only a subset of users will be permitted access to it.

There are a number of ways to modularize your application, and the method you decide to use will often depend on if you want to use a framework or not. Let's start by discussing some of the options available to you, and then look at implementing a simple means of modularizing your application.

You need to start by making a decision on whether you are prepared to use an existing framework in order to modularize your application, or create your own custom solution. Incorporating a framework can provide many benefits (in addition to the modularization), however it may also impose on the structure and design of your application-which, depending on the stage you are at in your development process, may or may not be an issue. They can also introduce additional complexity into your application and incur a significant learning curve. It will depend on the nature of both your application and your team as to whether you are prepared to undertake this process.

The most popular frameworks for implementing modularization in Silverlight applications include Prism and the Managed Extensibility Framework (MEF).