Silverlight Application Life Cycle

In the previous article I attempted to explain What Silverlight is and how it is being used more and more to develop business applications. In this article I will try to explain Silverlight Application Life Cycle. Building apps with Silverlight is more or less similar way of building Desktop apps, for example WinForms or WPF apps.
When you embed the Silverlight plug-in in a Web page, you specify the location of the application package that the plug-in should download. The whole process is as follows:

1. A User requests a Web page that hosts the Silverlight plug-in.
2. If the correct version of Silverlight has been installed, the Web browser loads the Silverlight plug-in and creates the Silverlight content region. The plug-in then begins downloading your .xap file.
3. The plug-in extract the contents of the .xap file and read the AppManifest.xaml file from the XAP to determine the assemblies your application uses.
4. The plug-in loads the Silverlight core services and the Silverlight runtime environment (CLR) which then creates an Application Domain for your application.
5. When the package is downloaded, the plug-in then loads your application assemblies and dependencies (if any) into the AppDomain. The CLR uses the metadata in .xap to instantiate your Application class and the default constructor of the Application class raises its Startup event.
6. The Startup event handler is handled to display a user interface page and that is how you view your UI. This event occurs once the Silverlight plug-in has finished loading the .xap file. Once the UI is loaded, other events occur in response to user actions.

ASP.NET and Silverlight

There are many differences between ASP.net and Silverlight.
ASP.net generates the control (client side scripts to build UI) and send to client for rendering. It requires two processes, dynamic generation of code at server, rendering of server generated code at client inside the browser. Even the code is generated at server by ASP.net worker process, it gets executed as script on the client as it gets downloaded in form of script (html, CSS, js etc).
On other hand, Silverlight contains pre-compiled intermediate language code (MSIL) for controls and only create instance to display that. A single process of instantiation of control is sufficient to render the information in browser. All Silverlight codes are pre-compiled so loading is faster than ASP.net. It requires less data transfer between server and client. There are no "server round trip", no javascript, no Ajax.
Silverlight is just like a Flash app... A server file is request by the plug-in on client computer, your server sends this file (.xap for Silverlight) and the plug-in runs it locally.
ASP.NET is stateless and everything is executed and handled on the server-side, Silverlight is not stateless and everything that is executed is executed by default on the client-side, only when you make call to the server, code on the server-side will be executed. So no refresh, no reloading of pages, no page life cycle, ViewState, just a beautiful rich client that holds state;

Page Life Cycle

Remember that Silverlight is running on the client, not on the server as normal ASP.NET pages... there is no such as Page Life Cycle in Silverlight. But there are some events that will be executed on the client side in a specific order.

1. First the App constructor in the App.xaml file.
2. The App's Applicaiton_Startup event which will be executed every time you open your Silverlight app.
3. The Main page's Constructor..  It will be the constructor of the page assigned to the RootVisual properly within the App's Application_Startup event.
4. InitializeCompnent, only to make sure the components are singed to variables so you can use them. I hope this one will be removed in the future and be handled elsewhere.
5. If you have hooked up to the Loaded event within the Main Page Constructor, that event will then be executed, same with the rest event listen in the order they will be executed if you have hooked up to them.
6. Then the SizeChanged event.
7. Then the LayoutUpdated event.
8. Then GotFocus if you mark the Silverlight app.
9. If you navigate from your Silverlight app or close the Browser the App's Application_Exit event will be executed.

As you may figure out, There is No Life Cycle. If you have a button control on the Silverlight app and press it, there will never we a post back, back to the server. The click event will just simply be fired of on the client-side; it's where the code is executed. To get data from a server, you can for use a WCF service, Web Service, Web Client, .NET RIA Services etc... They will make the call to the server from the client side for you.

Control Initialization Order

There are some subtle differences between instantiating a control in XAML, and instantiating it via code that I've called out, but most of the lifecycle is the same. 

A Short History of Silverlight


The development of Silverlight has been consistently incremental. Silverlight 4 is a superset
of Silverlight 3, which is a superset of Silverlight 2. Some of the code might not be
completely compatible between versions, mostly because when some things were missing
developers had to use workarounds. After a feature has been added in a later version,
however, the workarounds might not work properly anymore, and it is time to upgrade
the code to the proper implementation.
In some rare cases, the interface to some functionality might have changed because the
team came up with a better implementation. These occurrences are rare, however, and
upgrading an application to a newer version of Silverlight should be easy enough.




Silverlight 1.0
This early release of Silverlight (May2007) was far from complete, and in fact did not support any .NET code; it had to be programmed in JavaScript. It did, however, support a small subset of
XAML (eXtensible Application Markup Language), the language used to define
the user interface of Silverlight applications.


