In the unlikely event that you don’t know about Silverlight, it’s a web-based technology that allows designers and developers to deliver Rich Internet Applications (RIA) embedded in web pages. It is a cross-browser, cross-platform RIA framework, which provides a consistent user experience everywhere it runs. The architecture of Silverlight projects, and the deployment of a stripped-down version of the .NET CLR, are what make this possible, and what I’ll be look at here.

In this article, I will give you an overview of how web browsers render Silverlight applications, and identify which are the main components involved in the execution of said Silverlight applications. Armed with this information, you’ll have a much better sense of what’s going on inside your Silverlight projects, and will better able to troubleshoot basic rendering problems.

To start, let’s create a sample Silverlight application; open the Visual Studio 2010 IDE, go to the File > New Project menu item, and pick the Silverlight Application template from the available options.

Figure 1. Starting a new Silverlight Application project.

After clicking on OK, the New Silverlight Application dialog box will pop up, as shown below:

Figure 2. Configuring the new Silverlight project.

At this stage, and for the purposes of this article, you can opt for an ASP.NET Web project to be created in our solution. This ASP.NET Web project will, in turn, host the Silverlight Application (which will be installed on the client machine) within it. Given that we’ll be looking at the browser-based Silverlight project architecture, this dual-solution option will be the focus of this article. Now let’s click on OK, and you will see two projects are created, as shown below:

Figure 3. The new, and empty, Silverlight Projects.

You will see that two projects are created:

SilverlightApplication

This is the actual Silverlight application. By default, a newly created Silverlight application project contains a MainPage.xaml and App.xaml file. The App.xaml file is used to declare resources like brush and style objects, which are shared across the application. There is also a code behind file (App.xaml.cs) associated with it, which can be used to handle application level events, such as Application_Startup, Application_Exit, and so on. When we build this project, Visual Studio will compile this project into a .xap file and, if you look inside the “ClientBin” folder in the “SilverlightApplication.web” web application, you will see a SilverlightApplication.xap file. That’s the end result of having built the SilverlightApplication project, and I will explain the importance of the .xap file in more detail later in the article.

Silverlight Applications can be used with any web-server, including Apache on Linux, and can be hosted within static HTML files or any server side generated page, like PHP, Java, and so on. Sticking to the theme of cross-platform compatibility, you don’t even need the full .NET framework installed on the client machine in order to run Silverlight applications; you only need the Silverlight plug-in to be installed (and I’ll also explain why that is later).

SilverlightApplication.Web

This is the ASP.NET web application I mentioned earlier, and you’ll see that Visual Studio has generated .html and .aspx pages to host your Silverlight controls.

Let’s look at the files which are created in a “SilverlightApplication.Web” application:

1) SilverlightApplicationTestPage.html:

If you open this html page and scroll all the way down, you will see an <object> tag which looks similar to the following:

The data and type attributes in the <object> tag represent the Silverlight browser plug-in and MIME type (application/x-silverlight-2 in this case), which the browser uses to load and instantiate appropriate plug-ins. If browser doesn’t find the Silverlight plug-in installed, it will present the following message (see Figure 4) using the anchor tag inside the <object> tag, and clicking on this button will download the Silverlight plug-in. You can also customize this default message by modifying the anchor tag in the code seen above.

Figure 4. The message presented when the Silverlight plug-in is not found.

There are number of parameters and possible values specified within the <object> tag, so let’s take a look at them now:

• <param id=”quot;source”” value=”ClientBin/SilverlightApplication.xap”/> – The Source parameter specifies the file path which the browser plug-in will download the application from.  In our case, the browser will download the SilverlightApplication.xap file located in the ClientBin folder of the web application.
• <param id=”quot;onerror”” value=”onSilverlightError”/>  – onSilverlightError is the name of the function that will be called when the Silverlight plug-in generates an XAML parse error or run-time error at the native code level.
• <param id=”quot;minRuntimeVersion”” value=”4.0.50401.0″/>  – The value of this parameter represent the version of Silverlight plug-in required to run the given Silverlight application – 4.0.50401.0 in this case.  If the browser doesn’t find the plug-in version specified here, it will ask the user to perform an upgrade.
• <param id=”quot;autoUpgrade”” value=”true”/> – This setting has no effect if you don’t have a minRuntimeVersion specified. If the value is set to true and the Silverlight plug-in version found is earlier than the minRuntimeVersion, then the browser will attempt to update automatically.

2) SilverlightApplicationTestPage.aspx:

This page contains the same <object> tag which we have just seen in SilverlightApplicationTestPage.html. Both the HTML and ASPX pages are just the default pages to host your project for test purposes, and can later be removed from the project.

3) Silverlight.js:

You may have noticed that there is a JavaScript file(Silverlight.js) reference in the <head> tag of both the SilverlightApplicationTestPage.aspx and SilverlightApplicationTestPage.html pages:

Silverlight.js is a helper file used when adding a Silverlight application to a webpage via Javascript. It has a number of methods, but the most important are createObject and createObjectEx, which are used to instantiate Silverlight.

