MDC 2010 Takeaways

I attended the Minnesota Developers Conference (MDC 2010) yesterday in Bloomington, MN.  A nice dose of conference-motivation–some good speakers talking about great technologies.  In the FWIW category, here are my lists of takeaways for the talks that I attended.

1.       Keynote – Rocky Lhotka (Magenic)

General overview of development landscape today, especially focused on cloud computing and the use of Silverlight.  Takeaways:

  • We’re finally getting to a point where we can keep stuff in “the cloud”, access anywhere, from any device
  • Desire to access application data in the cloud, from any device, applies not just to consumer-focused stuff, but also to business applications
  • Smart client apps, as opposed to just web-based, are important/desired – intuitive GUI is how you differentiate your product and what users now expect
  • HTML5 is on the way, will enable smart client for web apps
  • Silverlight here today, enables smart clients on most devices (not iPhone/IOS)
  • Silverlight/WPF is ideal solution.  You write .NET code, reuse most GUI elements on both thick clients (WPF) running on Windows, and thin clients (Silverlight) running web-based or on mobile devices
  • I didn’t realize that I have in common with Rocky: working on teletypes, DEC VAX development, Amiga development. :O)
  • , @RockyLhotka (Twitter)

2.       WPF with MVVM From the Trenches – Brent Edwards (Magenic)

Practical tips for building WPF applications based on MVVM architecture.  What is the most important stuff to know?  Excellent talk.  Takeaways:

  • MVVM excellent pattern for separating UI from behavior.  Benefits: easier testing, clean architecture, reducing dependencies
  • MVVM is perfect fit for WPF apps, very often used for WPF/Silverlight
  • MVVM perfect fit for WPF/Silverlight, makes heavy use of data binding
  • Details of how to do data binding in MVVM, for both data and even for command launching
  • How to use: data binding, DataContext, Commanding, data templates, data triggers, value converters.  (Most often used aspects of WPF)
  • Showed use of message bus, centralized routing of messages in typical MVVM application.  Reduces coupling between modules.  (aka Event Aggregator).   Used Prism version.
  • Slide deck –
  •, @brentledwards (Twitter)

3.       Developer’s Guide to Expression Blend – Jon von Gillern (Nitriq)

Demoing use of Expression Blend for authoring UI of WPF/Silverlight apps.  Also demoed Nitriq/Atomiq tools.  Takeaways:

  • Blend not just for designers; developers should make it primary tool for editing GUI—more powerful than VStudio
  • Lots of tricks/tips/shortcuts – he handed out nice cheatsheet –
  • Very easy to add simple effects (e.g. UI animations) to app elements to improve look/feel, just drag/drop
  • Nitriq – tool for doing basic code metrics, summaries, visualize code, queries that look for style stuff.  (Free for single assembly, $40 for full )
  • Atomiq – find/eliminate duplicate code, $30
  •, @vongillern (Twitter)

4.       Introduction to iPhone Development – Damon Allison (Recursive Awesome)

Basic intro to creating iPhone app, showing the tools/language/etc.  From a .NET developer’s perspective.  Takeaways:

  • You have to do the dev work on a Mac—no tools for doing the work on Windows
  • The tools are archaic, hard to work with, much lower level than .NET.  (E.g. no memory management)
  • In many cases, consider creating web-baesd mobile app, rather than native iPhone.  But then you wrestle with CSS/browser issues
  • Worth considering creation of native iPhone app for the best user experience
  • Lots of crestfallen-looking .NET developers in the audience
  • , damonallison (Twitter)

5.       A Lap Around Prism 4.0 – Todd Van Nurden (Microsoft)

Showing Prism—a free architectural framework written by Microsoft, came out Patterns and Practices group.  Good for creating extensible apps, with plug-in model.  Takeaways:

  • Leverages MEF (Microsoft Extensibility Framework)
  • Good for apps where you have the idea of a lot of “tools” that plug into main application architecture.  Or for applications made up of various building blocks.
  • You write application modules that are decoupled from main app framework, loaded on demand.
  • Prism on Codeplex –

Silverlight 4 Project Types part III – Silverlight Class Library

Last time, I looked at the Silverlight Navigation Application choice in Silverlight’s New Project wizard.  Next, I’d like to look at the Silverlight Class Library choice.  This is next on the list, out of the six different project types that are listed in the New Project wizard when you pick Silverlight as a project type.

Creating a Class Library

What exactly is a class library?  Well, simply put, it’s a library containing the implementation of one or more classes, implemented as a .NET DLL.  The basic idea is to move basic functionality that you’d likely use in more than one place out to a common library that one or more applications can use.

Silverlight lets us easily create a class library that we can then deploy with our actual Silverlight application.  The class library would contain code that we could invoke from our Silverlight application.

Let’s create a basic Silverlight Class Library using the New Project wizard.  Here’s what the dialog looks like:

Once you enter your project name and click OK, you see the dialog shown below.  This is where you get to decide which version of Silverlight you’re targeting. We saw something similar when creating a Silverlight Navigation Application.

For this project, we’ll stick with version 4 of Silverlight.  Keep in mind that if you author a Silverlight 4 project, the client will need to download Silverlight 4.  If you’re curious about what specific changes were made between Silverlight 3 and Silverlight 4, you can take a look at the article:  Ensuring that Your Silverlight Applications Work with Silverlight 4.  Note the “quirks” mode, in which the Silverlight 4 runtime can behave like Silverlight 3, to avoid breaking applications that targeted version 3.

Here’s what the solution looks like, after the wizard creates it.  Pretty simple.

The obvious question is: how is this different from a standard class library, that you might use with Win Forms or a WPF application?  If we just create a standard class library and then compare the project that we get with our Silverlight Class Library,we see basically the same thing–an empty DLL containing a single class.

One real difference that you’ll notice is related to which assembly references are included in the project by default.  Take a look at the projects shown below.  On the left is a standard C# class library.  On the right is a Silverlight Class Library.  (Nevermind that I’ve changed the default class from “Class1” to “Cat”.

You’ll see some similarities and some differences.  The main thing to remember is that the Silverlight project is built against the Silverlight versions of all of these libraries, rather than the standard .NET Framework versions.  You can convince yourself that there is more than one set installed one your machine by looking at the directory “C:\Program Files\Reference Assemblies\Microsoft\Framework”.  Make note of the .NET Framework and Silverlight sub-directories, with various version numbers under each sub-directory.  If you drill down into the sub-directories, you’ll see the actual .NET Framework or Silverlight DLLs.  There is a completely different set of DLLs for each platform.  As an example of the differences, note that there is a System.Windows.Forms.dll in the .NET Framework directories, but not in the Silverlight directories.

One other thing to remember is that even when you see the same file in both .NET Framework and Silverlight directories, the content of the file may be different.  For example, the Silverlight version of System.Core doesn’t include the System.Diagnostics namespace, because for Silverlight, it’s implemented in mscorlib instead.

There is another important difference between the different versions of the framework–the Silverlight versions are much smaller than their full .NET Framework counterparts.  Remember that Silverlight needs to be deployed over the web, so its copy of the Framework is considerably smaller than the full .NET Framework.  If you just look on a system that has both and compare total size of the files in each directory, you’ll see:

  • Version 3.0 of the .NET Framework = 84.4MB
  • Version 4.0 of the .NET Framework = 189MB
  • v3.0 of Silverlight framework = 20.6MB
  • v4.0 of Silverlight framework = 24.6MB

So the Silverlight runtime is only about 13% of the size of the full .NET 4.0 Framework.  Pretty amazing.

Adding Some Code

Now let’s add some functionality to our Silverlight class library.  We’ll create a Cat class that we can later use in our Silverlight application.  Here’s the implementation:

public class Cat
    public string Name { get; set; }
    public string Motto { get; set; }
    public uint NumLives { get; set; }

    public Cat() { NumLives = 9; }

    public void Die()
        if (NumLives > 0)
            throw new Exception("This cat is already dead");


Building the Library

What do we get when we build the library that contains an implementation of our Cat class?  As it turns out, we just get a regular .NET DLL.  Let’s take a look at what shows up in our \bin directory:

Take a look at what’s in this directory.  Using the IL DASM tool (Intermediate Language Disassembler, which can be found in Windows 7 at C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin), crack open the DLL and you’ll see:

We could also look at the manifest for our Silverlight class library and compare it with manifest for a .NET 4.0 version.  If you did this, you’d see that the main difference is the version of mscorlib that they reference.  .NET 4.0 class libraries reference version 4.0.30319 of mscorlib and Silverlight 4 class libraries reference version 2.0.50727.  This could be because of the timing of the Silverlight and .NET 4.0 releases–Silverlight 4 just ended up using the version of mscorlib that shipped with .NET 3.5.  Or maybe it’s the case that Silverlight doesn’t make use of any of the new functionality added to .NET 4.0.

The bottom line here is that both class libraries (.NET 4.0 and Silverlight) are structurally the same–just .NET DLLs.  But they are not interchangeable, because they depend on different versions of various .NET DLLs.

Using Our Class

Now let’s actually use the class that we just created.  We’ll go back to our SilverlightClassLibrary1 solution and add a Silverlight Application project.  We leave the option turned on that automatically generates an ASP.NET Web Application project.

The solution now looks like this:

So we have a web project that loads our Silverlight application and we now want to change the application to make use of our class library.  Specifically, we’ll add some code that makes use of our Cat class.

On the MainPage control in the Silverlight application, we switch to the Events tab in the Properties window and double-click to the right of the Loaded event, to generate an event handler for Loaded.

Next, we add a reference to SilverlightClassLibrary1 in the Silverlight application.  In the Solution Explorer, we right-click the References folder in the SilverlightApplication1 project and select Add Reference.  Then we just click on the Project tab and select SilverlightClassLibrary1.  Now we see the class library show up as a reference in the Silverlight application.

Next, we open MainPage.xaml.cs in the code editor and add a using statement at the top for our class library.   Then we add code to the Loaded event to create a new instance of a Cat.  MainPage.xaml.cs now looks like this:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;
using SilverlightClassLibrary1;

namespace SilverlightApplication1
    public partial class MainPage : UserControl
        Cat _garfield;

        public MainPage()

        private void UserControl_Loaded(object sender, RoutedEventArgs e)
            _garfield = new Cat();
            _garfield.Name = "Garfield Arbuckle";
            _garfield.Motto = "Carpe Catnip";

