Silverlight Project Structure

Analogy categoryAnalogies

Overview

When you created a new 'Silverlight Application' project in Visual Studio, the wizard typically asked whether to also create a companion web project (ASP.NET Web Application/Web Site or an ASP.NET MVC project) to host it, producing a two-project solution: the Silverlight class library project itself, compiled into a .xap, and a web project whose ClientBin folder received a copy of that .xap along with a generated TestPage.html/aspx wired up with the correct <object> embedding markup for quick local testing.

🏏

Cricket analogy: A two-project solution with a Silverlight app and its hosting web project is like a franchise pairing its playing squad with its home-ground management company, one project handles the on-field talent, the other handles the stadium and ticketing that gets fans, or in this case browsers, into the match.

Key Files in the Silverlight Project

Inside the Silverlight application project itself, App.xaml declared application-level resources and pointed to App.xaml.cs, which contained the Application class with Startup, Exit, and UnhandledException event handlers; MainPage.xaml (with its MainPage.xaml.cs code-behind) was the default root UserControl set as the application's initial visual tree; AssemblyInfo.cs held assembly metadata (version, title, description); and — critically — every Silverlight project included an AppManifest.xaml file at the project root, an XML manifest listing the entry-point assembly and any out-of-browser settings, which got embedded into the compiled .xap package at build time.

🏏

Cricket analogy: App.xaml.cs holding Startup, Exit, and UnhandledException handlers is like a team manager's pre-match briefing, post-match debrief, and emergency injury-timeout protocol, three distinct procedures triggered at different moments of the same fixture's lifecycle.

The .xap Package

A .xap file was, structurally, nothing more than a standard ZIP archive with a renamed extension: it contained AppManifest.xaml at its root, the project's compiled primary assembly DLL, any referenced assembly DLLs not already present in the plugin's built-in cache, and embedded resources such as images or XAML resource dictionaries marked as content. Developers could literally rename a .xap to .zip and open it in any archive tool to inspect its contents, which was a common debugging technique for verifying that a required dependency DLL had actually been included in the build output.

🏏

Cricket analogy: A .xap being a renamed ZIP is like a team's official kit bag looking like any ordinary duffel from the outside, but opening it reveals a specific, structured set of gear, bats, pads, the manifest and DLLs, packed according to a known format.

Solution Layout with an ASP.NET Host

In the standard two-project layout, the web project's ClientBin folder was where the build process copied the freshly compiled .xap after every build, and the generated TestPage.aspx (or .html) in that project's root referenced ClientBin/YourApp.xap via the object embedding markup covered earlier — giving developers an immediately runnable page for F5 debugging directly from Visual Studio, with the debugger able to attach across both the web server process and the Silverlight plugin's managed runtime simultaneously.

🏏

Cricket analogy: The ClientBin folder auto-receiving the freshly built .xap is like a ground staff crew automatically rolling out a freshly prepared pitch before every single practice session, the latest version always ready and waiting without anyone manually setting it up each time.

xml

<!-- AppManifest.xaml — embedded into every .xap package -->
<Deployment xmlns="http://schemas.microsoft.com/client/2007/deployment"
            xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
            EntryPointAssembly="MyApp" EntryPointType="MyApp.App"
            RuntimeVersion="5.0.61118.0">
  <Deployment.Parts>
    <AssemblyPart x:Name="MyApp" Source="MyApp.dll" />
    <AssemblyPart x:Name="System.Windows.Controls.Data" Source="System.Windows.Controls.Data.dll" />
  </Deployment.Parts>
</Deployment>

<!--
Project folder layout (typical two-project solution):
MyApp.sln
  MyApp/                     <- Silverlight application project
    App.xaml / App.xaml.cs
    MainPage.xaml / MainPage.xaml.cs
    AppManifest.xaml
    Properties/AssemblyInfo.cs
  MyApp.Web/                 <- ASP.NET hosting project
    ClientBin/MyApp.xap      <- copied here on every build
    TestPage.aspx
    Web.config
-->

A .xap file is literally a ZIP archive with the extension renamed. You can copy any .xap, rename it to .zip, and open it with a standard archive tool to inspect AppManifest.xaml and the assembly DLLs it contains — a handy trick for diagnosing missing-dependency errors.

A new Silverlight project typically paired with a companion ASP.NET/MVC web hosting project.
App.xaml/App.xaml.cs defines application-level resources and Startup/Exit/UnhandledException handlers.
MainPage.xaml is the default root UserControl serving as the application's initial visual tree.
Every project includes an AppManifest.xaml listing the entry-point assembly, embedded into the .xap at build time.
A .xap is structurally a plain ZIP archive containing the manifest, assembly DLLs, and content resources.
The web project's ClientBin folder receives the freshly built .xap on every compile.
TestPage.aspx/.html is auto-generated with correct <object> embedding markup for immediate F5 debugging.