In my last Silverlight post, we got all of the Silverlight bits installed.  Now it’s time to build a super simple “Hello world” example and then look at the bits and pieces that go into a basic Silverlight app.  I’ll also compare the wizard-generated Silverlight application with the same application done in WPF.  (See my WPF hello-world samples: part 1, part 2 – Why XAML, and part 3 – Forms and Windows.

Let’s start with the obvious–create a Silverlight project in Visual Studio 2008, using the New Project wizard.  (I’m assuming that you’ve installed everything that you need for Silverlight).

We’re going to use C# and target version 3.5 of the .NET Framework.  You’ll see that there are templates for two different Silverlight project types:

• Silverlight Application
• Silverlight Class Library

Lovely.  We’ll create a simple “Silverlight Application”.

Before the project is actually created, we see a dialog asking us where we want to host our Silverlight Application.  Because Silverlight is a web-based technology, it has to actually be hosted in a web page somewhere.  Visual Studio is willing to generate a new project that will contain the test page.  Here’s the dialog that is shown, when creating a new Silverlight project in an empty solution:

Here’s some more detail on what each of the three options means:

• Add new ASP.NET Web project to the solution – creates a new solution with two projects: your Silverlight Application project and a new ASP.NET Web Application project.  The ASP.NET project will look like a typical new ASP.NET Web Application, except that it will also contain a test .aspx page and test .html page for hosting the Silverlight content.  You can also choose “ASP.NET Web Site” as your ASP.NET project type, rather than “ASP.NET Web Application”.  With a Web Application, you have to rebuild and re-publish a DLL to deploy, rather than having everything compiled dynamically (see this addressed in StackOverflow).  In most cases, you’ll want an ASP.NET Web Application.
• Automatically generate a test page to host Silverlight at build time – In this case, you get a new solution with a single project—the Silverlight Application project.  You don’t have the overhead of a full test project for hosting the Silverlight content.  Instead, when you build the project, you’ll get a test page (TestPage.html) that shows up in your \Bin\Debug or \Bin\Release directory.  The test page is automatically set up to host the Silverlight content from your Silverlight Application project.
• Link this Silverlight control into an existing Web site – This option will be available if you start with a solution containing an ASP.NET Web Application or Web Site and add your new Silverlight project to that solution.  The Silverlight Application project will be created in the existing solution.  The wizard will also offer to create a test page in the existing site (see below).  If you choose to create the test page, you’ll get an .aspx and an .html version, as before.

In general, if you’re starting fresh, you’ll want the first option—Add a new ASP.NET Web project to the solution.

The Project Structure

If we choose the first option, here is what the resulting solution looks like:

So at this point, we have a project for our Silverlight content—HelloSilverlight, and an ASP.NET Web Application project to host the content—HelloSilverlight.Web.

For the moment, let’s focus on the HelloSilverlight project and compare it to its counterpart WPF Application.  Here are both projects, laid out side by side (WPF on the left):

Forms, Windows and Pages

Before we dive into the pieces of the project, there is some interesting terminology to talk about.  In my Hello WPF World, part 3 post, I talked about the difference between a classic Win Forms application and a WPF application.  Under Win Forms, your main window is called a “form”, and this technology goes back at least as far as Visual Basic 3.  (Further)?  With WPF, the terminology changed slightly, in that you’re working with a “window”, rather than a “form”.  And with Silverlight, our main GUI surface is called a “page”.

In one sense, this is just semantics.  Whether we call our main design surface a form, a window, or a page, it’s really just an area of the screen that a user interacts with.  But it’s interesting to think about where these terms come from, especially when thinking about “forms” vs. “pages”.  If we think about paper equivalents to what we’re creating in software, we started creating “forms”—bringing to the computer the process of a human filling out a paper form.  The idea is that they had a sheet with a bunch of empty boxes and they filled in the information.  In the case of a “page”, we inherit the term from the world of web “pages”.  Here the paper equivalent is very different—a page is just a static sheet containing information that you read.

Maybe I’m belaboring the point.  I just find it interesting that in the past we’ve used both “form” and “page” to refer to a user interface surface, and that the corresponding elements in the paper-based world are so different from each other.

In the case of Silverlight, we’re working with “pages”.  We inherit the terminology because we’re writing web-based software, and the web started out serving up static “pages” of content–a very good match for the corresponding real-world idea of a paper page.  But even though Silverlight is presenting a fully interactive user surface–more of a “form”–we’re using the term “page” because of the history.  Perhaps it’s just the case that the term “page” has evolved to mean something new—an interactive and dynamic surface for displaying information and gathering input.

Back to the Silverlight Project

Let’s get back on track and go compare our new Silverlight project to its counterpart in the WPF world.

The Application Manifest

AppManifest.xml is a file that we have in our Silverlight application, but not in the WPF application.  In Silverlight, AppManifest is the application level manifest that describes the constituent DLLs that we are deploying, and their entry points.  In our project, you’ll see that AppManifest.xml is basically empty.  But if you build the application, you’ll see that an AppManifest.xaml file is generated in the output directory.  Looking at AppManifest.xaml, you’ll see that we list one DLL that we are deploying, HelloSilverlight.dll, and that the name of this assembly is “HelloSilverlight”.

So the application manifest is basically a bootstrapper for the Silverlight runtime, telling it which assemblies need to be loaded.  Note that we also still have a manifest inside our HelloSilverlight.dll file, as well.  This is just a standard .NET assembly manifest.

AssemblyInfo

Comparing the AssemblyInfo.cs file in the Silverlight app to its counterpart in our WPF application, they are quite similar.  The obvious difference is that the Silverlight application does not include the ThemeInfo attribute for defining theme-specific resource dictionaries.  As far as I can tell, this is not supported in Silverlight.

Resources

The next difference between the WPF and Silverlight projects is that the default WPF application contains the Resources.resx and Resources.Designer.cs files.  If you haven’t used resources before, the general idea is to move all of your localizable strings from the code out into a resource file and then create a separate resource file for each target language that you want to support.  The appropriate resource file is then loaded automatically at run-time and your code picks up the localized string because it is loading strings from the resource file, rather than the strings coming directly from your XAML (or from the code).

The default Silverlight application project doesn’t have a resource file in the project by default.  You can easily add one, however, and load your strings from the resource file.  It’s not completely clear why the file is not created by default.  Perhaps the goal is just to reduce the size of the final .xap file, since it will be downloaded to the client.  Or perhaps the thinking is that you’d be less likely to want to localize a web-based application vs. a thick client.

Settings File

Similarly, the Silverlight project does not include a settings file (Settings.settings).  In WPF, this is where you would write/read application settings which you want to persist between sessions.  You end up with a configuration file, e.g. Myapp.exe.config, in the same directory as your .exe.  But because the Silverlight control running on the client has no access to the file system, you can’t use .config files as a mechanism for persisting application settings.

Let’s Stop There

This is a good place to stop.  I’ll continue comparing the WPF and Silverlight applications next time and we’ll start looking at what happens at runtime, when rendering the Silverlight control in a browser.