Silverlight Tutorial

Debugging, Testing, and Deploying Silverlight Applications

Error Handling Overview

When writing programming language code, it is vital that you plan to handle any potential errors that could occur when the application is running. Although an application may function perfectly when used by a developer in a development environment, there are countless errors that could occur in an application once it is deployed. An application being used by its developer in its development environment is an optimal scenario. However, once an application is deployed, there's no way to calculate how a user may attempt to utilize an application and what other applications installed on the client machine or resource factors may affect the application performance.

As a result, most programming languages include facilities for handling errors if they occur. Errors generally occur when an application is dependent upon something controlled or provided externally. For example, a user may provide invalid data to an application or an attempt to connect to a database or a resource may fail if the database or resource is unavailable. Error handling code should be placed in code at any point where an error could possible occur.

There are three categories of application errors: compilation errors, runtime errors, and logic errors. Compilation errors typically occur due to syntax errors in code and are called compilation errors because they are caught during application compilation. Since an application won't compile while compilation errors exist, they are corrected before an application is deployed to users. A runtime error is an error that only occurs at runtime, such as the example given above where a database is not available when an attempt is made to connect to it. Finally, a logic error is generally the most difficult to identify and is an error that may not cause an application to stop executing but may cause an application to produce unexpected results. For example, you may have a Boolean expression in an if statement in code that is used to determine if a user should have permission to execute a piece of code. If the Boolean expression is checking for false when it should be checking for true, the result will be the opposite of what is expected but the behavior may not cause an error to occur.

Most .NET-compliant programming languages provide Try, Catch, and Finally blocks. JavaScript also provides try, catch, and finally blocks. When code inside a try block encounters an error, application execution stops and the application begins searching for a catch block that is designed to handle the type of error that occurred. When it finds one, it executes the code in the catch block. A finally block is optional but is used to provide code that is executed whether the code in the try block executes successfully or not. A finally block generally includes clean up code.

Global Error Handler

When you create a Silverlight application using the Visual Studio Project Template, a special file named App.xaml is added to the project for you. App.xaml can contain application-wide resources such as style information. There is also a code-behind file, named App.xaml.cs, which is particularly useful for error handling in Silverlight applications.

App.xaml.cs contains an event handler named Application_UnhandledException which will be executed whenever an unhandled error occurs in the Silverlight application. You can think of this as a global event handler, show the user a friendly, generic, error message or dialog within this event. You may also want to log the error details within this event so it will be easier to debug later.

Debugging and Testing

Debugging and testing code written in a Silverlight application is fairly straightforward and may occur in one of two given scenarios. The first scenario is a Silverlight application that executes only on the client while the second is a Silverlight application that makes calls to a Web service. Previous modules have covered thoroughly how to setup and configure the environment for testing a Silverlight application that calls a Web service by using Visual Studio 2008.

The Visual Studio 2008 debugger is incredibly powerful and one of the leading, if not the leading, debugger in the industry and includes more features than most developers will ever make use of. However, the simplest and most useful feature of the debugger is the ability to set breakpoints in code. When a breakpoint is set in code and execution of code encounters the breakpoint, execution halts at that point and every facet of code execution can be analyzed in depth. In the figure below, the Visual Studio 2008 debugger is displayed with a breakpoint set in the example used in the previous module.

An application goes through several levels and rounds of testing prior to being released to users in a production environment. In fact, just as application security should be considered early on and a formal security plan should be created during the planning phase of the application design cycle, a formal testing plan should also be created. The testing plan will document the levels of testing that should be performed on an application and who will be performing the testing. The various levels of testing include unit testing, regression testing, load testing, and integration testing.

Deploying

Once an application has been fully tested and is confirmed to be stable, the application is ready to be deployed. Deployment is the process of installing the application and configuring it for production use. Deployment may consist of simply copying the application files to a production location or may consist of creating an installation program that users can download and install. A formal deployment plan should also be created during the planning phase of the application design cycle.

In most cases, a Silverlight application simply needs to be copied to a Web server where users can access it over the Web.

Windows Live Silverlight Streaming Service

In an effort to support Silverlight developers and designers, Microsoft created a space online to host Silverlight applications under the Windows Live suite of tools and services. The Windows Live Silverlight Streaming service is free to use and is located at http://silverlight.live.com/.

The Windows Live Silverlight Streaming Service home page is shown in the figure below.

Uploading Applications to the Silverlight Streaming Service

The first step in the process of utilizing the Silverlight Streaming Service is to obtain an account id and account key. To obtain an account with the Silverlight Streaming Service, you'll need a Windows Live ID. If you have one, you can simply login to the Silverlight Streaming Service and generate your account id and key. If you do not have a Windows Live ID, you can sign up for one at the streaming service Web site. The figure below shows the key generation page.

Once you have obtained an account id and account key, you are ready to prepare your application for upload to the service. The Silverlight Streaming Service was very cumbersome to use in its infancy, however using the service is now straightforward and simple and there is not much preparation necessary.

The basic steps of using the service are to create a new application in the service, assign the application a unique name, and upload the Silverlight XAP file for the application. Once a Silverlight application XAP file has been uploaded to the streaming service, a configuration file can be created to direct the streaming service on how it should handle and manage your new Silverlight application. The configuration file is an XML file called the application manifest. In previous versions of the streaming service, the manifest had to be uploaded as part of the deployment process. The streaming service will now create the manifest for you and offers you options to configure the manifest after the XAP file has been uploaded.

A Silverlight application manifest resembles the following markup listing.

<?xml version="1.0" encoding="utf-8" ?>
<SilverlightApp>
 <source>Page.xaml</source>
 <version>1.0</version>
 <width>100%</width>
 <height>100%</height>
 <inplaceInstallPrompt>false</inplaceInstallPrompt>
 <background>#FFFFFF</background>
 <framerate>24</framerate>
 <isWindowless>false</isWindowless>
</SilverlightApp>

Once a Silverlight application is deployed to the streaming service, the service provides a test page and links for using the Silverlight application remotely.

Web Server Deployment

Deploying a Silverlight application to a Web server is also a simple process. The first step in the process is to create a virtual folder for the new Silverlight application to reside in. A Silverlight application may also be an integrated part of another Web application. A Silverlight XAP file typically resides inside a subfolder named ClientBin. Hence, when deploying a Silverlight application, the Silverlight XAP file should reside in the ClientBin subfolder. Additionally, any files or resources that are used by the Silverlight application should be placed relatively in the same location that they existed in the Silverlight project.

As mentioned in the first module, Web server requirements for hosting a Silverlight application are minimal since the server does not process Silverlight but simply downloads it to the client machine for processing. It may be necessary to add the MIME type for .XAP files to the web server, so that XAP files are allowed to be streamed to the client browser.

Lab: Deploying a Silverlight Application

In this lab, you will deploy a Silverlight application to the Windows Live Silverlight Streaming Service.

All material in this Debugging, Testing, and Deploying Silverlight Applications is copyright 2009 Webucator. The purpose of this website is to help you learn Silverlight on your own and use of the website implies your agreement to our Silverlight Tutorial Terms of Service.