Silverlight - Micorosoft's magic for RIA (Part 3)

For previous part of this post, please visit Silverlight (Part 2).

Creating an ASP.NET Web Site with Silverlight Content:

Although Silverlight does perfectly well on its own, you can also develop, test, and deploy it as part of an ASP.NET web site. Here’s how to create a Silverlight project and an ASP.NET web site that uses it in the same solution:

1. Select File -> New -> Project in Visual Studio, choose the Visual C# group of project types, and select the Silverlight Application template. It’s a good idea to use the Create directory for solution option, so you can group together the two projects that Visual Studio will create—one for the Silverlight assembly and one for ASP.NET web site.

2. Once you’ve picked the solution name and project name, click OK to create it.

3. When asked whether you want to create a test web, choose the first option, Add a new Web. You’ll also need to supply a project name for the ASP.NET web site. By default, it’s your project name with the added text _Web. Finally, click OK to create the solution.

There are two ways to integrate Silverlight content into an ASP.NET application:

(1) Create HTML files with Silverlight content: You place these files in your ASP.NET web site folder, just as you would with any other ordinary HTML file. The only limitation of this approach is that your HTML file obviously can’t include ASP.NET controls, because it won’t be processed on the server.

(2) Place Silverlight content inside an ASP.NET web form: To pull this trick off, you need the help of the Xaml web control. You can also add other ASP.NET controls to different regions of the page. The only disadvantage to this approach is that the page is always processed on the server. If you aren’t actually using any server-side ASP.NET content, this creates an extra bit of overhead that you don’t need when the page is first requested.

Of course, you’re also free to mingle both of these approaches, and use Silverlight content in dedicated HTML pages and inside ASP.NET web pages in the same site. When you create a Silverlight project with an ASP.NET web site, you’ll start with both. For example, if your Silverlight project is named SilverlightApplication1, you can use SilverlightApplication1TestPage.html or SilverlightApplication1TestPage.aspx. The HTML file is identical to the test page in the ordinary Silverlight-only solution you saw earlier. The .aspx file is an ASP.NET web form that uses ASP.NET’s Xaml web control to show your Silverlight application. The end result is the same, but the Silverlight control creates the test page markup dynamically, when it’s processed on the server. (This extra step gives you a chance to use your own server-side code to perform other tasks when the page is initially requested, before the Silverlight application is downloaded and launched.) Below figure shows how a Silverlight and ASP.NET solution starts out.

Along with the two test pages, the ASP.NET web site also includes a Default.aspx page (which can be used as the entry point to your ASP.NET web site) and web.config (which allows you to configure various web site settings).

Silverlight and ASP.NET provide essentially the same debugging experience as a Silverlight-only solution. When you run the solution, Visual Studio compiles both projects and copies the Silverlight assembly to the ClientBin folder in the ASP.NET web site. (This is similar to assembly references—if an ASP.NET web site references a private DLL, Visual Studio automatically copies this DLL to the Bin folder.) Once both projects are compiled, Visual Studio looks to the startup project (which is the ASP.NET web site) and looks for the start page (which is SilverlightApplication1TestPage.aspx). It then launches the default browser and navigates to the start page.

Silverlight Compilation and Deployment:
Now that you’ve seen how to create a basic Silverlight project, add a page with elements and code, and run your application, it’s time to dig a bit deeper. In this section, you’ll see how your Silverlight is transformed from a collection of XAML files and source code into a rich browser-based application.

