Silverlight Application

Silverlight is a next generation development platform for creating engaging, interactive user
experiences for Web, Desktop and mobile applications when online or offline. This is an
application framework for writing and executing rich internet applications, with features and
purposes similar to those of Adobe Flash with some extended features like WCF support, good
programing support form .net framework. The run-time environment for Silverlight is available
as a plug-in for most web browsers running under MS Windows.
Silverlight provides a retained mode graphics system similar to Windows Presentation
Foundation, and integrates multimedia, graphics, animations and interactivity into a single
runtime environment. In Silverlight applications, user interfaces are declared in Extensible
Application Mark-up Language (XAML) and programmed using a subset of the .NET
Framework. XAML can be used for marking up the vector graphics and animations. Also
Microsoft provides Microsoft Blend visual studio for creating design mock ups.
The key benefits of Silverlight is the all logic executing in client side so that will be great
benefits for performance and provide any rich UI to the client side with very fastest execution. It
is also a cross-browser, cross-platform implementation of the .NET Framework for building and
delivering the next generation of media experiences and Rich Interactive Applications (RIA) for
the web. It runs in all popular browsers, including Microsoft Internet Explorer, Mozilla Firefox,
Apple Safari, Opera, and Chrome. Required plugin for run Silverlight application is very small
size so anytime that can be installed.
It is combination of different technologies into a single development platform that allows you to
select tools and the programming language you want to use. Silverlight integrates seamlessly
with your existing Javascript and ASP.NET AJAX code to complement functionality which you
have already created.
Also in newer days Microsoft launches lightswitch with extended version of the Silverlight with
inbuilt facility to generate silver light forms and required services.
Silverlight aims to compete with Adobe Flash and the presentation components of Ajax. It also
competes with Sun Microsystems JavaFX, which was launched a few days after Silverlight.
In Web application have some limitation with performance and rich User Interface because of the
html is executing in client Browser and for major execution parts happen in server side. So the
performance goes down due to this scenario. So, Microsoft has introduced a concept called
Silverlight which is executing in clients browser by automatically installing a plug in of
Silverlight with providing facility of rich UI by XAML and tremendous performance. For server
side data interaction they will call web services by asynchronous call.
Below are the key benefits of Silverlight applications:

Provide excellent performance in web application because it is executing in client

browser, so user can fill experience like as window application
Rich graphical interface available along with animation

Data is stored in server and that access by web services so there is no any security hole

In the unlikely event that you dont know about Silverlight, its 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 Ill 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, youll have a much better sense of whats going on
inside your Silverlight projects, and will better able to troubleshoot basic rendering problems.
To start, lets 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 well be looking at the
browser-based Silverlight project architecture, this dual-solution option will be the focus of this
article. Now lets 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:
2

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. Thats 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 dont 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 Ill also explain why that is later).

SilverlightApplication.Web
This is the ASP.NET web application I mentioned earlier, and youll see that Visual Studio has
generated .html and .aspx pages to host your Silverlight controls.
Lets 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:
<object data="data:application/x-silverlight-2," type="application/x-silverlight-2"
width="100%" height="100%">
<param name="source" value="ClientBin/SilverlightApplication.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"
3

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

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 doesnt 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 lets
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 doesnt 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 dont 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:
<script type="text/javascript"
src="Silverlight.js"/>

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 were 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 dont believe me, you can prove it to
yourself by renaming it as a .zip file and extracting its contents. In the application package,
youll see following two files:
5

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 youre curious, youll see something like the
following in the AppManifest.xaml file:
<Deployment xmlns=http://schemas.microsoft.com/client/2007/deployment
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
EntryPointAssembly="SilverlightApplication"
EntryPointType="SilverlightApplication.App"
RuntimeVersion="4.0.50401.0">
<Deployment.Parts>
<AssemblyPart x:Name="SilverlightApplication" Source="SilverlightApplication.dll" />
</Deployment.Parts>
</Deployment>