Silverlight 2
For a very short time, this version was named Silverlight 1.1, but considering the major
changes implemented (and also to simplify the versioning process), it made sense to
change the version number to a full digit instead.
Silverlight 2 (released shortly before the Professional Developer Conference in October
2008) was revolutionary because it brought for the very first time the .NET framework (as
a subset) to other platforms than Windows. It also included a rich set of controls,
enhanced video, new tool support, and many other exciting features



Silverlight 3
This version (again a full-digit increment) was released in July 2009, a mere nine months
after Silverlight 2. In this short time, the team managed to bring Silverlight to a more
mature version.



And Silverlight 4…
And here we are! Silverlight 4 will not be the final version of this technology, but one
thing is sure: If you were still hesitating to invest in Silverlight, now is a great time to
start. We know a lot about what Silverlight is, what it can do and cannot do, and we have
a quite clear vision of what will happen in the near future. We also have Silverlight
experts with (in some cases) two or three years of experience with this technology.
Silverlight 4 is a very stable release. What we predicted when Silverlight 2 was published is
proven true today: Silverlight is here to stay, and Microsoft is betting a lot on this technology.
In these three years, it went from “Flash contender” to major user interface technology.
According to recent numbers, the Silverlight installation basis grew very fast since
Silverlight 2 was released, and you can count on approximately 60% of all the connected
computers having Silverlight 3 or Silverlight 4 already installed

Hi Friends ,,,


Wait for Few Days ... I am coming with new SilverLight  4.0 tutorial from beginner to Advance ..




Regards 


Sujeet Bhujbal
Senior Software Engineer 

Difference between web services and WCF

These days all the projects that are upgrading from .net 2.0 to .net 3.5 or to .net 4.0 are facing the issue of choosing between web-services and WCF (Windows Communication Foundation). In this post I am going to discuss the difference between them and look at points which would make clear what to choose and throw light to web-service vs WCF issue. .

WCF Definition

WCF is a part of the .NET Framework that provides a unified programming model for rapidly building service-oriented applications that communicate across the web and the enterprise.

The following figure shows the features that the WCF provides compared to other technology in .net:

ASP.NET Web services was developed for building applications that send and receive messages by using the Simple Object Access Protocol (SOAP) over HTTP. The structure of the messages can be defined using an XML Schema, and a tool is provided to facilitate serializing the messages to and from .NET Framework objects. The technology can automatically generate metadata to describe Web services in the Web Services Description Language (WSDL), and a second tool is provided for generating clients for Web services from the WSDL.

WCF is for enabling .NET Framework applications to exchange messages with other software entities. SOAP is used by default, but the messages can be in any format, and conveyed by using any transport protocol. The structure of the messages can be defined using an XML Schema, and there are various options for serializing the messages to and from .NET Framework objects. WCF can automatically generate metadata to describe applications built using the technology in WSDL, and it also provides a tool for generating clients for those applications from the WSDL.

There are different points to consider for WCF:

1.    WCF is architecturally more robust and promotes best practices.

2.    If you know what you are doing its "silky smooth" if not you are in for a ride.

3.    Do you have enough time to complete the conversion of your services?

Two further aspects:
1) No matter how you decide this for the server-side, you can easily consume Webservices and WCF Services using only WCF on the client-side. This is of value, if you consume multiple services with a single client.
2) If you consider Cloud Computing: It is possible to host WCF Services on Windows Azure.

Finally I would say that, if you have the time, the bling and the muscle to do the upgrade. Its worth it. If asmx is satisfying all the needs, you may persist with web services.

ASMX is great and simple - but it's very limited in many ways:

·         you can only host your web services in IIS

·         you can only reach your web services over HTTP

·         security is very limited

WCF remedies this - and offer much more beyond that. You can host your WCF services in IIS - or self-host in a console app or Win NT Service, as need be. You can connect your WCF services using HTTP, TCP/IP, MSMQ, Peer-to-peer protocols, named pipes for on-machine communications and much more.

I'd definitely recommend you go with WCF. It's a tad more complex than ASMX, but it also offer just sooo much more capabilities and choices!

Major difference between the two is that Web Services use XmlSerializer but WCF uses DataContractSerializer which is better in performance as compared to XmlSerializer. Some key issues with XmlSerializer to serialize .NET types to XML are:

* Only Public fields or Properties of .NET types can be translated into XML.
* Only the classes which implement IEnumerable interface.
* Classes that implement the IDictionary interface, such as Hash table can not be serialized.