Compiling a Silverlight Assembly:
When you compile a Silverlight project, Visual Studio uses the same csc.exe compiler that you use for full-fledged .NET applications. However, it references a different set of assemblies and it passes in the command-line argument nostdlib, which prevents the C# compiler from using the standard library (the core parts of the .NET Framework that are defined in mscorlib.dll). In other words, Silverlight applications can be compiled like normal .NET applications written in standard C#, just with a more limited set of class libraries to draw on. The Silverlight compilation model has a number of advantages, including easy deployment and vastly improved performance when compared to ordinary JavaScript. Your compiled Silverlight assembly includes the compiled code and the XAML documents for every page in your application, which are embedded in the assembly as resources. This ensures that there’s no way for your event handling code to become separated from the user interface markup it needs. Incidentally, the XAML is not compiled in any way (unlike WPF, which converts it into a more optimized format called BAML).
Your Silverlight project is compiled into a DLL file named after your project. For example, if you have a project named SilverlightApplication1, the csc.exe compiler will create the file SilverlightApplication1.dll. The project assembly is dumped into a ClientBin folder in your project directory, along with a few other important files:

(1) A PDB file: This file contains information required for Visual Studio debugging. It’s named after your project assembly (for example, SilverlightApplication1.pdb).
(2) AppManifest.xaml: This file lists assembly dependencies.
(3) Dependent assemblies: The ClientBin folder contains the assemblies that your Silverlight project uses, provided these assemblies have the Copy Local property set to true. Assemblies that are a core part of Silverlight have Copy Local set to False, because they don’t need to deployed with your application. (You can change the Copy Local setting by expanding the References node in Solution Explorer, selecting the assembly, and using the Properties window.).
(4) TestPage.html: This is the entry page that the user requests to start your Silverlight application.
(5) A XAP file: This is a Silverlight package that contains everything you need to deploy your Silverlight application, including the application manifest, the project assembly, and any other assemblies that your application uses.

Deploying a Silverlight Assembly:
Once you understand the Silverlight compilation model, it’s a short step to understanding the deployment model. The XAP file is the key piece. It wraps the units of your application (the application manifest and the assemblies) into one neat container. Technically, the XAP file is a ZIP archive. To verify this, rename a XAP file like SilverlightApplication1.xap to SilverlightApplication1.xap.zip. You can then open the archive and view the files inside.

The XAP file system has two obvious benefits:
(1) It compresses your content: Because this content isn’t decompressed until it reaches the client, it reduces the time required to download your application. This is particularly important if your application contains large static resources , like images or blocks of text.

(2) It simplifies deployment: When you’re ready to take your Silverlight application live, you simply need to copy the XAP file to the web server, along with TestPage.html or a similar HTML file that includes a Silverlight content region. You don’t need to worry about keeping track of the
assemblies and resources.

Thanks to the XAP model, there’s not much to think about when deploying a simple Silverlight application. Hosting a Silverlight application simply involves making the appropriate XAP file available, so the clients can download it through the browser and run it on their local machines. However, there’s one potential stumbling block. When hosting a Silverlight application, your web server must be configured to allow requests for the XAP file type. This file type is included by default in IIS 7, provided you’re using Windows Server 2008 or Windows Vista with Service Pack 1. If you have Windows Vista without Service Pack 1, you have an earlier version of IIS, or you have another type of web server, you’ll need to add a file type that maps the .xap extension to the MIME type application/xsilverlight-app. For IIS instructions, see http://learn.iis.net/page.aspx/262/silverlight.

Now, you get enough basic knowledge of Silverlight. For more articles, videos, blogs please visit http://silverlight.net/

Silverlight - Micorosoft's magic for RIA (Part 2)

For first part of this post, please visit Silverlight (Part 1).

Silverlight and Visual Studio 2008:

VS2008 does not support built in template for Silverlight application. You need to download Silverlight tools from following link: http://www.microsoft.com/downloads/details.aspx?FamilyId=c22d6a7b-546f-4407-8ef6-d60c8ee221ed&displaylang=en.

VS2010 will includes built in template for Silverlight application so be patient till release of VS2010 :).

There are two types of Silverlight web sites that you can create in Visual Studio:
(1) Ordinary HTML web site: In this case, the entry point to your Silverlight application is a basic HTML file that includes a Silverlight content region.