The Silverlight CLR (and if that term raise questions in your mind, Ill 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 weve got enough information about the files that get created in a Silverlight web
application, but before we get started, theres one last element I want to introduce: The
Silverlight CLR.

CoreCLR
Ill mention the Silverlight Common Language Runtime in a moment, so lets 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)

6

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 lets look at the execution cycle of a Silverlight application and the roles of those
components weve just discussed.

The Step by Step Execution

1. The client (user) requests the SilverlightApplicationTestPage.html or
SilverlightApplicationTestPage.aspx web page. Lets 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 tags 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/xsilverlight-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 (theres no other way to
describe it) by the Application_UnHandledException event (much like the
Application_OnError event in an ASP.NET web application)
7

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).

Hello Silverlight World, part 3 The

Lifecycle of a Silverlight Control
12
Ok, continuing with building a simple Wizard-generated Silverlight application and then staring
at it to see how it works.. Last time, I talked about the Application object in Silverlight vs.
WPF. This time Ill continue looking at the pieces in the sample Silverlight application, looking
at the Page class that was generated and what happens to this control at runtime on a client
machine.
Pages vs. Windows
I pointed out a couple of posts back the interesting difference here, just in the terminology. In
Silverlight, your main design surface is a page, which sort of comes from the fact that youre
serving up a series of web pages with some content in each. (Nevermind that a Silverlight
control can never be an entire page by itself, but must be hosted in an .html or .aspx page). In
WPF, the main design surface is a window, which seems appropriate because it runs in a
bordered window.
Silverlights UserControl Class
In Silverlight, you render all of your content in a class that derives from
System.Windows.Controls.UserControl. When you use the wizard to generate a Silverlight
application, it creates a class named Page, e.g.:
1public partial class Page : UserControl
2{
3
public Page()
{
4
InitializeComponent();
5
}
6}
7
One other quick thing to look at, is what else were doing in our child class at runtime, beyond
what we get in the UserControl base class. If you build your Silverlight application and then
look at the other half of the partial class, i.e. the generated code in Page.g.cs, youll see:
1 public partial class Page : System.Windows.Controls.UserControl {
2
internal System.Windows.Controls.Grid LayoutRoot;

3
4
private bool _contentLoaded;
5
6
/// <summary>
/// InitializeComponent
7
/// </summary>
8
[System.Diagnostics.DebuggerNonUserCodeAttribute()]
9
public void InitializeComponent() {
10
if (_contentLoaded) {
11
return;
}
12
_contentLoaded = true;
13
System.Windows.Application.LoadComponent(this, new
14System.Uri("/SilverlightApplication2;component/Page.xaml",
15System.UriKind.Relative));
this.LayoutRoot = ((System.Windows.Controls.Grid)
16
(this.FindName("LayoutRoot")));
17
}
18
}
19
So, like our App class that derived from System.Windows.Application, the Page class defines
an InitializeComponent method that just calls the static Application.LoadComponent method,
which just constitutes an object in question, based on its .xaml. So for both our App and our
Page class, the class is getting instantiated and then InitializeComponent causes it to finish
initializing by reading the associated .xaml file and then setting properties and creating child
objects based on what is in the .xaml. This is the magic fairy dust that allows .xaml to workat
runtime, the .xaml is just interpreted and associated objects are created.
The second half of this process is happening at the point where we are setting the LayoutRoot
property. The wizard generated some .xaml for our page that has a Grid as the topmost element,
with the name LayoutRoot. Then, at code generation time, we get a Grid object declared and
then point it to the object that we loaded from the .xaml. (Using the FindName method).
Where Are We?
Ok, so weve seen that there really isnt much to our Page class, other than the fact that it
constitutes itself from the .xaml. But what is really going on at runtime, on the client where this
control will be hosted?
The Lifecycle of a Silverlight Control
To answer that, lets just walk through the entire lifecycle of our Silverlight control, starting from
how the code is downloaded from the server and continuing on to how the Silverlight runtime on
the clients machine loads and renders the control.
It All Starts With a Web Page

