Examining the Silverlight 2.0 Architecture
The Silverlight 2.0 runtime plug-in is essentially a ‘micro’ version of the .NET CLR. This runtime is hosted
within the client side browser. This runtime will host your Silverlight assemblies, as well as the Silverlight
base class libraries. This runtime will JIT CIL code, handle threads, exceptions and garbage collection. This is
a good thing, as your current .NET programming skills apply directly to Silverlight development.
In addition to the ‘micro-CLR’, Silverlight 2.0 supports a subset of the .NET base class libraries. When a
requesting browser loads a Silverlight page, any required assemblies are downloaded to the user’s machine, if
they are currently not installed. Like any other .NET program, you can build your own code custom libraries
for use within your Silverlight programs.
Many of the Silverlight libraries are identically named to their .NET 3.5 counterparts (for example, mscorlib.
dll). However in every case, the Silverlight equivalents are lean-and-mean versions which support a *subset*
of the functionality found in their .NET 3.5 counterparts. For example, .NET 3.5 and Silverlight 2.0 each
provide a System.Threading namespace within the mscorlib.dll assembly. However, the Silverlight 2.0
implementation contains fewer types than that of .NET 3.5. Given this, be careful when incorporating .NET
3.5 code libraries into a Silverlight 2.0 application! Testing will be necessary.
The SDK documentation provides the following helpful legend which breaks down the Silverlight architecture.
Again note that Silverlight 2.0 offers support for LINQ, WCF services, numerous GUI controls and XML
processing support. Also note that version 1.0 and 2.0 both make use of XAML.
A Silverlight 2.0 application is deployed from a web server as an ‘XAP’ package. The XAP file contains the
compiled Silverlight assembly, any embedded resources, and any referenced assemblies. The Silverlight
runtime downloads the XAP package and executes its contents.
Recall, a Silverlight 2.0 application is typically a part of a larger HTML web page. If you wish, you can build
the web page using nothing but HTML and JavaScript. As well, ASP.NET provides some Silverlight web-
controls, which will generate the required client side script code. You will look at each approach later in the
course.
The following diagram illustrates the relationship between the client-side and server-side resources. As
expected, HTTP is used to request the initial web page containing the SL 2.0 plug-in. Once loaded by the
plug-in, the SL 2.0 application is able to make remote calls (to the web server or any arbitrary endpoint) using
WCF technologies. The entire web page does *not* need to be refreshed when the SL 2.0 web plug in changes
state. This can greatly enhance the end user experience.
The Silverlight 2.0 runtime plug-in is essentially a ‘micro’ version of the .NET CLR. This runtime is hosted
within the client side browser. This runtime will host your Silverlight assemblies, as well as the Silverlight
base class libraries. This runtime will JIT CIL code, handle threads, exceptions and garbage collection. This is
a good thing, as your current .NET programming skills apply directly to Silverlight development.
In addition to the ‘micro-CLR’, Silverlight 2.0 supports a subset of the .NET base class libraries. When a
requesting browser loads a Silverlight page, any required assemblies are downloaded to the user’s machine, if
they are currently not installed. Like any other .NET program, you can build your own code custom libraries
for use within your Silverlight programs.
Many of the Silverlight libraries are identically named to their .NET 3.5 counterparts (for example, mscorlib.
dll). However in every case, the Silverlight equivalents are lean-and-mean versions which support a *subset*
of the functionality found in their .NET 3.5 counterparts. For example, .NET 3.5 and Silverlight 2.0 each
provide a System.Threading namespace within the mscorlib.dll assembly. However, the Silverlight 2.0
implementation contains fewer types than that of .NET 3.5. Given this, be careful when incorporating .NET
3.5 code libraries into a Silverlight 2.0 application! Testing will be necessary.
The SDK documentation provides the following helpful legend which breaks down the Silverlight architecture.
Again note that Silverlight 2.0 offers support for LINQ, WCF services, numerous GUI controls and XML
processing support. Also note that version 1.0 and 2.0 both make use of XAML.
A Silverlight 2.0 application is deployed from a web server as an ‘XAP’ package. The XAP file contains the
compiled Silverlight assembly, any embedded resources, and any referenced assemblies. The Silverlight
runtime downloads the XAP package and executes its contents.
Recall, a Silverlight 2.0 application is typically a part of a larger HTML web page. If you wish, you can build
the web page using nothing but HTML and JavaScript. As well, ASP.NET provides some Silverlight web-
controls, which will generate the required client side script code. You will look at each approach later in the
course.
The following diagram illustrates the relationship between the client-side and server-side resources. As
expected, HTTP is used to request the initial web page containing the SL 2.0 plug-in. Once loaded by the
plug-in, the SL 2.0 application is able to make remote calls (to the web server or any arbitrary endpoint) using
WCF technologies. The entire web page does *not* need to be refreshed when the SL 2.0 web plug in changes
state. This can greatly enhance the end user experience.
Silverlight Architecture
Table of Contents
Copyright (c) 2008. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Courseware
Training Resources
Tutorials
Services