While we’re on the topic, there are two ways to embed a Silverlight plug-in into your web page:

1) Using the HTML object element

This is the simplest way to embed the Silverlight plug-in and also the default approach used by Visual Studio when you choose to host your Silverlight application in a web page. You can see the HTML object element in the SilverlightAppilcationTestPage.html and SilverlightApplicationTestPage.aspx files.

2) Using the Silverlight.js file.

You can also embed the Silverlight plug-in in a web page dynamically using the createObject and createObjectEx functions defined in the JavaScript file. The Silverlight.js file, and the dynamic approach, is particularly useful when it comes to improving the standard Silverlight installation or upgrade experiences.

4) SilverlightApplication.xap:

The Silverlight application is packaged into this file. When you build your SilverlightApplication project, Visual studio generates the application package (SilverlightApplication.xap) in the ClientBin folder of the SilverlightApplication.Web application. This .xap file is similar to a .zip file and, if you don’t believe me, you can prove it to yourself by renaming it as a .zip file and extracting its contents. In the application package, you’ll see following two files:

• SilverlightApplication.dll
• AppManifest.xaml

SilverlightApplication.dll is the Silverlight application assembly, and AppManifest.xaml is the application manifest file, which contains information such as what DLLs are present in this package and which DLL contains the entry point. If you’re curious, you’ll see something like the following in the AppManifest.xaml file:

The Silverlight CLR (and if that term raise questions in your mind, I’ll explain it shortly) reads this file to load the SilverlightApplication assembly (specified by the EntryPointAssembly attribute), which is located in the SilverlightApp.dll file (specified in <Deployment.Parts>), and then create an instance of the SilverlightApplication.App class (as specified in the EntryPointType attribute).

I think we’ve got enough information about the files that get created in a Silverlight web application, but before we get started, there’s one last element I want to introduce: The Silverlight CLR.

CoreCLR

I’ll mention the Silverlight Common Language Runtime in a moment, so let’s take a closer look at it before we get started. In a nutshell, CoreCLR (or Silverlight CLR) is the Silverlight version of the CLR that runs inside the Silverlight plug-in, and is located in C:\Program Files\Microsoft Silverlight\ 4.0.50401.0\. CoreCLR is similar to the full .NET CLR , but is much smaller and only has the features necessary to manage Silverlight applications in a browser environment.

Figure 5. The In-Browser Silverlight environment (Diagram from MSDN article)

As you can see in Figure 5, the Silverlight control runs in a managed environment (the Silverlight CLR), which in turn runs within the context of the browser plug-in, which runs inside the context of the browser.

So now let’s look at the execution cycle of a Silverlight application and the roles of those components we’ve just discussed.

The Step by Step Execution

1. The client (user) requests the SilverlightApplicationTestPage.html or SilverlightApplicationTestPage.aspx web page. Let’s assume that the test page is stored somewhere on a web server.
2. The SilverlightApplicationTestPage.html page gets downloaded from the web server to the client, and the browser starts rendering the html page.
3. While rendering SilverlightApplicationTestPage.html page, the browser sees the <object> tag, and uses the value of the tag’s type attribute to figure out what plug-in it needs to load. In our case, the value of type attribute is application/x-silverlight-2, which is the MIME type which maps to npctrl.dll, located in C:\Program Files\Microsoft Silverlight\4.0.50401.0\. This MIME type, application/x-silverlight-2, is used for Silverlight version 2 and upwards. There is a registry entry named AgControl.AgControl.4.0 that associates with that MIME type.

   

   Figure 6. The registry entry, AgControl.AgControl.4.0, associated with the application/x-silverlight-2 MIME type.

4. Once the plug-in has been loaded, it starts up the Silverlight common language runtime and starts downloading the SilverlightApplication.xap file from the server. As mentioned earlier, the .XAP file is not restricted by the Microsoft stack, and can be served from any webserver.
5. Once the SilverilghtApplication.xap file is downloaded, CoreCLR instantiates the entry point type (if you remember, in our case its SilverlightApplication.App) and fires up the Application.Startup event.

Here are the other events that get executed during the execution cycle of the Silverlight application:

• The Application_Startup event is responsible for displaying the initial user interface, and once the UI is loaded, other events occur based on users’ actions.
• Unhandled application errors can be handled (there’s no other way to describe it) by the Application_UnHandledException event (much like the Application_OnError event in an ASP.NET web application)
• The Application_Exit event gets fired just before the application is released from memory (again, much like the Application_End event in an ASP.NET web application).

Summary

So, we’ve seen that the Silverlight browser plug-in and Silverlight CLR, both of which are running on the client’s machine, are the main components when it comes to executing a native .NET Silverlight application in the browser senvironment. This offers excellent cross-platform support and allows for full communication between your Silverlight application and your web-page. It also means that developers can target a consistent runtime, and execute .NET code without needing to deploy the entire .NET runtime. Moreover, the browser plug-in is a mere handful of Megabytes. What’s not to like?