Heres a diagram from the MSDN documentation that gives us the big picture. Your Silverlight
control runs in a managed environment (the Silverlight Common Language Runtime), which in
turn runs in the context of a browser plug-in. And that plug-in runs in the context of a web page
that is downloaded from a web server to the client machine.
Remember that when we created our Silverlight application using the Visual Studio wizard, it
also generated an ASP.NET web application in which to host our control. (e.g.
SilverlightApplication1.Web). If you look at the web application, youll see that weve been
given a couple examples of pages hosting our Silverlight control. Specifically, youll see an
.aspx and an .html page. For now, lets look at the more basic of the twothe .html page.
If you open this test page, e.g. SilverlightApplication1TestPage.html, and scroll to the bottom,
youll see an <object> tag that mentions Silverlight:
<object data="data:application/x-silverlight-2," type="application/xsilverlight-2" width="100%" height="100%"><param name="source"
value="ClientBin/SilverlightApplication1.xap"/><param name="onerror"
1value="onSilverlightError" /><param name="background" value="white" /><param
value="2.0.31005.0" /><param name="autoUpgrade"
2name="minRuntimeVersion"
value="true" /><a href="http://go.microsoft.com/fwlink/?LinkID=124807"
3style="text-decoration: none;">
4
<img src="http://go.microsoft.com/fwlink/?LinkId=108181" alt="Get
Microsoft Silverlight" style="border-style: none"/>
</a>
</object>

What we see here is a standard HTML <object> tag, which allows us to embed a 3rd party plugin into the browser on the clients machine. When rendering the web page, the browser will set
aside an area of the page and let the plug-in render directly to that area. In this case, the 3rd
party is Microsoft and the plug-in is Silverlight.
So heres how things get rolling with our Silverlight control, on the clients machine (whoever is
pointing their browser at your .html page):

Client starts up their browser and points it at SilverlightApplication1TestPage.html

(lets assume that the test page is on a web server somewhere)
10

The .html page is downloaded from the web server to the client and the browser begins
rendering the HTML content

The browser reaches the <object> tag, which indicates that a plugin should be loaded,
started up, and allowed to render that part of the page

To figure out how to call the plugin, the browser uses the value of the type attribute on
the object tag.

In our cases, this type is application/x-silverlight-2. This is a MIME type, which maps
to Silverlight 2

Using the MIME type, the browser loads the plugin

o

Under Windows, there is a registry entry that associates this MIME type with an
ActiveX control named AgControl.AgControl, which in turn is implemented by a
DLL npctrl.dll, located in C:\Program Files\Microsoft Silverlight\2.0.40115.0

So npctrl.dll is the actual plugin implementationan unmanaged Windows DLL

that implements the plugin API and, in turn, launches the Silverlight CLRthe
execution environment in which your Silverlight control actually runs

Ok, if you were paying attention, you may have noticed something surprising in that last bullet
point: ActiveX?? Isnt ActiveX dead and buried, now that were dealing with a managed
environment?
Well, yes and no. The code that we are authoringour Silverlight controldoes run in a managed
environment on the client machine, in that it runs inside of the Silverlight CLR/runtime. But the
Silverlight plugin itself has to interact with the web browser and, as such, is unmanaged code
that implements that standard browser plug-in API(s) that allow it to run within the browser.
So clearly, npctrl.dll is unmanaged code. But ActiveX? The MSDN documentation is not 100%
clear on this point, but heres what I think is going on. npctrl.dll is both a classic Win32 DLL
(non-COM), as well as an ActiveX control (COM server). Which mode it runs in depends on the
browser. When running inside of Internet Explorer, the plug-in runs as an ActiveX control,
implementing the IXcpControl COM interface. However, when Silverlight is hosted in other
browsers, like Mozilla, it implements the Netscape Plug-in API, running as a classic Win32
DLL. (It implements functions like NP_Initialize and NP_GetEntryPoints). [This paragraph
is mostly conjecture].
Silverlight Presentation Core

11

