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:
- A User requests a Web page that hosts the Silverlight plug-in.
- 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.
- 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.
- The plug-in loads the Silverlight core services and the Silverlight runtime environment (CLR) which then creates an Application Domain for your application.
- 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.
- 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 SilverlightThere 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).
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 CycleRemember 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.
- First the App constructor in the App.xaml file.
- The App's Applicaiton_Startup event which will be executed every time you open your Silverlight app.
- 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.
- 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.
- 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.
- Then the SizeChanged event.
- Then the LayoutUpdated event.
- Then GotFocus if you mark the Silverlight app.
- If you navigate from your Silverlight app or close the Browser the App's Application_Exit event will be executed.