(2) ASP.NET web site: In this case, Visual Studio creates two projects—one to contain the Silverlight application files, and one to hold the server-side ASP.NET web site that will be deployed alongside your Silverlight files. The entry point to your Silverlight application can be an ordinary HTML file or an ASP.NET web form that also includes server-generated content.

ASP.NET is a better approach in the following cases:
- You want to create a web application that combines ASP.NET web pages with Silverlight- enhanced pages.
- You want to generate Silverlight content indirectly, using ASP.NET web controls.
- You want to create a Silverlight application that calls a web service, and you want to design the web service at the same time (and deploy it to the same web server).

Creating a Silverlight Project:
Now that you understand the two types of Silverlight web sites, you’re ready to create a new Silverlight application by following these steps:

1. Select File ->New ->Project in Visual Studio, choose the Visual C# group of project types, and select the Silverlight Application template. As usual, you need to pick a project name and a location on your hard drive before clicking OK to create the project.

2. At this point, Visual Studio will prompt you to choose whether you want to create an ordinary HTML web site or a full-fledged ASP.NET web site that can run server-side code. For now, choose the second option to create an ordinary web site and click OK.

The Anatomy of a Silverlight Application:
Every Silverlight project starts with a small set of essential files, as shown in Figure.



All the files that end with the extension .xaml use a flexible markup standard called XAML. All the files that end with the extension .cs hold the C# source code that powers your application.

Here’s a rundown of the files shown in above Figure:
- App.xaml and App.xaml.cs: These files allow you to configure your Silverlight application. They allow you to define resources that will be made available to all the pages in your application, and they allow you to react to application events such as startup, shutdown, and error conditions. In a newly generated project, the startup code in the App.xaml.cs file specifies that your application should begin by showing Page.xaml.

- Page.xaml: This file defines the user interface (the collection of controls,
images, and text) that will be shown for your first page. Technically, Silverlight pages are user controls. A Silverlight application can contain as many pages as you need—to add more, simply choose Project à Add New Item, pick the Silverlight User Control template, choose a file name, and click Add.

- Page.xaml.cs: This file includes the code that underpins your first page, including the event handlers that react to user actions.

Along with these four essential files, there are a few more ingredients that you’ll only find if you dig around. Under the Properties node in Solution Explorer, you’ll find a file named AppManifest.xml, which lists the assemblies that your application uses. You’ll also find a file named AssemblyInfo.cs that contains information about your project (such as its name, version, and publisher), which is embedded into your Silverlight assembly when it’s compiled. Neither of these files should be edited by hand—instead, they’re modified by Visual Studio when you add references or set projects properties. Lastly, the gateway to your Silverlight application is an automatically generated but hidden HTML file named TestPage.html. To see this file, click the Show All Files icon at the top of the Solution Explorer window, and expand the ClientBin folder (which is where your application is compiled).
Let’s add one textblock named “lblMessage” and one button named “cmdClickMe” on page.xaml.

Adding Event Handling Code:
You attach event handlers to the elements in your page using attributes, which is the same approach that developers take in WPF, ASP.NET, and JavaScript. For example, the Button element exposes an event named Click that fires when the button is triggered with the mouse or keyboard. To react to this event, you add the Click attribute to the Button element, and set it to the name of a method in your code.

This example assumes that you’ve created an event handling method named cmd_ClickMe. Here’s what it looks like in the Page.xaml.cs file:

private void cmdClickMe_Click(object sender, RoutedEventArgs e)
{
lblMessage.Text = "Goodbye, cruel world.";
}

You can’t coax Visual Studio into creating an event handler by doubleclicking
an element or using the Properties window (as you can in other types of projects). However, once you’ve added the event handler, you can use IntelliSense to quickly assign it to the right event. Begin by typing in the attribute name, followed by the equal sign. At this point, Visual Studio will pop up a menu that lists all the methods that have the right syntax to handle this event and currently exist in your code-behind class. Simply choose the right event handling method.