Within the Silverlight plug-in, the next layer to take control is the Silverlight Presentation
Core. You can see the Presentation Core as the bottom blue box in this diagram (also found in
MSDN documentation).
The Presentation Core is responsible for rendering everything in the browser, handling user
interaction, playing video, and parsing XAML. Its implemented in agcore.dll, which is a classic
Win32 DLL. (Not a COM server and not a .NET executable).
When your browser starts up (in Firefox, at least), both npctrl.dll (Plug-in) and agcore.dll
(Presentation Core) are loaded. The remaining Silverlight runtime libraries described below are
only loaded when you actually load a page containing a Silverlight control.
Silverlight CoreCLR
After your browser has loaded the Silverlight plug-in, it does three basic things:

Starts up the Silverlight Common Language Runtime

Downloads the .xap file containing your Silverlight control and Application object from
the server

Instantiates your Application object and loads it

The CoreCLR, or Silverlight Common Language Runtime, is the Silverlight version of the
CLR that runs inside the Silverlight plug-in. (Labeled CLR Execution Engine in the above
12

diagram). This is the managed environment that your Silverlight applications run inside, similar
to the CLR that hosts thick-client .NET applications.
The CoreCLR is implemented in coreclr.dll, also in C:\Program Files\Microsoft
Silverlight\2.0.xxxxx.0. The CoreCLR is based on the same codebase as the desktop version of
the CLR, but much smaller, and with features not required in a browser environment removed.
(In the desktop world, the equivalent DLLs are mscoree.dll and mscorwks.dll).
Note: coreclr.dll is also just a plain old unmanaged Win32 DLL. It is the implementation of
the .NET CLR, so it does not run in a managed environment itself.
The XAP File
Before Silverlight can run any of your code on the client machine, it has to download it from the
server. Your Silverlight application is packaged into a .xap file. The .xap file is nothing more
than a .zip file that has been renamed. You can prove this to yourself by building your
application and then renaming the resulting .xap file as a .zip file.

If you look at the files inside your .xap, for a typical wizard-generated Silverlight application,
youll find two files:

AppManifest.xaml
SilverlightApplication1.dll

The AppManifest.xaml file is the application manifest, which tells the Silverlight runtime what
DLLs are present in this package and which one contains the entry point, or startup object, for
your Silverlight application. For example, you might see something like the following:
1<Deployment xmlns="http://schemas.microsoft.com/client/2007/deployment"
2xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
EntryPointAssembly="SilverlightApplication1"
3
13

EntryPointType="SilverlightApplication1.App"

4
RuntimeVersion="2.0.31005.0">
5 <Deployment.Parts>
<AssemblyPart x:Name="SilverlightApplication1"
6
Source="SilverlightApplication1.dll"
/>
7
</Deployment.Parts>
8</Deployment>
Note that the manifest tells Silverlight to load the assembly located in
SilverlightApplication1.dll and that the startup object is SilverlightApplication1.App, which is
the class that derives from System.Windows.Application.
Starting Up
Once the .xap file is downloaded, the CoreCLR can instantiate your object and get things
started. It does this by:

Instantiating an instance of your entry point type, e.g. SilverlightApplication1.App

Firing the Application.Startup event

Our wizard-generated Silverlight application included wizard-generated code to get everything

up and running as follows:

During the App constructor

o Wire a handler for the Application.Startup event
o

App.InitializeComponent, also wizard-generated :

o

Calls Application.LoadComponent, to reconstitute our App object from the

.xaml (like WPF, the XAML lives inside your assembly as compiled BAML)

The handler for the Application.Startup event

o

Instantiates a new Page object (the actual Silverlight control to be displayed)

Sets the RootVisual property of the parent App object to point to the Page

During the Page constructor

o

Call App.InitializeComponent

Call Page.InitializeComponent

Page.InitializeComponent
o

Calls Application.LoadComponent, reconstituting the Page object from the

associated XAML (BAML)

14

Thats really all there is to it. At this point, through the magic of the browser plug-in architecture
and the fact that the Silverlight CoreCLR is running on the clients PC, you have a native .NET
(Silverlight) application running on the client, hosted in the browser.

15