Overview
When a browser finished loading a page containing the Silverlight <object> tag, the plugin initialized its embedded CLR, downloaded and unpacked the referenced .xap package, read AppManifest.xaml to locate the entry-point assembly, and instantiated the Application-derived class defined in App.xaml.cs — at which point it raised the Startup event, where developers conventionally assigned Application.Current.RootVisual to a MainPage instance, the UserControl that would actually become visible on screen.
Cricket analogy: The sequence from plugin load to Startup is like the toss ceremony before a match: the pitch report is checked, the manifest, the captains are confirmed, the Application class, and only once the coin lands does the umpire signal play can begin, the Startup event.
Runtime Events: Errors, Navigation, and Resizing
Once running, a Silverlight application handled several lifecycle events beyond Startup: Application.UnhandledException fired for any exception escaping managed code, and leaving it unhandled in early Silverlight versions could crash the plugin silently, so production apps always wired a handler that logged the error and set e.Handled = true; the Frame control's Navigated and Navigating events supported page-to-page navigation within a single .xap, mimicking multi-page browsing without a full page reload; and the host page's resize behavior combined with Silverlight's own SizeChanged event let a Canvas or Grid adapt its layout whenever the browser window changed size.
Cricket analogy: Application.UnhandledException catching a stray exception is like the DRS catching a bat-pad edge the on-field umpire missed, a safety net that reviews and corrects a problem before it wrongly ends the innings, the whole plugin session.
Shutdown: Application_Exit and Cleanup
When the user navigated away from the host page or closed the browser tab, the plugin raised Application.Exit, giving developers a final, brief opportunity to persist state — typically into IsolatedStorageSettings.ApplicationSettings, a synchronous local write — since anything relying on a pending network call was best-effort only, as the plugin could be torn down mid-request. Unlike a WPF desktop app, which had a comparatively generous and predictable shutdown sequence, a Silverlight application had no guarantee of a lengthy graceful exit, because browser navigation could terminate the plugin process abruptly at any point.
Cricket analogy: A match abandoned for bad light gives the umpires only a brief window to record the exact score and overs bowled before players must leave, mirroring Application_Exit's brief, unguaranteed window to persist state before the plugin is gone.
public partial class App : Application
{
public App()
{
this.Startup += this.Application_Startup;
this.Exit += this.Application_Exit;
this.UnhandledException += this.Application_UnhandledException;
InitializeComponent();
}
private void Application_Startup(object sender, StartupEventArgs e)
{
this.RootVisual = new MainPage();
}
private void Application_Exit(object sender, EventArgs e)
{
var settings = IsolatedStorageSettings.ApplicationSettings;
settings["lastSessionEndedUtc"] = DateTime.UtcNow;
settings.Save();
}
private void Application_UnhandledException(object sender, ApplicationUnhandledExceptionEventArgs e)
{
e.Handled = true;
LogError(e.ExceptionObject);
}
}IsolatedStorageSettings.ApplicationSettings is the most reliable place to persist state during Application_Exit because it is a synchronous, local write. Anything relying on a pending network call inside Exit is best-effort only — the plugin can be torn down before an in-flight request completes.
- The plugin loads the .xap, reads AppManifest.xaml, and raises Application.Startup before anything is visible.
- Developers set Application.Current.RootVisual, conventionally to a MainPage instance, inside the Startup handler.
- Application.UnhandledException lets developers catch and log exceptions before they silently crash the plugin.
- The Frame control's Navigated/Navigating events support page-to-page navigation within a single .xap.
- SizeChanged combined with the host page's resize behavior lets layouts adapt to browser window changes.
- Application.Exit gives only a brief, non-guaranteed window to persist state before the plugin is torn down.
- IsolatedStorageSettings.ApplicationSettings is the recommended, synchronous way to persist data during Exit.
Practice what you learned
1. In which event did developers conventionally assign Application.Current.RootVisual?
2. What was the risk of not handling Application.UnhandledException in early Silverlight versions?
3. What was the most reliable way to persist data during Application_Exit?
4. Which events supported page-to-page navigation within a single .xap?
Was this page helpful?
You May Also Like
What Is Silverlight?
An introduction to Microsoft Silverlight, the browser plugin that brought XAML-based UI and a sandboxed .NET runtime to rich internet applications from 2007 to 2021.
Silverlight Project Structure
A tour of a typical Silverlight solution: the application project's key files, the AppManifest.xaml, the .xap package format, and the companion ASP.NET hosting project.
The Silverlight Plugin and Browser Hosting
How the Silverlight browser plugin was installed, embedded into HTML pages, and extended through out-of-browser and elevated trust modes.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics
Microsoft TechnologiesMVVM Design Pattern Study Notes
.NET · 30 topics