Now let’s do something with our cat.  We go back to the design surface for the main window, add a new button, change the Content property to “Kill” and then double-click on the button to create an instance of the button’s Click event.  The code for the Click event is pretty simple–we just tell Garfield to die.

private void button1_Click(object sender, RoutedEventArgs e)

Now we’ve created a Cat and we have a button that lets us kill the cat (repeatedly).  As a next step, let’s just add a label on the main page that indicates how many lives the cat has left.  After you drag the label onto the design surface, it will look like this:

Let’s think about the best way to display the number of lives.  One way would be to add a line in button1_Click() that resets the label’s Content property every time we invoke the Die method.  But the drawback of this is that if we have other places in our code that cause our cats # lives to decrement (or increment), we’d have to remember to add code to all of those places to also update the label.  Better than manually updating the label would be to just “bind” it to Garfield’s NumLives property.  We’d like the label to change automatically whenever Garfield’s NumLives property changes.

Doing the data binding involves two main steps.  The first is to specify the binding of the label’s Content property.  We can set up the binding in XAML, specifying the binding Path, which indicates which property of the Cat object we want to bind this label to.  Below is the XAML for our main page, showing both the Button and the Label.  Note the value of the label’s Content property, with the binding path specified.

<Grid x:Name="LayoutRoot" Background="White">
    <Button Content="Kill" Height="23" HorizontalAlignment="Left" Margin="153,69,0,0" Name="button1" VerticalAlignment="Top" Width="75" Click="button1_Click" />
    <sdk:Label Height="28" HorizontalAlignment="Left" Margin="165,26,0,0" Name="label1" VerticalAlignment="Top" Width="63" Content="{Binding Path=NumLives}" />

(For more info on data binding in Silverlight, see this Silverlight Data Binding article in MSDN).

There’s one more thing that we have to do to get the binding to work.  We need to also specify the object that we’re binding to.  In our case, the object is the instance of the Cat that we created in the Load event–Garfield.  We do this by setting the DataContext property of our main page.  Really, we want to set the DataContext property of the Label.  But we can just set the data context for the whole page and then that data context will automatically get used for all controls on the page (if they don’t set their own data context).  This would be handy if we plan on adding other controls later that are also bound to Garfield.  We do this in our Loaded event:

private void UserControl_Loaded(object sender, RoutedEventArgs e)
    _garfield = new Cat();
    _garfield.Name = "Garfield Arbuckle";
    _garfield.Motto = "Carpe Catnip";

    // Set data context of main grid to be our Cat object
    LayoutRoot.DataContext = _garfield;

Now let’s try running our application.  When the Silverlight application starts up in a web browser, it looks like this:

Hey, that looks like success.  Our Label appears to have been bound to the NumLives property, because it’s showing that Garfield has 9 lives.

But what happens when we press the Kill button?  When I try it, nothing happens.  Inside the Cat object, the NumLives property should be decrementing.  And our Label should reflect the new value, since we set up the data binding.  But the label doesn’t appear to be changing.  Why not?

As it turns out, the NumLives property is changing internally whenever we kill Garfield.  But our client–the MainPage–is not being told that the property changed.  So the data binding isn’t fully functional and the label does not update.

We missed one small step when we set up data binding on our Cat object.  To properly bind to an object’s property, we need our Cat class to implement the INotifyPropertyChanged interface and to fire the PropertyChanged event whenever the NumLives property changes.  (For more info on INotifyPropertyChanged, see the MSDN documentation for INotifyPropertyChanged Interface).

To start with, we change our Cat class definition to indicate that we plan to implement the INotifyPropertyChanged interface.

public class Cat : INotifyPropertyChanged

If you try to build the project now, you’ll get an error telling you that you haven’t implemented the PropertyChanged event.  This is because when we inherit from INotifyPropertyChanged, we’re agreeing to a contract that says we’ll implement the interface’s methods.  In this case, it means that we’ll implement the PropertyChanged event.

The easiest way to implement the event is to right-click on INotifyPropertyChanged and select “Implement Interface”.  Then select “Implement Interface” again.

When you do that, you’ll get the following event declaration added to your code:

public event PropertyChangedEventHandler PropertyChanged;

Next, we need some code that will fire this event.  So we create a little method that we can use throughout our class.  I added the following code after the event declaration:

public void OnPropertyChanged(PropertyChangedEventArgs e)
    if (PropertyChanged != null)
        PropertyChanged(this, e);

Finally, we need to fire this event whenever the value of NumLives property changes.  We do this by invoking the OnPropertyChanged method that we just implemented.  We also have to pass the name of the property that is changing when we fire the event.  Here is the updated code for the NumLives property:

private uint _numLives;
public uint NumLives {
    get { return _numLives; }
        _numLives = value;
        OnPropertyChanged(new PropertyChangedEventArgs("NumLives"));

That should be everything that we need to get the data binding to work.

For reference, here is the full source code listing for our Cat class:

using System;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Ink;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;
using System.ComponentModel;

namespace SilverlightClassLibrary1
    public class Cat : INotifyPropertyChanged
        public event PropertyChangedEventHandler PropertyChanged;
        public void OnPropertyChanged(PropertyChangedEventArgs e)
            if (PropertyChanged != null)
                PropertyChanged(this, e);

        public string Name { get; set; }
        public string Motto { get; set; }

        private uint _numLives;
        public uint NumLives {
            get { return _numLives; }
                _numLives = value;
                OnPropertyChanged(new PropertyChangedEventArgs("NumLives"));

        public Cat() { NumLives = 9; }

        public void Die()
            if (NumLives > 0)
                throw new Exception("This cat is already dead");


Killing the Cat

Finally, let’s run our application.  Now when we start up the application and run it in browser, we see the # lives indicator decrement whenever we click the Kill button.  Success!


Let’s look at one more thing.  When we create and use a Silverlight class library and then deploy and run our Silverlight application, what is really going on?  We saw earlier that we’re creating a DLL.  But what actually happens to that DLL when some client hits the web page that hosts our Silverlight Application?

In Windows Explorer, let’s find the project directory and drill down until we see the ClientBin directory under the SilverlightApplication1.Web project.

In ClientBin dir, we see just one file: SilverlightApplication1.xap.  This is the XAP file that represents our Silverlight application and which gets deployed by the web server whenever a client loads the hosting ASP.NET page.

Let’s take a look inside the .xap file.  (Just rename the extension to .zip and double-click to open the .zip archive).  Here’s what we see:

The important components to notice are SilverlightApplication1.dll and SilverlightClassLibrary1.dll.  SilverlightApplication1.dll is the main DLL that contains our Silverlight application (MainPage class, derived from Silverlight UserControl).  SilverlightClassLibrary1.dll is the output of our SilverlightClassLibrary1 project–a DLL that contains our Cat object.  So we see that when our Silverlight application is deployed, the referenced class library is also deployed to the client, since it is included in the .xap file.


Now we’ve seen the main purpose of the Silverlight Class Library.  You can create a separate DLL that contains one or more classes that your Silverlight application is going to make use of, when running on the client.  Since the Silverlight application makes use of the class library, the class library is deployed to the client along with the main Silverlight application.

Silverlight 4 Project Types part I – Silverlight Application

Ok, let’s take a look at the different types of Silverlight applications that you can create out-of-the-box with Visual Studio 2010.  Now that I’ve installed Visual Studio 2010 and Silverlight 4, I want to take a quick spin through each of the different project types that the New Project wizard makes available.

After firing up Visual Studio 2010, I click on the New Project link and then select the Silverlight project type under C#.  Here’s the default list that I see:

  • Silverlight Application
  • Silverlight Navigation Application
  • Silverlight Class Library
  • Silverlight Business Application
  • WCF RIA Services Class Library
  • Silverlight Unit Test Application

I’d like to take a quick look at each project type, looking at the pieces that make up the project and then thinking a little bit about when to use that particular project type.  As I walk through the various project types, I’d also like to think a little bit about the ecosystem in which the Silverlight application lives.  In other words, what other components might you typically create when designing a solution of that type?

I also want to think a little bit about the tooling.  What tools would you typically use to work on the project that you’re creating?  Would Visual Studio 2010 alone be sufficient?  Or would you spend a lot of time working in Blend?  What about SQL Server 2008?

The Silverlight Application

The first project type—the Silverlight Application—looks like it might be the same thing that I created with Visual Studio 2008 and Silverlight 2, back in the Hello Silverlight World, Part 1 post.

The New Application dialog that we see next is very similar to what I saw with Visual Studio 2008 and Silverlight 2.  As before, we have to host our Silverlight application somewhere.

Notice that this time we have one additional project type that we didn’t have before—an ASP.NET MVC Web Project.  So we can basically go with a “classic” ASP.NET web site or an MVC web site.

The default is to host Silverlight in a new ASP.NET web application project.  But if I uncheck the first checkbox, I get a simple Silverlight project with no containing web site:

If you go this route and then press F5 to “run” your Silverlight application, Visual Studio will just create a test .html page in which to host your Silverlight control.

If you take a look at this page, you’ll see a simple HTML page with a familiar <object> tag hosting the Silverlight control.  (See my post on the Lifecycle of a Silverlight Control for more details on how this is done).

If we instead go with the defaults on the New Silverlight Application dialog (host the Silverlight Application in a new ASP.NET Web Application project), we end up with a simple ASP.NET project that contains both .html and .aspx pages hosting the new Silverlight control.

In either case, .html or .aspx, your Silverlight application is embedded in the web page

<div id="silverlightControlHost">
 <object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="100%">
 <param name="source" value="ClientBin/SLApp1.xap"/>
 <param name="onError" value="onSilverlightError" />
 <param name="background" value="white" />
 <param name="minRuntimeVersion" value="4.0.41108.0" />
 <param name="autoUpgrade" value="true" />
 <a href="" style="text-decoration:none">
 <img src="" alt="Get Microsoft Silverlight" style="border-style:none"/>
 </object><iframe id="_sl_historyFrame" style="visibility:hidden;height:0px;width:0px;border:0px"></iframe></div>

As I describedin The Lifecycle of a Silverlight Control, this <div> tag embeds your Silverlight application (control) into a web page using the application/x-silverlight-2 MIME type.  This MIME type now maps to the AgControl.AgControl.4.0 class, implemented in npctrl.dll, which can be found in C:\Program Files\Microsoft Silverlight\4.0.41108.0.

Visually, the pieces of the puzzle look like this (from MSDN article on Silverlight 4.0 Application Services):

So as before, a Silverlight application is managed code that runs in the context of a browser plugin.  Here’s how things work when your browser renders a page containing a Silverlight control:

  • Browser renders HTML  from .html page (or generated HTML from ASP.NET page)
  • Browser sees <object> tag for application/x-silverlight-2 MIME type and fires up the Silverlight plug-in
  • Silverlight plug-in loads the Silverlight core services
  • Silverlight plug-in loads the Silverlight CLR, which creates an AppDomain for your application
  • .xap file containing your Silverlight application is downloaded from the server
  • Your application manifest is loaded/read (from AppManifest.xaml, in .xap)
  • Your main Silverlight application DLL is loaded (from .xap)
  • Silverlight CLR instantiates your Application object and fires its Startup event
  • Your application’s Startup event creates a new instance of your main page (a Silverlight UserControl)
  • Your main page (e.g. MainPage in wizard-generated project) renders itself by reading/loading its .xaml file

Voila.  At the end of all this, you get a Silverlight Application rendered in an ASP.NET web page.  In our case, having generated everything using the Project Wizard, we can just press F5 to run the application–launching a browser window and loading your auto-generated ASP.NET page.  It looks like this (the Silverlight application has the green background):

The XAP Payload

One final topic to cover quickly is–what exactly does the downloaded .xap file contain?  In our wizard-generated test project, you’ll find a ClientBin directory, which contains the compiled Silverlight application in a .xap file.  In our case, it’s named SLApp1.xap.

If you just rename the .xap file as and double-click on it, you can see what it contains:

The main pieces here are the application manifest, which tells the Silverlight runtime what object to start up first, and the assembly in which that object lives.  The .xap file also contains the assembly (SLApp1.dll) that contains our actual code.

The .xap file also contains some dependent DLLs, which are sent down to the client as part of the .xap package.

Wrapping Up

That’s all there is to a basic Silverlight Application.  Next time, I’ll take a look at the Silverlight Navigation Application, which lets us create a complete Silverlight application with multiple pages, rather than a single user control.

Silverlight Gets Full-Fledged Designer Support in Visual Studio 2010

Trying to wrap my head around the current situation with Silverlight 2 and 3 support in Visual Studio 2008 and 2010, I’m confused enough that I feel like shouting out a line from my daughter’s favorite Dr. Suess book, Fox in Socks:  “Now wait a minute, Mr. Socks Fox”!!

It is a little confusing.  But I think I now understand who supports what and I’ll take a stab at jotting it down, for future reference.

Visual Studio 2008 SP1

Visual Studio 2010

  • Supports both Silverlight 2 and Silverlight 3
  • Can install both on the same development machine
  • Each Silverlight project targets one of the two Silverlight versions
  • Silverlight 2 — need to install the Silverlight 2 SDK manually
  • Silverlight 3 — install manually

Ok, as far as I can tell, that’s the current situation.

This basically boils down to two questions:

  • Do I want to develop in Silverlight 2 or Silverlight 3?
    • Silverlight 2 is more stable and is officially released
    • Silverlight 3 (beta) — new controls, navigation framework, out-of-browser support
  • Which version of Visual Studio do I want to use?
    • VS 2008 — easier install experience, stable/released
    • VS 2010 — improved tooling for Silverlight & WPF

The last point is what I want to talk about.  Notice that improved tooling for Silverlight is a feature of Visual Studio, not of Silverlight itself.  Visual Studio 2010 finally gives us full design-time drag-and-drop support for Silverlight.

Let’s see what this looks like.  But first, let’s go back and take a look at the Silverlight design-time experience in Visual Studio 2008.  (I’m using Silverlight 3 here).

The Bad Old Days – Visual Studio 2008 SP1

Until now, Silverlight developers haven’t had the most basic tooling enjoyed by even the lowliest VB6 developers.  Namely — the ability to drag and drop controls onto a design surface and set their properties right in the designer.

Specifically, here’s what you couldn’t do.  If you look at the split window for Silverlight controls in the designer, you’ll notice that the upper pane is labeled “Preview”.

Preview Pane

This was a “Preview” pane because all it could do was to render your XAML on the screen as a preview of how it would eventually look in your Silverlight application.  You couldn’t drag controls onto this surface.  You also couldn’t select any controls in order to reposition them or to set their properties.

In Visual Studio 2008, if you try dragging Silverlight controls onto this Preview window, you just get a big fat “don’t do this” icon.  Even sadder, you can’t select any controls.  If you look at the properties window in Visual Studio, you just see the following sad message:

No Property Editing

Thankfully, you could at least drag and drop controls down into your XAML.  This would at least insert the proper XAML tags for the control that you’d selected.  But you just got an empty tag.  (In the picture below, I’ve just dragged a Button into my XAML).

Drag Into XAML

And, although we weren’t able to set property values in the property editor, there was some consolation in that Intellisense worked in the XAML code.

Intellisense in XAML

So the Silverlight development environment was workable, but not ideal.  Also, you could always author/edit your UIs in Expression Blend.  But then there was a big learning curve to tackle.

Enter Visual Studio 2010

In Visual Studio 2010, we finally have full designer support for Silverlight applications.  In the picture below, I’ve just dragged a Button from the toolbox onto the design surface.

Silverlight Design Surface

It makes me want to weep.  (Who would have thought that a developer would be so happy with being able to drag a button onto a form)?

Not only did the designer let me drag the button onto a design surface, but now it actually gives me a little more than an empty/default Button tag in my XAML.  I actually get a sensibly configured button object, with a reasonable size and a preset label.  Also notice that the upper pane is now labeled “Design”, rather than “Preview”.

But don’t weep yet.  It gets better.  You can actually left-click to select the button in the designer.  When you do this, you’ll see that you can now actually set properties for the button in the property window.

Property Window

Now you may weep or cheer, depending on your particular emotional reaction.

You’ll also notice that you can now click on the little event icon and then double-click to generate event handlers in your code-behind.  (As opposed to using Intellisense in the XAML to discover relevant events).

Event Properties

This is great, although I still don’t understand why there is no dropdown in the properties window to select the individual controls.  Is there a good reason why neither WPF or Silverlight applications allow selecting individual controls from the property window?

Also note that all of the above is possible in both Silverlight 2 and Silverlight 3.

Where Are We?

So clearly, Silverlight is now a full-fledged citizen in Visual Studio, with full tooling.  This may not seem like much, but for anyone who works with Silverlight a lot, it will make a huge difference.  Not to mention a much shallower learning curve for developers coming up to speed with Silverlight.

Mr. Socks Fox wasn’t spouting blibber blubber after all.

Hello Silverlight World, part 3 – The Lifecycle of a Silverlight Control

Ok, continuing with building a simple Wizard-generated Silverlight application and then staring at it to see how it works..  Last time, I talked about the Application object in Silverlight vs. WPF.  This time I’ll continue looking at the pieces in the sample Silverlight application, looking at the Page class that was generated and what happens to this control at runtime on a client machine.

Pages vs. Windows

I pointed out a couple of posts back the interesting difference here, just in the terminology.  In Silverlight, your main design surface is a “page”, which sort of comes from the fact that you’re serving up a series of web “pages” with some content in each.  (Nevermind that a Silverlight control can never be an entire page by itself, but must be hosted in an .html or .aspx page).  In WPF, the main design surface is a “window”, which seems appropriate because it runs in a bordered window.

Silverlight’s UserControl Class

In Silverlight, you render all of your content in a class that derives from System.Windows.Controls.UserControl.  When you use the wizard to generate a Silverlight application, it creates a class named Page, e.g.:

    public partial class Page : UserControl
        public Page()

One other quick thing to look at, is what else we’re doing in our child class at runtime, beyond what we get in the UserControl base class.  If you build your Silverlight application and then look at the other half of the partial class, i.e. the generated code in Page.g.cs, you’ll see:

    public partial class Page : System.Windows.Controls.UserControl {

        internal System.Windows.Controls.Grid LayoutRoot;

        private bool _contentLoaded;

        /// <summary>
        /// InitializeComponent
        /// </summary>
        public void InitializeComponent() {
            if (_contentLoaded) {
            _contentLoaded = true;
            System.Windows.Application.LoadComponent(this, new System.Uri("/SilverlightApplication2;component/Page.xaml", System.UriKind.Relative));
            this.LayoutRoot = ((System.Windows.Controls.Grid)(this.FindName("LayoutRoot")));

So, like our App class that derived from System.Windows.Application, the Page class defines an InitializeComponent method that just calls the static Application.LoadComponent method, which just constitutes an object in question, based on its .xaml.  So for both our App and our Page class, the class is getting instantiated and then InitializeComponent causes it to finish initializing by reading the associated .xaml file and then setting properties and creating child objects based on what is in the .xaml.  This is the magic fairy dust that allows .xaml to work–at runtime, the .xaml is just interpreted and associated objects are created.

The second half of this process is happening at the point where we are setting the LayoutRoot property.  The wizard generated some .xaml for our page that has a Grid as the topmost element, with the name “LayoutRoot”.  Then, at code generation time, we get a Grid object declared and then point it to the object that we loaded from the .xaml.  (Using the FindName method).

Where Are We?

Ok, so we’ve seen that there really isn’t much to our Page class, other than the fact that it constitutes itself from the .xaml.  But what is really going on at runtime, on the client where this control will be hosted?

The Lifecycle of a Silverlight Control

To answer that, let’s just walk through the entire lifecycle of our Silverlight control, starting from how the code is downloaded from the server and continuing on to how the Silverlight runtime on the client’s machine loads and renders the control.

It All Starts With a Web Page


Here’s a diagram from the MSDN documentation that gives us the big picture.  Your Silverlight control runs in a managed environment (the Silverlight Common Language Runtime), which in turn runs in the context of a browser plug-in.  And that plug-in runs in the context of a web page that is downloaded from a web server to the client machine.

Remember that when we created our Silverlight application using the Visual Studio wizard, it also generated an ASP.NET web application in which to host our control.  (e.g. SilverlightApplication1.Web).  If you look at the web application, you’ll see that we’ve been given a couple examples of pages hosting our Silverlight control.  Specifically, you’ll see an .aspx and an .html page.  For now, let’s look at the more basic of the two–the .html page.

If you open this test page, e.g. SilverlightApplication1TestPage.html, and scroll to the bottom, you’ll see an <object> tag that mentions Silverlight:

    <object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="100%"><param name="source" value="ClientBin/SilverlightApplication1.xap"/><param name="onerror" value="onSilverlightError" /><param name="background" value="white" /><param name="minRuntimeVersion" value="2.0.31005.0" /><param name="autoUpgrade" value="true" /><a href="" style="text-decoration: none;">
            <img src="" alt="Get Microsoft Silverlight" style="border-style: none"/>

What we see here is a standard HTML <object> tag, which allows us to embed a 3rd party plug-in into the browser on the client’s machine.  When rendering the web page, the browser will set aside an area of the page and let the plug-in render directly to that area.  In this case, the 3rd party is Microsoft and the plug-in is Silverlight.

So here’s how things get rolling with our Silverlight control, on the client’s machine (whoever is pointing their browser at your .html page):

  • Client starts up their browser and points it at SilverlightApplication1TestPage.html (let’s assume that the test page is on a web server somewhere)
  • The .html page is downloaded from the web server to the client and the browser begins rendering the HTML content
  • The browser reaches the <object> tag, which indicates that a plugin should be loaded, started up, and allowed to render that part of the page
  • To figure out how to call the plugin, the browser uses the value of the type attribute on the object tag.
  • In our cases, this type is application/x-silverlight-2.  This is a MIME type, which maps to Silverlight 2
  • Using the MIME type, the browser loads the plugin
    • Under Windows, there is a registry entry that associates this MIME type with an ActiveX control named AgControl.AgControl, which in turn is implemented by a DLL npctrl.dll, located in C:\Program Files\Microsoft Silverlight\2.0.40115.0
    • So npctrl.dll is the actual plugin implementation–an unmanaged Windows DLL that implements the plugin API and, in turn, launches the Silverlight CLR–the execution environment in which your Silverlight control actually runs

Ok, if you were paying attention, you may have noticed something surprising in that last bullet point:  ActiveX??  Isn’t ActiveX dead and buried, now that we’re dealing with a managed environment?

Well, yes and no.  The code that we are authoring–our Silverlight control–does run in a managed environment on the client machine, in that it runs inside of the Silverlight CLR/runtime.  But the Silverlight plugin itself has to interact with the web browser and, as such, is unmanaged code that implements that standard browser plug-in API(s) that allow it to run within the browser.

So clearly, npctrl.dll is unmanaged code.  But ActiveX?  The MSDN documentation is not 100% clear on this point, but here’s what I think is going on.  npctrl.dll is both a classic Win32 DLL (non-COM), as well as an ActiveX control (COM server).  Which mode it runs in depends on the browser.   When running inside of Internet Explorer, the plug-in runs as an ActiveX control, implementing the IXcpControl COM interface.  However, when Silverlight is hosted in other browsers, like Mozilla, it implements the Netscape Plug-in API, running as a classic Win32 DLL.  (It implements functions like NP_Initialize and NP_GetEntryPoints).  [This paragraph is mostly conjecture].

Silverlight Presentation Core


Within the Silverlight plug-in, the next layer to take control is the Silverlight Presentation Core.  You can see the Presentation Core as the bottom blue box in this diagram (also found in MSDN documentation).

The Presentation Core is responsible for rendering everything in the browser, handling user interaction, playing video, and parsing XAML.  It’s implemented in agcore.dll, which is a classic Win32 DLL.  (Not a COM server and not a .NET executable).

When your browser starts up (in Firefox, at least), both npctrl.dll (Plug-in) and agcore.dll (Presentation Core) are loaded.  The remaining Silverlight runtime libraries described below are only loaded when you actually load a page containing a Silverlight control.

Silverlight CoreCLR

After your browser has loaded the Silverlight plug-in, it does three basic things:

  • Starts up the Silverlight Common Language Runtime
  • Downloads the .xap file containing your Silverlight control and Application object from the server
  • Instantiates your Application object and loads it

The CoreCLR, or Silverlight Common Language Runtime, is the Silverlight version of the CLR that runs inside the Silverlight plug-in.  (Labeled CLR Execution Engine in the above diagram).  This is the managed environment that your Silverlight applications run inside, similar to the CLR that hosts thick-client .NET applications.

The CoreCLR is implemented in coreclr.dll, also in C:\Program Files\Microsoft Silverlight\2.0.xxxxx.0.  The CoreCLR is based on the same codebase as the desktop version of the CLR, but much smaller, and with features not required in a browser environment removed.  (In the desktop world, the equivalent DLLs are mscoree.dll and mscorwks.dll).

Note: coreclr.dll is also just a “plain old” unmanaged Win32 DLL.  It is the implementation of the .NET CLR, so it does not run in a managed environment itself.

The XAP File

Before Silverlight can run any of your code on the client machine, it has to download it from the server.  Your Silverlight application is packaged into a .xap file.  The .xap file is nothing more than a .zip file that has been renamed.  You can prove this to yourself by building your application and then renaming the resulting .xap file as a .zip file.


If you look at the files inside your .xap, for a typical wizard-generated Silverlight application, you’ll find two files:

  • AppManifest.xaml
  • SilverlightApplication1.dll

The AppManifest.xaml file is the application manifest, which tells the Silverlight runtime what DLLs are present in this package and which one contains the entry point, or startup object, for your Silverlight application.  For example, you might see something like the following:

<Deployment xmlns="" xmlns:x=""
    <AssemblyPart x:Name="SilverlightApplication1" Source="SilverlightApplication1.dll" />

Note that the manifest tells Silverlight to load the assembly located in SilverlightApplication1.dll and that the startup object is SilverlightApplication1.App, which is the class that derives from System.Windows.Application.

Starting Up

Once the .xap file is downloaded, the CoreCLR can instantiate your object and get things started.  It does this by:

  • Instantiating an instance of your entry point type, e.g. SilverlightApplication1.App
  • Firing the Application.Startup event

Our wizard-generated Silverlight application included wizard-generated code to get everything up and running as follows:

  • During the App constructor
    • Wire a handler for the Application.Startup event
    • Call App.InitializeComponent
  • App.InitializeComponent, also wizard-generated :
  • The handler for the Application.Startup event
    • Instantiates a new Page object  (the actual Silverlight control to be displayed)
    • Sets the RootVisual property of the parent App object to point to the Page
  • During the Page constructor
    • Call Page.InitializeComponent
  • Page.InitializeComponent
    • Calls Application.LoadComponent, reconstituting the Page object from the associated XAML (BAML)

That’s really all there is to it.  At this point, through the magic of the browser plug-in architecture and the fact that the Silverlight CoreCLR is running on the client’s PC, you have a native .NET (Silverlight) application running on the client, hosted in the browser.


Debugging Silverlight Applications with windbg and sos.dll – 21 Aug 2008 – Tess Ferrandez
Debugging Tools and Symbols: Getting Started – Windows Hardware Developer Central
Dissecting Silverlight – 1 May 2007 – Ed Burnette
Setting a Silverlight 2 Startup Breakpoint Using WinDBG – 10 Jan 2009 – David Betz
Silverlight Application Services – MSDN
Silverlight Application Structure – MSDN
Silverlight Architecture – MSDN
Silverlight Plug-In Object Reference – MSDN

Hello Silverlight World, part 2 – The Application Object

In my last Silverlight post, Hello Silverlight part 1 – Generating the Project, I started creating a Silverlight-based Hello World application.  I described the various pieces that get created by the Project Wizard in Visual Studio 2008.  I also started comparing the Silverlight application to a wizard-generated WPF application.

Let me continue looking at the individual pieces that make up a bare-bones Silverlight application.  Maybe the convention should be to call it a “Silverlight control”, since that seems a bit more accurate.  For now, I’ll stick with Visual Studio’s terminology and call it a “Silverlight application”.


Like our WPF application, the main entry point of the Silverlight application is described by the App.xaml / App.xaml.cs files.  In both WPF and Silverlight, these files define a subclass of System.Windows.Application, which serves as the main object loaded at runtime.

In both WPF and Silverlight, we can look at the code in App.xaml.cs and App.g.cs (generated at build time) to get a sense of how the application gets loaded and run.  What we see is very different behavior, despite the fact that both App classes appear to derive from System.Windows.Application.

In the WPF application, here’s what happens:

  • There is an entry point named Main()
  • Main()
    • Creates an instance of the App class
    • Calls the InitializeComponent method of the App object
    • Calls the Run method of the App object
  • App.InitializeComponent
    • Sets App.StartupUri property to point to a Uri object pointing to Window1.xaml, our main window

In the Silverlight application, something very different is going on at startup:

  • There is no Main() method
  • The App constructor
    • Wires up the Application_Startup event handler to the App.Startup property
    • Wires up the Application_Exit event handler to the App.Exit property
    • Wires up the Application_UnhandledException event handler to the UnhandledException property
    • Invokes InitializeComponent
  • Application_Startup
    • Instantiates a new Page object (the class for our main page)
    • Sets App.RootVisual to point to this page object
  • InitializeComponent
    • Calls Application.LoadComponent, passing it a new Uri object pointing to App.xaml

Why is the startup behavior so radically different, between WPF and Silverlight, given that the main application appears to be inherited from System.Windows.Application in both cases?

The answer is that, while the class name and namespace are identical, the Application object in Silverlight is a very different animal than the one that is part of WPF.  Remember that the WPF application is running against an entirely different .NET Framework than the Silverlight application.  WPF is referencing/using the full .NET Framework 3.5 (with pieces from 2.0, 3.0 and 3.5), while the Silverlight application is referencing/using the Silverlight Framework, which is an entirely different set of libraries.  While much of the Silverlight framework is a subset of the WPF framework, the Application object is entirely different.

  • In WPF, the System.Windows.Application class lives in PresentationFramework.dll
  • In Silverlight, System.Windows.Application lives in System.Windows.dll

PresentationFramework.dll is part of the .NET Framework 3.0 and exists on a  client system when they install the full .NET Framework (3.0 or 3.5).  System.Windows.dll is part of the Silverlight framework and exists on a client system when they install Silverlight.

You can see this by reading the documentation (MSDN).  Or you can see how different these Application classes are by doing the following:

  • In the WPF application, open the App.xaml.cs file, right-click on Application and choose Go To Definition
    • You’ll see that the Application class has a Run method and a StartupUri property, but no RootVisual property
    • Now hover over the tab for this window in Visual Studio–you’ll see a temp filename that contains the name “PresentationFramework.dll”
  • In the Silverlight application, open the App.xaml.cs file, right-click on Application and choose Go To Definition
    • You’ll see a very different Application class, with a RootVisual property, but no Run method
    • Hover over the tab again–you’ll see a temp file name containing “System.Windows.dll”

Let’s Stop Here

That’s a good stopping point, for now.  We’ve looked just a little bit under the covers in the Silverlight application–enough to see that the main Application object loaded at runtime is very different from the object loaded in the WPF application.

Learning Out Loud

I’ve always sort of figured that this blog was a place to post things I was just learning, rather than a place to publish tutorials about technologies that I have more expertise in.

Because of the nature of our field, and the amount of new technologies that are always coming out, I’m far more interested in learning than I am in teaching.  There are already plenty of great teachers out there who are blogging, writing or lecturing.  I don’t really aspire to sell myself as a teacher of technologies—that would take far too much time and energy.

Instead, I see this blog as a forum for my attempts to learn new technologies—e.g. WPF and Silverlight.  I’m always looking for new ways to motivate myself to learn new technologies and having a blog is a good way to force myself to dive in and start learning something new.  When I realize that I haven’t posted anything for a few days, I feel the urge to start pulling together the next post.  Then, because I know I’m going to have to write about it, I find that I force myself to explore whatever the topic is in a much deeper manner than I would if I were just reading a book or attending a class.

This has been working out great so far.  I’m discouraged by how little time I have to study these new technologies.  I’d like to post far more frequently than I do.  But at least I’m gradually learning some new bits and pieces, about technologies like WPF and Silverlight.

Reminding myself of my goals also helps me to just relax and not worry so much about making mistakes.  I’m just capturing on “paper” what I’m learning, as I learn it.  Since I’m only beginning the journey of grokking whatever it is, I don’t need to worry about whether I get it right or not.

Remembering all of this led me to change the tagline of this blog.  Instead of offering up my thoughts on various topics, I now see this as “learning out loud”.  That perfectly describes what I think I’m doing—learning new stuff, stumbling through it, and capturing the current state of my knowledge so that I can come back and refer to it later.

So let the journey continue—there’s still so much to learn!

Hello Silverlight World, part 1 – Generating the Project

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

Project wizard

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:

Hosting Options

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.

Link to Existing Site

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):

WPF Vs Silverlight

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.


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.


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.

Why Can’t I Drag Silverlight Controls into the Designer?

We’re all spoiled.  For years, we’ve been able to drag/drop controls onto a design surface in Visual Studio and then write the code-behind.  Traditionally, our world has consisted of these two things–the design surface and the code-behind.

But with WPF and Silverlight, we really have three views: the design surface, the XAML code that defines the visual layout, and the code-behind.

When working on WPF projects then, you typically have a split window where you can work in either the design surface or the XAML code.  You can drag controls from the toolbox onto the design surface and the changes are reflected immediately in the XAML.  Conversely, you can edit the XAML and see changes on the design surface.  It looks like this.

WPF Designer

This is beautiful.  You can work in the classic drag/drop paradigm to quickly gen up your GUI.  And then you can tweak things in the XAML, or the property editor.  Life is good.

Silverlight – Something’s Missing!

But there is a bit of a difference when you’re working with Silverlight projects.  Take a look at that same split designer view:

Silverlight Designer

Notice the difference?  “Preview”, rather than “Design”.  You’ll also notice right away that you can’t drag controls onto the design surface.  Argh, I can’t live without drag/drop—these are habits that I picked up back in the days of VB3!

Relax.  Turns out that you can still drag/drop into the XAML, and your changes will be reflected in the Preview window.  The Silverlight designer is different from WPF in that this window is a read-only view of your GUI, rather than a directly-editable designer.  The other bad news is that there is no property window when editing Silverlight XAML, whereas there is when you’re working with the XAML in a WPF application.

You can read all about the Silverlight designer and its limitations here: Silverlight Tools for Visual Studio 2008 Designer Support

While this isn’t ideal, it’s workable.  Perhaps we’ll see the ability to edit directly on the design-surface in future versions of Visual Studio.  Being a newer technology, it’s sensible that Silverlight lags a bit behind WPF in terms of tooling support, in the same way that WPF seems to still lag a bit behind Win Forms.

Silverlight, Day 1 – Installing Everything

Silverlight is the new framework for delivering rich client functionality in a web browsers.  It’s an important architecture to consider when thinking about creating a new application–along with WPF (classic thick client) and ASP.NET/AJAX (thinner client).  The three framework choices–WPF, Silverlight, and ASP.NET/AJAX–live on different spots on the thick-to-thin client continuum.  Each is a valid choice as a framework for creating an application, depending on the customer or the needs.  Which one you choose depends on what the customer goals are.  It’s also possible to craft a solution that is a mix of one or more technologies–e.g. Silverlight controls as part of a broader ASP.NET site.

Given what I think is Silverlight’s importance in the Microsoft ecosystem, I think that it’s important for all Microsoft (or .NET) developers to be at least a little familiar with the platform.  So here’s a step-by-step recipe for getting a Silerlight development environment set up on your machine.  I’ve been setting up a new VM over the past few days that will be my “virgin” Silverlight development box.  There’s a lot to be said for just starting fresh and installing exactly what you need—no more, no less.

This has been written about at length at the site–how to get started with Silverlight.  But I thought it worth doing a post that walks through the exact steps required.

Virtual Machines and the Windows 7 Taskbar

As always, creating a new VM makes me feel all fresh, clean and wonderful.  I’m using VMware 6.5.1, which I really love.  I created a 32-bit bit VM and installed the Windows 7 beta that was just released last week (build 7000).  I can’t say enough good stuff about Windows 7, from what I’ve seen so far.  The performance is incredibly snappy, even in the VM, with 1GB of virtual memory.  The boot time is lightning fast.  And, with a little tweaking, I’m now really enjoying the new taskbar (the “superbar”).  I’m not remotely a Vista hater (I’ve been running it on all my home machines forever), so I wouldn’t call Window 7 “the Windows that Vista should have been”.  Vista has been great for me.  But Win 7 takes Vista and just pushes it a bit further, improving various things.

Just as a quick side note, here is the tweak that I made to the taskbar behavior, after hearing Paul Thurrott talk about this on Windows Weekly.  As Paul said, this should really be the default behavior.

Here’s how the taskbar looks out of the box.

Default Taskbar

Each button on the taskbar (in this case) represents a running application, which may contain one or more instances/windows.  What’s confusing about this is that you need to first click on an icon to get a popup of the individual windows.  Paul recommends, and I very much prefer, changing the default look and feel so that taskbar buttons are not grouped.

Here’s where you set the option, under Taskbar properties:

Change Taskbar

Notice that the default Button grouping setting is “Always group”.  If you change it to “Group when taskbar is full” or “Never group”, the taskbar then looks like this:

Better Taskbar

This is much nicer, because: a) you can click on individual windows, if more than one instance of an app is running and b) the text that is displayed makes it much easier to find what you’re looking for.

(Note: These screen grabs are actually from the M3 build distributed at PDC in Oct, 2008.  In the Jan, 2009 beta, you won’t see the Quick Launch icons).

Ok, enough fauning over Windows 7.  Let’s move on to installing all the Silverlight bits.

The Plan

The site has a nice Getting Started post listing the bits that you need to install, to get Silverlight fully functional.  [Note: Throughout this post, and from now on in my life, whenever I say “Silverlight”, I always mean “Silverlight 2”].  Here’s what the list looks like:

Getting Started with Silverlight

I’ll work through this entire list, to get everything installed.

Oh by the way, I’m assuming that you’ve already installed Visual Studio 2008 SP1, which also includes the .NET Framework 3.5 SP1.

Visual Studio 2008 SP1

Installing Silverlight Tools for Visual Studio 2008 SP1

To start with, we download and install Silverlight Tools for Visual Studio 2008 SP1.  This is version 9.0.30729.146, released on 10/30/2008.  The download is 72.7MB.

Download the Silverlight_Tools.exe file and launch it.


Soak up the EULA:

License Agreement

At this point, the install may tell you that there are processes running that you need to shut down:

Incompatible Processes

After closing Firefox, I click the Refresh button and now get a clean bill of health:

No Incompatible Processes

The install then starts:

Install Progress

And we’re done.

Silverlight Install Complete

At this point, you’ve installed:

  • Silverlight 2 developer runtime  (2.0.31005.0)
  • Silverlight 2 SDK  (2.0.31005.0)
  • KB956453 for Visual Studio 2008 SP1
  • Silverlight Tools for Visual Studio 2008 SP1

You can find an installation log file at:  C:\Users\myname\AppData\Local\Temp\Silverlight%20Tools%20RTW_20090108_121446406.html .  It also contains hyperlinks to the textual MSI log files for the different products installed.

Silverlight 2 DataGrid Update

Next, you’ll want to download and install the Silverlight 2 DataGrid December 2008 Release, released on 12/19/2008.  This release apparently fixes a number of bugs with the DataGrid.

Expanding on the instructions on the download page, here are the steps:

  1. Close all instances of Visual Studio 2008
  2. Run SL2DataGridDec08.exe to extract the files
    Extract Files
  3. Delete all cached toolbox items by removing all files beginning with “toolbox” from C:\Users\UserName\AppData\Local\Microsoft\VisualStudio\9.0.
    Delete Toolbox Files
  4. Replace the following assemblies with the ones in this package:

    • %ProgramFiles%\Microsoft SDKs\Silverlight\v2.0\Libraries\Client\System.Windows.Controls.Data.dll
    • %ProgramFiles%\Microsoft SDKs\Silverlight\v2.0\Libraries\Client\System.Windows.Controls.Data.Design.dll

Installing Expression Blend 2

Next on the agenda is downloading and installing Expression Blend 2—the tool used for designing Silverlight and WPF GUIs.  Expression Blend 2 supports Silverlight 1.0.  SP1 for Expression Blend 2 (see below) adds support for Silverlight 2.0.

I’m installing a full version that I get through the Empower ISV program.  The link above will take you to a page where you can download a 30-day trial version.  You can purchase the full version from Amazon for roughly $479, or upgrade from Expression Blend 1 for $95.

This is version 2.0.1523.0.

Wow, snazzy install screen—exactly what you’d expect for a design-focused tool.

Installing Expression Blend

By the way, the Expression family consists of the following different tools:

  • Expression Web ($245) – for designing web sites  (think Front Page replacement)
  • Expression Blend ($479) – for creating WPF and Silverlight user interfaces
  • Expression Design – graphical design tool (partner tool for Blend, adding some add’l drawing capabilities)
  • Expression Media ($186) –  for organizing your media (assets)
  • Expression Encoder ($190) – for producing webcasts and publishing via Silverlight

You can get the whole lot—Expression Studio 2—for $666.  [Odd number to use for a retail price].

Decide where to install Blend:

Install Location

And off we go..

Blend Install Starts

Blend 2 is now installed.  But wait!  If you’re running on a VMware VM, don’t try running it yet.  It appears that the Expression products don’t run properly in VMs if 3D graphics acceleration is enabled.  Shut down your VM and disable 3D graphics acceleration (go to Settings, select your Display, look for the “3D graphics” section and uncheck “Accelerate 3D graphics (DirectX 9.0c).  Expression Blend was locking up my VM, but when I disabled 3D graphics acceleration, everything started working fine.

Install Expression Blend 2 Service Pack 1

Next you’ll want to install the service pack for Expression Blend 2 that adds support for Silverlight 2.  You can find it here: Expression Blend 2 Service Pack 1.

Note that this service pack replaces the Expression Blend 2.5 June 2008 Preview (which existed to support beta Silverlight 2 functionality).  So you don’t need Blend 2.5.

The service pack is small (18MB), and downloads and installs quickly.  The listed version is 2.1.1760.0.  So perhaps we can think of what we end up with as Blend 2.1, rather than Blend 2 or Blend 2.5.

Blend 2 Service Pack 1

Install Deep Zoom Composer  (optional)

Next on the Getting Started list is to install Deep Zoom Composer.  Deep Zoom is a technology built on top of Silverlight that allows you to publish a very high resolution image on a web site and allow zooming way into the image.  This is done by pre-processing the image to generate many different chunks of the image at many different resolutions.  You then publish all of these files to your server and visitors to your site can then zoom in and out of the original high-res image.

For an example of Deep Zoom in action, take a look at this collage of photos of my Dad.  I started with 191 different images and, after running everything through Deep Zoom Composer, ended up with 18,433 unique images on my server, taking up about 1.5GB of space.  The end result is pretty cool.  There’s another excellent example of Deep Zoom in action at the Hard Rock Memorabilia web site.

This step is optional because you’ll only want/need the Deep Zoom Composer if you intend to author some Deep Zoom images.  You can find the download for Deep Zoom Composer here: Deep Zoom Composer.  This is also small (4MB).  It’s listed as version

For completeness, here’s the install sequence (which is pretty brainless):


Note–when selecting an install location, I also set it up so that Everyone on the machine can run it.  That’s just my preference.


Confirm that you’re ready to start the install:


And we’re done.  Note the mention of checking for updates to the .NET Framework.  If you’ve followed all of the steps above, there should be no framework updates.


Install the Silverlight Toolkit

Finally, you’ll want to install the latest version of the Silverlight Toolkit.  This is a collection of Silverlight controls (announced/released during the PDC in Oct 2008) and other goodies that the team has made available on codeplex.  The components have different levels of quality, depending on where in the release cycle they are.  But this is all stuff that is intended to eventually find its way into the mainline Silverlight product/release.  For more information on what’s in the Silverlight Toolkit, see Shawn Burke’s blog post.

You can download the Silverlight Toolkit here: download Silverlight Toolkit.  The current version was released on 9 Dec 2008.

The toolkit will come down as a .zip file.  There’s nothing really to install.  The idea is to unzip everything to a location of your choice and then just add references from your projects to the appropriate assemblies.

If you want to just play around with the controls, there’s a nice sample project included in the distribution, at \Samples\Controls.Samples.html — just open up the HTML page and you’ll be able to see and interact with the various controls.

Here’s a quick overview of how you make use of these controls from your Silverlight project.  Assume that we’ve already unzipped everything to \My Documents\Silverlight Toolkit.  Now fire up a new Silverlight project.  Once you’ve loaded the project, you’ll want to add the various controls to your toolbox, as follows:

Right-click in the Toolbox and select Choose Items.

Choose Items

In the dialog that comes up, go to the Silverlight tab and then click Browse.  Locate one of the assemblies from the Silverlight Toolkit and click the Open button.  The controls from that assembly will now show up in the dialog.  (And, if checked, in your Toolbox):

Silverlight Components

For example, notice that we now have the AutoCompleteBox in our toolbox:


Wrapping Up

That’s really all there is to it.  Once you’ve followed all of these steps, you have all of the Silverlight bits and are now ready to create great Silverlight applications!

Session – Silverlight Controls Roadmap

PDC 2008, Day #3, Session #2, 45 mins

Shawn Burke
Product Unit Manager
WPF/Silverlight Controls Team, Microsoft

Shawn Burke gave a short talk on the new controls being released this week in the Silverlight Toolkit, on Codeplex.

He started by outlining the general strategy for releasing controls toolkits like this one:

  • Focus on controls for both WPF & Silverlight
  • Ship out of band from major releases
  • Ship w/source code
  • Fold best (and most popular) controls back into the mainline product

I also appreciated that Shawn outlined the idea of “quality bands”.  Every control goes through a lifecycle, where it passes through various quality bands before eventually making it into the mainline product:

  • Experimental
  • Preview   (team is committed to it)
  • Stable  (equivalent to Beta—feature-complete)
  • Mature   (bugs are fixed)

This is great—because the team doesn’t have to wait for the entire toolkit to reach a particular quality level before releasing it to the public.  Instead, they can assess the quality of each control and then make that known.

WPF Parity Controls

Some of the controls included in the toolkit are “parity” controls—i.e. controls that are already in WPF and now being added to Silverlight.  They include:

  • DockPanel
  • Expander
  • TreeView

DockPanel (Stable)

A DockPanel control allows docking child elements to one side of the container.  The last child can be made to fill the remaining space in the container.

Expander (Preview)

The Expander allows display overview and details information, with the details view showing when the user clicks on an expander widget.  You can also change the direction that the content expands to (the default is Down).  The first image below shows the default state—content not yet expanded.  When the user clicks on the expander icon, the Content appears and the icon changes to show an up arrow.

TreeView (Stable)

Shawn indicated that the TreeView was by far the control mostly frequently asked for by users.  It’s behavior is quite familiar—presenting hierarchical data in a dynamic way and allowing the user to expand/collapse the various nodes.

What’s very cool is that the individual nodes in the tree can be basically anything, and fully styled.

New Non-WPF Controls

Shawn mentioned a series of controls that are brand new—i.e. not yet in WPF either.

  • AutoComplete
  • Charting
  • NumericUpDown

AutoComplete (Preview)

Auto completion is a pretty standard feature on the web.  The idea is to do some data lookup while a user types and then display relevant/possible matches to what they are typing.  The cool thing is that the content displayed can be nearly anything.  Shawn demonstrated having a DataGrid show up to display selected data.

Here’s another example, showing some nice styling:

Charting (Preview)

Shawn ran some pretty amazing charting demos, showing charts on a web page updating in real-time.  He said that Microsoft partnered with Dundas, long-time vendor of charting controls, to gain some expertise in the area.

Here are some samples:


There are some wonderful goodies in this new set of Silverlight tools.  It’s clear that as time goes by, Silverlight will just continue to become more mature and the set of controls will continue to grow—in both WPF and Silverlight.

Original Materials

You can find video of Shawn’s presentation at:

You can play with “live” samples of the various controls at:

Charting samples can be found at:

Session – Deep Dive: Building an Optimized, Graphics-Intensive Application in Microsoft Silverlight

PDC 2008, Day #2, Session #4, 1 hr 15 mins

Seema Ramchandani

The final session of the day was all about optimizing graphics-based Silverlight applications.  The talk was a little bit different from what I expected.  I was imagining it being about how to do custom 2D graphics.  Instead, it was more geared at understanding the underlying rendering loop and optimizing basic animations.

Seema is a Program Manager in the Silverlight group and described her job as being focused on performance.  She is the person, she explained, that people call when they can’t figure out why their Silverlight application is running so slowly.

The Dancing Peacock

Seema’s first real-world story gives us a new term that we can use in assessing application performance:

The Dancing Peacock = the portions of your application that are consuming resources, but not contributing to the user experience in any meaningful way.

The story goes something like this.  Someone called up Seema and said that they had a very poorly performing Silverlight application and they could not figure out why it was so slow.  Seema took a look at it and started removing elements to understand which element was contributing to the performance degradation.

What she found, under all of the visible controls, was a giant full-screen animated dancing peacock.  It was being rendered, because it was behind all of the other windows, but the designer had left it in the XAML code, figuring that it wasn’t doing any harm.  But as it turns out, code to calculate all of the peacock’s dance steps was still running in the background—and dragging the entire application down.

So Seema’s basic message throughout the talk was—look for the dancing peacocks in your application and remove them.

The Graphics Pipeline

Seema argued that it was important to fully understand how the graphics pipeline in Silverlight works.  If you understand the full sequence of what happens to render graphics to the screen, it can greatly help you in debugging the source of any performance problems.

She showed a fairly detailed diagram of the rendering loop and walked through all of the steps, explaining what happens at each point.

Tips / Tricks

Seema also presented miscellaneous tips and tricks for improving performance.  Without going into details, some of the basic ideas were:

  • Blend in as small a region as possible
  • Mitigate blurry text with UsesLayoutRounding
  • Avoid large-scale animations  (costly)
  • Don’t plug up your UI thread with costly operations
  • Avoid video resizing by encoding at the desired resolution
  • Simplify XAML – avoid bloat


Seema also demonstrated a very useful tool that you can use for profiling Silverlight applications.  She described using a tool called XPerf, which using Event Tracing for Windows to exactly measure the amount of time spent in each module of the underlying native code.

XPerf can be used for debugging, but is most powerful as a way of comparing alternative designs, to see how they impact performance.

Session – Microsoft Silverlight Futures: Building Business Focused Applications

PDC 2008, Day #2, Session #3, 1 hr 15 mins

Jamie Cool

In the Silverlight Futures session, Jamie Cool focused on building business applications using Silverlight.  (From now on, when we say “Silverlight”, we really mean “Silverlight 2”).

Jamie started by summarizing the whole thick/thin client thing and reiterating where Silverlight fits in.

  • WPF apps run natively on your PC
    • Richer UI experience
    • Better performance
    • Access to everything on your PC, e.g. file system
  • ASP.NET web apps run in the browser
    • Broadest reach, running on any platform, any browser
    • Much more limited UI
    • Runs in a sandbox, limited access to local resources
  • Silverlight is somewhere in the middle
    • Runs in your browser
    • Much better user experience than ASP.NET
    • Fewer trips back to server, things running on client
    • Requires client to first download Silverlight runtime

People who write business applications hear requests all the time for accessing their apps through a web browser.  In the past, this has meant a radically different and more limited GUI in the form of ASP.NET.  But with Silverlight, you can really have it all—deliver both rich WPF applications and browser-based applications using Silverlight.  Because Silverlight uses a subset of the .NET Framework, you can even use the same codebase.  (If you’re careful).

Support for Business Apps Using Today’s Platforms

Much of Jamie’s talk focused on a future extension to Silverlight, code-named Alexandria, that would provide a richer framework for allowing business apps hosted in Silverlight to do the kinds of things that they typically need doing.

According to Jamie, business applications have the following characteristics:

  • They are mainly focused on working with data and applying business logic to data
  • They need
    • A way to move data between tiers
    • Methods for “shaping” data
    • Methods for soundly applying business logic to the data
    • A way to bind data to the user interface

In terms of moving data between tiers, Jamie mentioned ADO.NET Data Services as really being the best tool for exposing data stored in a database to a web-based application.  He mentioned the same speaking points as the guys in the Astoria talks—the ability to expose/consume data using simple a REST protocol.

Jamie also demoed how the Entity Data Model could be used a data layer between the database (or data service) and the application.  He also demoed some of the basics of binding Silverlight controls to the data served up through ADO.NET Data Services.

Futures – A Business Logic Framework

The second half of Jamie’s talk focused on a future extension to Silverlight, code-named Alexandria, that would provide a richer framework for allowing business apps hosted in Silverlight to do the kinds of things that business apps typically need to do.

(Jamie never mentioned “Alexandria”, but he was making use of a namespace that had that name in all of his demos).

Jamie did some basic demos of how Alexandria works.  To start with, you create a class to represent your business object, then set up its data binding and use attributes to specify validation rules.

Hold on just a second!  Alexandria suddenly sounds exactly like Rocky Lhotka’s CSLA.NET Framework—especially since Rocky is just finishing up a version of CSLA for Silverlight.  With an entire team of developers, Microsoft has managed to develop a framework that Rocky created (mostly) all by himself.

I’m being a little facetious.  I’m really curious what Rocky’s take is on Alexandria, since it seems to fulfill the same basic mission as CSLA.NET.  I don’t know about many of the details of CSLA, but a couple of things occurred to me:

  • CSLA.NET also supports Win Forms and Web Forms, whereas Alexandria appears to be targeted exclusively at Silverlight
  • CSLA.NET supports a wide variety of transport protocols (anything in WCF, I think), where Alexandria seems to be REST-only
  • CSLA.NET may not directly support binding to an ADO.NET Data Service, or maybe not as seamlessly as Alexandria
  • CSLA.NET is open source, so benefit from many improvements that come from the community

Anyway, as I said I’m not very knowledgeable about CSLA, but it definitely seemed like Alexandria is targeting the exact same set of business requirements as CSLA.  As with any framework comparison, however, each is certain to have its own strengths and weaknesses and appropriate for a particular category of applications.

Rocky, what is your take on this?  Ditto current users of CSLA.

Keynote #2 – Ozzie, Sinofsky, Guthrie, Treadwell

PDC 2008, Day #2, Keynote #2, 2 hrs

Ray Ozzie, Steven Sinofsky, Scott Guthrie, David Treadwell

Wow.  In contrast to yesterday’s keynote, where Windows Azure was launched, today’s keynote was the kind of edge-of-your-seat collection of product announcements that explain why people shell out $1,000+ to come to PDC.  The keynote was a 2-hr extravaganza of non-stop announcements and demos.

In short, we got a good dose of Windows 7, as well as new tools in .NET 3.5 SP1, Visual Studio 2008 SP1 and the future release of Visual Studio 2010.  Oh yeah—and an intro to Office 14, with online web-based versions of all of your favorite Office apps.

Not to mention a new Paint applet with a ribbon interface.  Really.

Ray Ozzie Opening

The keynote started once again today with Ray Ozzie, reminding us of what was announced yesterday—the Azure Services Platform.

Ray pointed out that while yesterday focused on the back-end, today’s keynote would focus on the front-end: new features and technologies from a user’s perspective.

He pointed out that the desktop-based PC and the internet are still two completely separate world.  The PC is where we sit when running high-performance close-to-the-metal applications.  And the web is how we access the rest of the world, finding and accessing other people and information.

Ray also talked about the phone being the third main device where people spend their time.  It’s always with us, so can respond to our spontaneous need for information.

The goal for Microsoft, of course, is that applications try to span all three of these devices—the desktop PC, the web, and the phone.  The apps that can do this, says Ozzie, will deliver the greatest value.

It’s no surprise either that Ray mentioned Microsoft development tools as providing the best platform for developing these apps that will span the desktop/web/phone silos.

Finally, Ray positioned Windows 7 as being the best platform for users, since we straddle these three worlds.

Steven Sinofsky

Next up was Steven Sinofsky,Senior VP for Windows and Windows Live Engineering Group at Microsoft. Steven’s part of the keynote was to introduce Windows 7.  Here are a couple of tidbits:

  • Windows 7 now in pre-beta
  • Today’s pre-beta represents “M3”—a feature-complete milestone on the way to Beta and eventual RTM.  (The progression is M1/M2/M3/M4/Beta)
  • The beta will come out early in 2009
  • Release still targeted at 3-yrs after the RTM of Vista, putting it at November of 2009
  • Server 2008 R2 is also in pre-beta, sharing its kernel with Windows 7

Steven mentioned three warm-fuzzies that Windows 7 would focus on:

  • Focus on the personal experience
  • Focus on connecting devices
  • Focus on bringing functionality to developers

Julie Larson-Green — Windows 7 Demo

Next up was Julie Larson-Green, Corporate VP, Windows Experience.  She took a spin through Windows 7 and showed off a number of the new features and capabilities.

New taskbar

  • Combines Alt-Tab for task switching, current taskbar, and current quick launch
  • Taskbar includes icons for running apps, as well as non-running (icons to launch apps)
  • Can even switch between IE tabs from the taskbar, or close tabs
  • Can close apps directly from the taskbar
  • Can access app’s MRU lists from the taskbar (recent files)
  • Can drag/dock windows on desktop, so that they quickly take exactly half available real estate

Windows Explorer

  • New Libraries section
    • A library is a virtual folder, providing access to one or more physical folders
    • Improved search within a library, i.e. across a subset of folders

Home networking

  • Automatic networking configuration when you plug a machine in, connecting to new “Homegroup”
  • Automatic configuration of shared resources, like printers
  • Can search across entire Homegroup (don’t need to know what machine a file lives on)


  • New lightweight media player
  • Media center libraries now shared & integrated with Windows Explorer
  • Right-click on media and select device to play on, e.g. home stereo


  • New Device Stage window, summarizing all the operations you can perform with a connected device (e.g. mobile device)
  • Configure the mobile device directly from this view


  • Can now exist on your desktop even without the sidebar being present


  • Can share desktop themes with other users
  • User has full control of what icons appear in system tray
  • New Action Center view is central place for reporting on PC’s performance and health characteristics

Multi-touch capabilities

  • Even apps that are not touch-aware can leverage basic gestures (e.g. scrolling/zooming).  Standard mouse behaviors are automatically mapped to equivalent gestures
  • Internet Explorer has been made touch-aware, for additional functionality:
    • On-screen keyboard
    • Navigate to hyperlink by touching it
    • Back/Forward with flick gesture

Applet updates

  • Wordpad gets Ribbon UI
  • MS Paint gets Ribbon UI
  • New calculator applet with separate Scientific / Programmer / Statistics modes

Sinofsky Redux

Sinofsky returned to touch on a few more points for Windows 7:

  • Connecting to Live Services
  • Vista “lessons learned”
  • How developers will view Windows 7

Steve talked briefly about how Windows 7 will more seamlessly allow users to connect to “Live Essentials”, extending their desktop experience to the cloud.  It’s not completely clear what this means.  He mentioned the user choosing their own non-Microsoft services to connect to.  I’m guessing that this is about some of the Windows 7 UI bits being extensible and able to incorporate data from Microsoft Live services.  Third party services could presumably also provide content to Windows 7, assuming that they implemented whatever APIs are required.

The next segment was a fun one—Vista “lessons learned”.  Steve made a funny reference to all of the feedback that Microsoft has gotten on Vista, including a particular TV commercial.  It was meant as a clever joke, but Steve didn’t get that many laughs—likely because it was just too painfully true.

Here are the main lessons learned with Vista.  (I’ve changed the verb tense slightly, so that we can read this as more of a confession).

  • The ecosystem wasn’t ready for us.
    • Ecosystem required lots of work to get to the point where Vista would run on everything
    • 95% of all PCs running today are indeed able to run Vista
    • Windows 7 is based on the same kernel, so we won’t run into this problem again
  • We didn’t adhere to standards
    • He’s talking about IE7 here
    • IE8 addresses that, with full CSS standards compliance
    • They’ve even released their compliance test results to the public
    • Win 7 ships with IE8, so we’re fully standards-compliant, out of the box
  • We broke application compatibility
    • With UAC, applications were forced to support running as a standard user
    • It was painful
    • We had good intentions and Vista is now more secure
    • But we realize that UAC is still horribly annoying
    • Most software now supports running as a standard user
  • We delivered features, rather than solutions to typical user scenarios
    • E.g. Most typical users have no hope of properly setting up a home network
    • Microsoft failed to deliver the “last mile” of required functionality
    • Much better in Windows 7, with things like automatic network configuration

The read-between-the-lines takeaway is we won’t make these same mistakes with Windows 7.  That’s a clever message.  The truth is that these shortcomings have basically already been addressed in Vista SP1.  So because Windows 7 is essentially just the next minor rev of Vista, it inherits the same solutions.

But there is one shortcoming with Vista that Sinofsky failed to mention—branding.  Vista is still called “Vista” and the damage is already done.  There are users out there who will never upgrade to Vista, no matter what marketing messages we throw at them.  For these users, we have Windows 7—a shiny new brand to slap on top of Vista, which is in fact a stable platform.

This is a completely reasonable tactic.  Vista basically works great—the only remaining problem is the perception of its having not hit the mark.  And Microsoft’s goal is to create the perception that Windows 7 is everything that Vista was not.

Enough ranting.  On to Sinofsky’s list of things that Windows 7 provides for Windows developers:

  • The ribbon UI
    • The new Office ribbon UI element has proved itself in the various Office apps.  So it’s time to offer it up to developers as a standard control
    • The ribbon UI will also gradually migrate to other Windows/Microsoft applications
    • In Windows 7, we now get the ribbon in Wordpad and Paint.  (I’m also suspecting that they are now WPF applications)

  • Jump lists
    • These are new context menus built into the taskbar that applications can hook into
    • E.g. For “most recently used” file lists
  • Libraries
    • Apps can make use of new Libraries concept, loading files from libraries rather than folders
  • Multi-touch, Ink, Speech
    • Apps can leverage new input mechanisms
    • These mechanisms just augment the user experience
    • New/unique hardware allows for some amazing experiences
  • DirectX family
    • API around powerful graphics hardware
    • Windows 7 extends the DirectX APIs

Next, Steven moved on to talk about basic fundamentals that have been improved in Windows 7:


  • Memory — kernel has smaller memory footprint
  • Disk I/O — reduced registry reads and use of indexer
  • Power  — DVD playback cheaper, ditto for timers


  • Speed  — quicker boot time, device-ready time
  • Responsiveness  — worked hard to ensure Start Menu always very responsive
  • Scale  — can scale out to 256 processors

Yes, you read that correctly—256 processors!  Hints of things to come over the next few years on the hardware side.  Imagine how slow your single-threaded app will appear to run when running on a 256-core machine!

Sinofsky at this point ratcheted up and went into a sort of but wait, there’s more mode that would put Ron Popeil to shame.  Here are some other nuggets of goodness in Windows 7:

  • Bitlocker encryption for memory sticks
    • No more worries when you lose these
  • Natively mount/managed Virtual Hard Drives
    • Create VHDs from within Windows
    • Boot from VHDs
  • DPI
    • Easier to set DPI and work with it
    • Easier to manage multiple monitors
  • Accessibility
    • Built-in magnifier with key shortcuts
  • Connecting to an external projector in Alt-Tab fashion
    • Could possibly be the single most important reason for upgrading to Win 7
  • Remote Desktop can now access multiple monitors
  • Can move Taskbar all over the place
  • Can customize the shutdown button  (cheers)
  • Action Center allows turning off annoying messages from various subsystems
  • New slider that allows user to tweak the “annoying-ness” of UAC (more cheers)

As a final note, Sinofsky mentioned that as developers, we had damn well all be developing for 64-bit platforms.  Windows 7 is likely to ship a good percentage of new boxes on x64.  (His language wasn’t this strong, but that was the message).

Scott Guthrie

As wilted as we all were with the flurry of Windows 7 takeaways, we were only about half done.  Scott Guthrie, VP, Developer Division at Microsoft, came on stage to talk about development tools.

He started by pointing out that you can target Windows 7 features from both managed (.NET) and native (Win32) applications.  Even C++/MFC are being updated to support some of the new features in Windows 7.

Scott talked briefly about the .NET Framework 3.5 SP1, which has already released:

  • Streamlined setup experience
  • Improved startup times for managed apps  (up to 40% improvement to cold startup times)
  • Graphics improvements, better performance
  • DirectX interop
  • More controls
  • 3.5 SP1 built into Windows 7

Scott then demoed taking an existing WPF application and adding support for Windows 7 features:

  • He added a ribbon at the top of the app
  • Add JumpList support for MRU lists in the Windows taskbar
  • Added Multi-touch support

Scott announced a new WPF toolkit being released this week that includes:

  • DatePicker, DataGrid, Calendar controls
  • Visual State Manager support (like Silverlight 2)
  • Ribbon control  (CTP for now)

Scott talked about some of the basics coming in .NET 4 (coming sometime in 2009?):

  • Different versions of .NET CLR running SxS in the same process
  • Easier managed/native interop
  • Support for dynamic languages
  • Extensibility Component Model (MEF)

At this point, Scott also starts dabbling in the but wait, there’s more world, as he demoed Visual Studio 2010:

  • Much better design-time support for WPF
  • Visual Studio itself now rewritten in WPF
  • Multi-monitor support
  • More re-factoring support
  • Better support for Test Driven Development workflow
  • Can easily create plugins using MEF

Whew.  Now he got to the truly sexy part—probably the section of the keynote that got the biggest reaction out of the developer crowd.  Scott showed off a little “third party” Visual Studio plug-in that pretty-formatted XML comments (e.g. function headers) as little graphical WPF widgets.  Even better, the function headers, now graphically styled, also contained hot links right into a local bug database.  Big cheers.

Sean’s prediction—this will lead to a new ecosystem for Visual Studio plugins and interfaces to other tools.

Another important takeaway—MEF, the new extensibility framework, isn’t just for Visual Studio.  You can also use MEF to extend your own applications, creating your own framework. Demo of Rich WPF Client Application

Here we got our obligatory partner demo, as a guy from showed off their snazzy application that allowed users to order groceries.  Lots of 2D and 3D graphical effects—one of the more compelling WPF apps that I’ve seen demoed.

Scott Redux

Scott came back out to talk a bit about new and future offerings on the web development side of things.

Here are some of the ASP.NET improvements that were delivered with .NET 3.5 SP1:

  • Dynamic Data
  • REST support
  • MVC (Model-View-Controller framework)
  • AJAX / jQuery  (with jQuery intellisense in Visual Studio 2008)

ASP.NET 4 will include:

  • Web Forms improvements
  • MVC improvements
  • AJAX improvements
  • Richer CSS support
  • Distributed caching

Additionally, Visual Studio 2010 will include better support for web development:

  • Code-focused improvements  (??)
  • Better JavaScript / AJAX tooling
  • Design View CSS2 support
  • Improved publishing and deployment

Scott then switched gears to talk about new and future offerings for Silverlight.

Silverlight 2 was just RTM’d two weeks ago.  Additionally, Scott presented two very interesting statistics:

  • Silverlight 1 is now present on 25% of all Internet-connected machines
  • Silverlight 2 has been downloaded to 100 million machines

IIS will inherit the adaptive (smooth) media streaming that was developed for the NBC Olympics web site.  This is available today.

A new Silverlight toolkit is being released today, including:

  • Charting controls, TreeView, DockPanel, WrapPanel, ViewBox, Expander, NumericUpDown, AutoComplete et al
  • Source code will also be made available

Visual Studio 2010 will ship with a Silverlight 2 designer, based on the existing WPF designer.

We should also expect a major release of Silverlight next year, including things like:

  • H264 media support
  • Running Silverlight applications outside of the browser
  • Richer graphics support
  • Richer data-binding support

Whew.  Take a breath..

David Treadwell – Live Services

While we were all still reeling from Scott Gu’s segment, David Treadweall, Corporate VP, Live Platform Services at Microsoft, came out to talk about Live Services.

The Live Services offerings are basically a set of services that allow applications to interface with the various Windows Live properties.

The key components of Live Services are:

  • Identity – Live ID and federated identity
  • Directory – access to social graph through a Contacts API
  • Communication & Presence – add Live Messenger support directly to your web site
  • Search & Geo-spatial – including mashups on your web sites

The Live Services are all made available via standards-based protocols.  This means that you can invoke them from not only the .NET development world, but also from other development stacks.

David talked a lot about Live Mesh, a key component of Live Services:

  • Allows applications to bridge Users / Devices / Applications
  • Data synchronization is a core concept

Applications access the various Live Services through a new Live Framework:

  • Set of APIs that allow apps to get at Live Services
  • Akin to CLR in desktop environment
  • Live Framework available from PC / Web / Phone applications
  • Open protocol, based on REST, callable from anything

Ori Amiga Demo

Ori Amiga came out to do a quick demonstration of how to “Meshify” an existing application.

The basic idea of Mesh is that it allows applications to synchronize data across all of a user’s devices.  But importantly, this means—for users who have already signed up for Live Mesh.

Live Mesh supports storing the user’s data “in the cloud”, in addition to on the various devices.  But this isn’t required.  Applications could use Mesh merely as a transport mechanism between instances of the app on various devices.

Takeshi Numoto – The Closer

Finally, Takeshi Numoto, GM, Office Client at Microsoft, came out to talk about Office 14.

Office 14 will deliver Office Web Applications—lightweight versions of the various Office applications that run in a browser.  Presumably they can also store all of their data in the cloud.

Takeshi then did a demo that focused a bit more on the collaboration features of Office 14 than on the ability to run apps in the browser.  (Running in the browser just works and the GUI looks just like the rich desktop-based GUI).

Takeshi showed off some pretty impressive features and use cases:

  • Two users editing the same document at the same time, both able to write to it
  • As users change pieces of the document, little graphical widget shows up on the other user’s screen, showing what piece the first user is currently changing.  All updated automatically, in real-time
  • Changes are pushed out immediately to other users who are viewing/editing the same document
  • This works in Word, Excel, and OneNote  (at least these apps were demoed)
  • Can publish data out to data stores in Live Services

Ray’s Wrapup

Ray Ozzie came back out to wrap everything up.  He pointed out that everything we’d seen today was real.  He also pointed out that some of these technologies were more “nascent” than others.  In other words—no complaints if some bits don’t work perfectly.  It seemed an odd note to end on.