For next part of this post, please visit Silverlight (Part 3).

Silverlight - Micorosoft's magic for RIA (Part 1)

Hi Friends, sorry for delay in new post. Actually, I was busy with some personal stuff. Today, I got time and going to discuss Silverlight.

Microsoft has released two versions of Silverlight: Silverlight 1.0 and Silverlight 2.0. Personally I don’t like Silverlight 1.0. The actual magic begins with Silverlight 2.0. So let’s start our journey with Silverlight 2.0.

Silverlight is a framework for building rich, browser-hosted applications that run on a variety of operating systems. Silverlight works its magic through a browser plug-in. When you surf to a web page that includes some Silverlight content, this browser plug-in runs, executes the code, and renders that content in a specifically designated region of the page. The important part is that the Silverlight plug-in provides a far richer environment than the traditional blend of HTML and JavaScript that powers ordinary web pages.

Silverlight Vs. Flash
The most successful browser plug-in is Adobe Flash, which is installed on over 90 percent of the world’s web browsers. It’s perfectly reasonable for .NET developers to create web sites that use Flash content. However, doing so requires a separate design tool and a completely different programming language (ActionScript) and programming environment (Flex).

Silverlight aims to give .NET developers a better option for creating rich web content. Silverlight provides a browser plug-in with many similar features to Flash, but one that’s designed from the ground up for .NET. Silverlight natively supports the C# language and embraces a range of .NET concepts. As a result, developers can write client-side code for Silverlight in the same language they use for server-side code (such as C# and VB) and use many of the same abstractions (including streams, controls, collections, generics, and LINQ).

Features Silverlight 2.0:

(1) Lightweight download: In order to encourage adoption, Silverlight is installed with a small-size setup (about 4MB) that’s easy to download.

(2) 2D Drawing: Silverlight provides a rich model for 2D drawing. Best of all, the content you draw is defined as shapes and paths, so you can manipulate this content on the client side. You can even respond to events (like a mouse click on a portion of a graphic), which makes it easy to add interactivity to anything you draw.

(3) Controls: Developers don’t want to reinvent the wheel, so Silverlight is stocked with a few essentials, including buttons, text boxes, lists, and a grid. Best of all, these basic building blocks can be restyled with custom visuals if you want all of the functionality but none of the stock look.

(4) Animation: Silverlight has a time-based animation model that lets you define what should happen and how long it should take. The Silverlight plug-in handles the sticky details, like interpolating intermediary values and calculating the frame rate.

(5) Media: Silverlight provides playback of Windows Media Audio (WMA), Windows Media Video (WMV7 through WMV9), MP3 audio, and VC-1 (which supports high definition). You aren’t tied to the Windows Media Player ActiveX control or browser plug-in—instead, you can create any front end you want, and you can even show video in full-screen mode.

(6) The CLR: Most impressively, Silverlight includes a scaled-down version of the CLR, complete with an essential set of core classes, a garbage collector, a just-in-time (JIT) compiler, support for generics, threading, and so on. In many cases, developers can take code written for the full .NET CLR and use it in a Silverlight application with only moderate changes.

(7) Networking: Silverlight applications can call old-style ASP.NET web services (ASMX) or Windows Communication Foundation (WCF) web services. They can also send manually created XML requests over HTTP. This gives developers a great way to combine rich client-side code with secure server-side routines.

(8) Data binding: Although it’s not as capable as in its big brother, Windows Presentation Foundation (WPF), Silverlight data binding provides a convenient way to display large amounts of data with minimal code. You can pull your data from XML or in-memory objects, giving you the ability to call a web service, receive a collection of objects, and display their data in a webpage—often with just a couple of lines of code.

Limitations Silverlight 2.0:
- Lack of database support (there’s no ADO.NET)
- No support for 3D drawing
- No printing
- No command model and few rich controls like trees and menus

For next part of this post, please visit Silverlight (Part 2).