Important difference between DataContractSerializer and XMLSerializer:

* A practical benefit of the design of the DataContractSerializer is better performance over Xmlserializer.

* XML Serialization does not indicate the which fields or properties of the type are serialized into XML where as DataCotratSerializer Explicitly shows the which fields or properties are serialized into XML.

* The DataContractSerializer can translate the HashTable into XML.
Quick benefits of WCF over Web-Services (ASMX):

1) For internal (behind firewall) service-to-service calls we use the net:tcp binding, which is much faster than SOAP

2) We enabled both a net:tcp endpoint and a "web" endpoint on the same service with only a configuration file update (no code changes)

3) We were able to create AJAX-supporting RESTful web services with only configuration changes and using the DataContractJsonSerializer that's already built in. To do this otherwise, we would have had to write an HTTP Handler (ashx) and handle most of the Json serialization and url parsing by hand.

4) As our site needs to scale for performance optimization and stability, we are looking at converting to using an MSMQ-based messaging structure that is asynchronous AND guaranteed and participates in transactions; WCF provides an MSMQ bindng that requires little-to-no code change in our services--just reference updates and setting up MSMQ properly with the existing services (and adding attributes for Transactional boundaries).

BUT BE WARNED: Really invest in learning this. There are things like argument-name-changes during development that actually don't break the service references but result in null arguments being passed (built-in version skew handling), hosting models to consider (Windows Service vs. IIS), and instantiation models and FaultExceptions to all REALLY understand. We didn't going in and we had some pains. But we plowed ahead and are VERY happy with our learnings and the flexibility and growth opportunities we have not being tied to ASMX anymore!

wcf for beginners

The WCF Service

The WCF Interface you expose can not be particularly complex if you want to use the Service Moniker – I’ve found it best to keep top primitive types, and arrays of primitive types.  Data Contracts seem to be a no-go.
Start by creating a new WCF Service using File|New|Project and selecting WCF Service Library:

Double-click on IService1.cs in the Solution Explorer, and replace the default contents with this simple interface:

using System;
using System.ServiceModel;

namespace WcfService1
{
    [ServiceContract]
    public interface IService1
    {
        [OperationContract]
        string GetData(int value);

        [OperationContract]
        object[] GetSomeObjects();
    }
}

Next replace the contents of the service implementation, Service1.cs, with the following:

using System;

namespace WcfService1
{
    public class Service1 : IService1
    {
        public string GetData(int value)
        {
            return string.Format("You entered: {0}", value);
        }

        public object[] GetSomeObjects()
        {
            return new object[] { "String", 123, 44.55, DateTime.Now };
        }
    }
}

Configuring the WCF Service

By default the WCF Service is configured to use HTTP as the transport protocol.  I generally switch it to use TCP, because I am operating within a corporate intranet, and HTTP seems like overkill.
You’ll also find that by default your WCF Service exposes two endpoints.  The first exposes as you’d expect, the IService1 interface you defined above.  The second exposes Metadata about your service, which the Service Moniker uses to know what operations are available on your service.  You’ll need both.
Right-click on the App.config file in the Solution Explorer, and select Edit WCF Configuration:

Switch the first endpoint to use TCP:

Also change the second to use mexTcpBinding:

Change the base address that the service will use, to use a TCP address instead of a HTTP Address by selecting the Host node on the left hand tree, and then selecting the base address and clicking on Edit, and changing the text to be net.tcp://localhost:7891/Test/WcfService1/Service1/

Finally, because you are using TCP instead of HTTP, change the MetataData service to not expect to expose the metadata via HTTP, by changing HttpGetEnabled to False under Advanced|Service Behaviours…

Save the changes and exit the WCF Editor.  Your App.config should look like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.web>
    <compilation debug="true" />
  </system.web>
  <system.serviceModel>
    <services>
      <service behaviorConfiguration="WcfService1.Service1Behavior"
        name="WcfService1.Service1">
        <endpoint address="" binding="netTcpBinding" bindingConfiguration=""
          contract="WcfService1.IService1">
          <identity>
            <dns value="localhost" />
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexTcpBinding" bindingConfiguration=""
          contract="IMetadataExchange" />
        <host>
          <baseAddresses>
            <add baseAddress="net.tcp://localhost:7891/Test/WcfService1/Service1/" />
          </baseAddresses>
        </host>
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="WcfService1.Service1Behavior">
          <serviceMetadata httpGetEnabled="False"/>
          <serviceDebug includeExceptionDetailInFaults="False" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

