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.

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. However, deploying to the streaming service can be slightly more complex than simply performing an upload; an application must be slightly converted so that it is ready to function with the streaming service.

The first step of the process is to modify any pages that load Silverlight and that include a reference to the Silverlight.js script that checks for Silverlight prerequisites. By default, this script is located in the local project but a streaming application should pull it from a location online. The script reference element initially reads

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

but it needs to be updated to

<script type="text/javascript" src="http://agappdom.net/h/silverlight.js"></script>

Next, the code behind files for any HTML files modified above need to be modified as well. These files will contain a function called createSilverlight. The function originally reads

{Silverlight.createObjectEx({ source: "Page.xaml",
    parentElement: document.getElementById("SilverlightControlHost"),
    id: "SilverlightControl", properties: { width: "100%", height:
    "100%", version: "1.1", enableHtmlAccess: "true" }, events: {}}

but it needs to be updated to

function createSilverlight()
{
    Silverlight.createHostedObjectEx({
        source: "streaming:/19178/MyFantasyPicks",
        parentElement: document.getElementById("SilverlightControlHost"),
        id: "SilverlightControl"
       });
}

The new version pulls your Silverlight application from the streaming service by using your key and also eliminates any additional parameters as those will be moved to a new location, the application manifest. Add a new XML file to the project and name it "manifest.xml". The contents of the manifest.xml file should resemble the following XML 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>

In the listing above, the grammar and case are important. The markup states that the first XAML file that will run is the Page.xaml file and that the height and width of the Silverlight application should be 100% each. The manifest is used by the streaming service to determine how to load and run your application.

The next step of the process is to create a zip file that contains the heart of the Silverlight application. To create the zip file, right-click on the project in the Solution Explorer and select Open Folder in Windows Explorer. Create a new zip file at this location and add the Page.xaml file, the manifest.xml file, and the project assembly (from the ClientBin folder) to the zip file.

When the zip file is created, the application is ready to be uploaded. Open the streaming service home page and select Manage Applications. Select the option to Upload a Silverlight Application. On the presented page, assign the application a name, select the zip file created above as the file to upload, and click Upload. Once the upload is complete, an application summary page is displayed with options for testing and running the application. The sample test page should resemble the following figure.

Finally, there are options on the same page to test the application. The application can be tested by simply creating a new HTML page with the provided script and markup.

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 Silverlight Tutorial is copyright © 2008 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.