To start running your service you can hit Ctrl-F5 in Visual Studio.  This will start a test service host, and a test client.  We will ignore the client, but you can check that the service host has started by clicking on the message in the notification area:


Eventually you’ll want to host your service somewhere else, such as a Windows Service.

WCF Hosting with Different ways

•       The host can be provided by Internet Information Services (IIS), by the Windows Activation Service (WAS) on Windows Vista or Windows Server 2008, Windows 7 or later, on the Windows Server AppFabric, or by the developer as part of the application.

•       In-process (or in-proc) hosting, where the service resides in the same process as the client, is a special case. By definition, the developer provides the host for the in-proc case.

IIS 5/6 Hosting

•       The main advantage of hosting a service on the Microsoft IIS web server is that the host process is launched automatically upon the first client request, and IIS 5/6 manages the lifecycle of the host process.

•       The main disadvantage of IIS 5/6 hosting is that you can only use HTTP.

•       With IIS 5, you are further restricted to having all services use the same port number.

•       Hosting in IIS is very similar to hosting a classic ASMX web service.

•       You need to create a virtual directory under IIS and supply an .svc file.

•       The .svc file functions similarly to an .asmx file and is used to identify the service code behind the file and class.

Using Visual Studio 2010

•       You can use Visual Studio 2010 to generate a boilerplate IIS-hosted service.

•       From the File menu, select New Web Site, then select WCF Service from the New Web Site dialog box. Visual Studio 2010 creates a new website, a service code, and a matching .svc file.

•       You can also use the Add New Item dialog box to add another service later.

Self-Hosting

•       Self-hosting is the technique in which the developer is responsible for providing and managing the lifecycle of the host process.

•       Use self-hosting when you want a process (or machine) boundary between the client and the service and when you are using the service in-proc—that is, in the same process as the client.

•       You can provide any Windows process, such as a Windows Forms application, a WPF application, a Console application, or a Windows NT Service.

•       You can provide a host with only a few lines of code.

•       A self-hosted service can use any WCF transport protocol, and you can take advantage of all the WCF features, including the service bus, discovery, and utilize a singleton service.

•       Hosting application config file (app.config) typically lists the types of the services you wish to host and expose to the world.

•       You need to provide the constructor of ServiceHost with the service type and optionally with default base addresses.

•       The set of base addresses can be an empty set, and even if you provide base addresses, you can configure the service to use different base addresses.

•       Having a set of base addresses enables the service to accept calls on multiple addresses and protocols and to use only a relative URI.

WAS Hosting

•       The problem with hosting in IIS 5/6 is that it is a web server, not a hosting engine.

•       It therefore requires you to masquerade your service as a website

•       While ASP.NET encapsulates this step for you, it causes a significant increase in internal complexity, involving the HTTP modules and the ASP.NET pipeline.

•       The problem is that the more moving parts involved, the higher the likelihood of something going wrong.

•       As a result, hosting in IIS 5/6 is notorious for instability and the frequent need to reset the server or IIS 5/6. Moreover, limiting the service to using only HTTP makes IIS 5/6 ill-suited for intranet applications.

What Is WCF?

•WCF is a software development kit for developing and deploying services on Windows.

•WCF provides a runtime environment for your services, enabling you to expose Common Language Runtime (CLR) types as services and to consume other services as CLR types.

•WCF is Microsoft’s implementation of a set of industry standards defining service interactions, type conversions, marshaling, and the management of various protocols.

•Consequently, WCF provides interoperability between services

•WCF provides developers with the essential off-the-shelf plumbing required by almost all applications and, as such, it greatly increases productivity.

•The first release of WCF 3.0 provided many useful facilities for developing services, such as hosting, service instance management, asynchronous calls, reliability, transaction management, disconnected queued calls, and security.

•The second release of WCF 3.5 provided additional tools and extended the original offering with additional communication options.

•The third release 4.0 includes configuration changes, a few extensions, and the new features of discovery and routers. While not directly related, WCF is also extended to support the Windows Azure Platform AppFabric Service Bus.

•WCF has an elegant extensibility model you can use to enrich the basic offering. 

•In fact, WCF itself is written using this extensibility model. 

•WCF is part of .NET 4.0, so it can run only on operating systems that support it.

•Presently, this list consists of Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, and Windows 7 or later.

•Most of the WCF functionality is included in a single assembly called System.Service-Model.dll, located in the System.ServiceModel namespace.

•Visual Studio 2010 allows you to add a WCF service to any application project by selecting WCF Service from the Add New Item dialog box. 

•A service added this way is, of course, in-proc toward the host process, but out-of-proc clients can also access it.