• Visual Studio 2010 Beta 2
• .NET Framework 4 Beta 2
• Silverlight 4 Beta
• Expression Blend for .NET 4 Preview

As of January, 2010, this represents the most complete development environment possible for Silverlight 4 applications.

Operating System

I’ll be installing into a virtual machine environment, using VMware Workstation 6.5.1, running on top of Windows 7 (the host operating system).  The guest operating system, where I’ll be installing the development tools, will be Windows 7 Ultimate.

Both my host and guest machines are 32-bit (x86).

Here’s our “clean slate”–a fresh install of Windows 7 Ultimate with nothing else yet installed:

It’s a beautiful sight.

Overview

Here’s a complete list of what I’ll be installing in the Windows 7 virtual machine:

1. Visual Studio 2010 Ultimate Beta 2 (x86)    (19 Oct 2009)
2. Silverlight 4 Beta Tools for Visual Studio 2010    (2 Dec 2009)
3. Microsoft for Expression Blend for .NET 4 Preview    (16 Nov 2009)
4. Silverlight Toolkit    (18 Nov 2009)
5. WCF RIA Services for Visual Studio 2010 Beta 2    (3 Dec 2009)

I’ll include a link to the location of each tool in the sections below.

Install Visual Studio 2010

I got my copy of Visual Studio 2010 through my MSDN subscription, but you can get a free copy (“Go Live” license) here:

Download Visual Studio 2010 Beta 2

I haven’t tried downloading Visual Studio 2010 from this location, so I’m not sure what edition you get.  But even if it’s one of the Express editions, it ought to be fine for developing Silverlight 4 applications.

We start by launching the VS 2010 installation.

The installation begins.

We agree to the license, after carefully reading it.

Next, we choose either a Full or Custom installation.  I always go with Custom, so that I can turn off stuff that I don’t want.  Notice that the default installation takes up 6.4 GB.

The next screen lets me select individual components to install.  It looks like everything is selected by default.

Here are my preferred choices.  I have no interest in VB, VC++ or F#.  For now, I’ll just stick with C#.  I do include the Office Development tools, but don’t need the Dotfuscator feature or SharePoint development tools.  I also uncheck SQL Server 2008 Express, since I’ll later install a full version of SQL Server 2008 when I need it.  This brings the install footprint down to 3.6 GB.

The installation process now starts.  It will take a while, since we have a lot of different components to install.

A reboot is required after installation of the .NET Framework.

By the way, it’s interesting to note that version 4 of the .NET Framework actually updates the core components of the .NET Framework.  This was not true of version 3.0 or 3.5, which were both just releases that added to existing functionality.  So 4.0 represents the first time that core libraries have been updated since the 2.0 release in Nov, 2005–just over four years ago.

Nearly done now..

And the installation is now complete.

Install Silverlight 4 Beta Tools for Visual Studio 2010

Visual Studio 2010 includes support for Silverlight 3, rather than Silverlight 4.  Because Visual Studio 2010 ships a bit earlier than Silverlight 4 (Visual Studio 2010 shipping in March, 2010 and Silverlight 4 shipping sometime in the first half of 2010), Visual Studio 2010 will support Silverlight 3 rather than Silverlight 4.

You can download the Silverlight 4 Tools for Visual Studio from the link below.  Note that this version of the Silverlight 4 tools works only with Beta 2–not Beta 1.

Download Silverlight 4 Beta Tools for Visual Studio 2010 Beta 2

The install starts:

There’s another license agreement to read and accept.

The install begins.

And we’re done..

Install Expression Blend Preview for .NET 4

There is a free preview download of Expression Blend that supports targeting both Silverlight 4 Beta and .NET 4 Beta 2.  It is listed as being compatible with Visual Studio 2010 Beta 2 and can be found at:

Download Expression Blend Preview for .NET 4

This is version 3.1.11111.0 of Expression Blend.  It supports creation of both Silverlight 4 Beta and .NET 4 Beta 2 content, but does not support creation of Silverlight 3 or .NET 3.5 content.  It also does not include SketchFlow.

Note: If you are installing the tools to a virtual machine running in VMware Workstation, you may need to make a change in your display settings for the virtual machine before launching the Expression Blend install.  If the 3D graphics setting is enabled for the VM, the Blend install program may not display properly.  Under VMware Workstation 6.5.1, I’ve seen this problem consistently.  The fix is to disabled the 3D graphics setting for the VM.

One you disable 3D graphics, the first dialog in the install program will display properly.

The Blend install dialogs are certainly beautiful.

The installation starts:

And the installation finishes quite politely.

Install Silverlight Toolkit

Next, we install the Silverlight Toolkit, which includes a number of additional Silverlight Controls.  You can find the toolkit on CodePlex.

Download Silverlight Toolkit

The install says that this is the toolkit for Silverlight 3, but the Nov, 2009 release has been updated to include support for Silverlight 4.

Yet another license agreement.

You next get a chance to decide which components of the toolkit to install.

Ready to start the install now.

The Silverlight Toolkit install in action:

And we’re done.

Install WCF RIA Services

Next, we install the WCF RIA services, which is a framework that allows writing n-tier ASP.NET/Silverlight applications.

You can find the WCF RIA Services install at:

Install WCF RIA Services for Visual Studio 2010 Beta 2

The link above allows you to download and install the WCF RIA Services.  However, I noticed that when I got to this point, it was already installed.  As it turns out, the install for the Silverlight 4 Beta also installed the WCF RIA Services preview.

Documentation

We’ve now downloaded everything that we need for creating Silverlight 4 applications.  One remaining piece of information that will be helpful is that the Silverlight 4 documentation can be found online at:

Silverlight 4 Documentation

Wrapping Up

There we go.  I now have a clean virtual machine that has everything on it that is needed for creating Silverlight 4 applications.  My one last remaining task is to go and save a snapshot of the VM, so that I preserve the “clean” Silverlight 4 development environment.

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

• Supports either Silverlight 2 or Silverlight 3, but not both on the same development machine
• Silverlight 2 — install using the Silverlight Tools for Visual Studio 2008 SP1
• Silverlight 3 — install using the Silverlight 3 Tools Beta for 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”.

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:

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

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.

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.

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.

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

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.

Note: Also take a look at the official Getting Started page for Silverlight 3.

This post will describe installing Silverlight 3 bits on top of a clean Windows 7 / Visual Studio 2010 environment.  I won’t install the Silverlight 2 components, so the resulting environment will be targeted exclusively at Silverlight 3.

At the moment, the Silverlight 3 beta is targeted at Visual Studio 2008 SP1, rather than Visual Studio 2010.  (See Tim Heuer’s blog post explaining this).  What this means is that we can’t just run the Silverlight 3 Tools installer.  If you try, you’ll get the following error.

Installing the Silverlight 3 Beta SDK

Instead, you’ll need to just install the Silverlight 3 Beta SDK manually.  Once you download the SDK installer and launch it, you’ll get the following screen:

Then you get a license dialog.  Note the comment about this beta license expiring 30 days after the commercial release of Silverlight 3, but no later than 30 Sep, 2009.  Does this imply that we’ll see a final release of Silverlight 3 by 30 Aug, 2009?

If you do a custom install, you’ll see the following features and components listed:

Here’s a quick summary of what is being installed:

• Silverlight Tools – Components needed for building Silverlight applications
  • The core Silverlight DLLs, e.g. agcore.dll, coreclr.dll, et al
• Build Components – Components used to build Silverlight projects
  • Microsoft.Silverlight.Build.Tasks.dll,  et al
• Client Libraries – Silverlight Client Libraries and Controls
  • System.Xml.Serialization.dll, System.Xml.Linq.dll, System.Windows.Controls.Navigation, et al
• Server Libraries – Silverlight Server Libraries and Controls
  • System.Web.Silverlight.dll, et al

Now we’re ready to install:

Install continues:

The install completes, and a dialog reminds us that the actual Silverlight 3 Beta runtime is not yet present.  (Actually, there is an error in this dialog — it’s reminding us that the Silverlight 2 runtime is not present).

Installing the Silverlight 3 Developer Runtime

Now we need to install the actual Silverlight 3 runtime, which you can download from here.

We start with the familiar Silverlight install splash screen (now branded as Silverlight 3 for Developers).

Off we go..

The runtime install completes quickly.

Pretty simple.  You now have all of the important stuff that you need for developing Silverlight 3 applications with Visual Studio.

Building a Silverlight Application with Visual Studio 2010

When you bring up the New Project wizard in Visual Studio, you’ll see two types of Silverlight projects listed:

• Silverlight Application
• Silverlight Class Library

If you create a new Silverlight Application, you’ll see the Add Silverlight Application dialog.  But notice that there is now a dropdown labeled Silverlight Version.  This defaults to Silverlight 2.0, but you can select Silverlight v3.0 to create a Silverlight 3 application.

You’ll see a similar dialog if you try to create a Silverlight Class Library.

The Silverlight Navigation Application

But notice that there is one Visual Studio template that shows up if you install Silverlight 3 Beta in Visual Studio 2008 SP1 that does not show up in Visual Studio 2010 — the Silverlight Navigation Application.  This is installed as part of the Silverlight 3 Tools installer, which we were unable to run.

We need to pull this particular template from Visual Studio 2008 SP1 into Visual Studio 2010.  To do this, install the Silverlight 3 Tools installer on a machine that is running Visual Studio 2008 SP1.  Then fire up Visual Studio 2008, create a Silverlight Navigation Application project, and select Export Template from the File menu.

You’ll see a dialog asking you to select the project to export a template for.  We’ll select the main navigation application.

You can also give the new template a description and select an icon.

When you’re done, a new Windows Explorer window will pop up, containing a .zip file for your new template.  Now copy this .zip file to the following directory on your Visual Studio 2010 machine:

C:\Users\myname\Documents\Visual Studio 10\Templates\ProjectTemplates\Visual C#

Now when you bring up the New Project wizard in Visual Studio 2010, you’ll see a new template that you can use to create a Silverlight Navigation Application.

Wrapping Up

That should do it — you now have a fully functional Silverlight 3 / Visual Studio 2010 environment.

Technorati tags: Silverlight, Silverlight 3, Visual Studio 2010

Note: I installed VS 2010 Beta 1 on a clean virtual machine running Windows 7 Build 7100 (RC).

We start with the familiar install startup menu:

Then we get a banner page, as things start up.

Next, we get a license page, as well as an overview of what is going to be installed.  The key components are:

• VC 9.0 and 10.0 runtime libraries
• .NET Framework 4 Beta 1    (more info)
• Help 3.0 Beta 1    (more info)
• Visual Studio Macro Tools
• Visual Studio 2010 Professional Beta 1    (more info)

Next up is an options page:

Now the actual installation begins and we can see a more complete list of all the components that will be installed.  For completeness, here’s the full list:

• VC 9.0 Runtime
• VC 10.0 Runtime
• Microsoft .NET Framework 4 Beta 1
• Microsoft Help 3.0 Beta 1
• Microsoft Visual Studio Macro Tools
• Microsoft Visual Studio 2010 Professional Beta 1
• Microsoft Web Deployment Tool
• Visual Studio Tools for the Office System 4.0 Runtime
• Microsoft Office Development Tools for Visual Studio 2010
• Dotfuscator Software Services – Community Edition
• Microsoft SQL Server Compact 3.5 SP1
• SQL Server Compact Tools for Visual Studio 2010 Beta 1
• Microsoft Sync Framework Runtime v1.0
• Microsoft Sync Services for ADO.NET v2.0
• Microsoft Sync Framework Services v1.0
• Microsoft Sync Framework SDK v1.0
• Microsoft SQL Publishing Wizard 1.4
• SQL Server System CLR Types
• Shared Management Objects
• Microsoft SQL Server 2008 Express Edition

Wow.  This is going to take a while.

You’ll have to reboot after the .NET Framework 4 installation.

Go get a cup of coffee while the remaining components install..

You’ll get a warning dialog, indicating that SQL Server 2008 has compatibility issues on Windows 7 and suggesting that you install SP1.

I just clicked the Run Program button and proceeded with the install.  A little bit later, I got a second compatibility warning dialog, also mentioning SQL Server 2008.  An external DOS window was also spawned, running a setup.exe command.

Finally, everything finishes up and we’re done!

After the install completes, we get the main autorun window again and the link for checking for service releases is now active.

If you click the Check for Service Releases link, you’ll be redirected to an update web page, which in turn allows firing up the Windows Update applet.  When I tried this (29 Jun 2009), no updates were found.

Finally, we bring up Visual Studio 2010 for the first time.

As with earlier versions, when you start Visual Studio for the first time, you’re asked to choose a language, which dictates how the environment is set up.  I’m a C# guy.

When things finally start up, we see the new Start Page for the first time.

The New Project dialog also gets a fresh look.

Finally, we create an empty WPF Application.

But I have a slight problem when I remote into my home machine from work.  Windows 7 supports mapping multiple monitors on the remote machine to multiple monitors on the local machine.  But at work, I just use a single monitor.  So I only see the windows that are being shown on the main monitor of my home machine.

The problem arises when I click on an icon in the taskbar to see a window and it doesn’t show up–because it exists on my second monitor.  Because I’m only seeing my main monitor, I don’t see the application’s window and can’t click on it.

The fix is simple.  Do the following:

• Left-click on the application’s icon in the taskbar, to make it active
• Right-click on the icon in the taskbar and select Move
• Click one of the arrow keys once (it doesn’t matter which)
• Now move your mouse–you’ll see an outline of the application appear on the screen and you can place it where you like

This works on both Windows XP and Windows Vista.  Windows placement in Windows 7 works a bit differently, so I’m not exactly sure the best way to do this in 7.

A well designed application, on the other hand, is one that is careful to do as much work as possible in background threads, keeping the GUI responsive and making sure that it makes it obvious to the user that work is going on in the background and adjusts the GUI to disallow any user actions that don’t apply until after the work finishes.

Under .NET 2.0, doing work on a background thread has become a lot easier, with the introduction of the BackgroundWorker class.  You no longer have to worry about cross-threading exceptions and checking a control’s InvokeRequired property.

A Simple Example of Using the BackgroundWorker Class

In this post, I’ll create a simple example of how you might use the BackgroundWorker class to do some work on a background thread and keep your GUI responsive.  We’ll start with a simple example that demonstrates how the GUI can become blocked and then evolve the application to make full use of the capabilities of the BackgroundWorker class.

Here are the basic players. We’ll have a FileReader class/object that reads text from a text file. And a Win Forms form with a button to initiate the file read operation and some GUI elements to display the status/results of the read operation.

Note: All code samples presented here can be found in CodePlex, at threadsafepubsub.codeplex.com

Iteration #1 – The Simplest Possible Solution

Let’s say that we just want to read a text file and return/display the number of lines found in the file. We can just make a call to our FileReader object, which returns the number of lines, and then display that number in our UI. Super simple.

This iteration is implemented in the files Form1.cs and FileReader1.cs.

Here’s what the GUI looks like.  If you click on the Read File button, you get a File Open dialog where you can select a file to read.  The file is read in and then we write out the # lines read, below the button.

So far, so good.  This is how most simple user interfaces are written–you click on a button, which launches a Click callback, which does some work, and then returns to the caller.

Here’s what the FileReader1 class looks like, with a simple ReadTheFile method:

using System;
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;

namespace ThreadSafePubSubUI
{
    public class FileReader1
    {
        // Read specified text file & return # lines
        public int ReadTheFile(string fileName)
        {
            int numLines = 0;

            using (StreamReader sr = new StreamReader(fileName))
            {
                string nextLine;
                while ((nextLine = sr.ReadLine()) != null)
                {
                    numLines++;
                }
            }

            return numLines;
        }
    }
}

And here’s the click event handler for the form: the guy that invokes ReadTheFile.

        private void btnSelect_Click(object sender, EventArgs e)
        {
            OpenFileDialog ofd = new OpenFileDialog();
            ofd.CheckFileExists = true;
            ofd.CheckPathExists = true;

            if (ofd.ShowDialog() == DialogResult.OK)
            {
                FileReader1 fr = new FileReader1();
                int numLines = fr.ReadTheFile(ofd.FileName);

                lblResults.Text = string.Format("We read {0} lines", numLines.ToString());
            }
        }

But what if the function that does the work takes a longer amount of time?  It’s pretty common for some action initiated by the user to take a little time.  What happens to the GUI while they are waiting?  We can simulate this by just adding a Thread.Sleep call in the ReadTheFile method.

            Thread.Sleep(3000);     // Simulate lengthy operation

Let’s also add a line in the btnSelect_Click method, to write a “busy” message to the GUI while we are processing.  Here is the updated click event handler:

        private void btnSelect_Click(object sender, EventArgs e)
        {
            OpenFileDialog ofd = new OpenFileDialog();
            ofd.CheckFileExists = true;
            ofd.CheckPathExists = true;

            if (ofd.ShowDialog() == DialogResult.OK)
            {
                lblResults.Text = " ... reading the file ...";
                FileReader1 fr = new FileReader1();
                int numLines = fr.ReadTheFile(ofd.FileName);

                lblResults.Text = string.Format("We read {0} lines", numLines.ToString());
            }
        }

What happens is not good.  Two bad things happen, from a user’s point of view:

• The user interface is completely unresponsive during the file read operation
• Our “reading the file” message is not displayed

What happened?  Well, because everything is on one thread, our user interface thread doesn’t respond to mouse clicks until ReadTheFile finishes.  Worse, even though we set the label’s Text property before we call ReadTheFile, the message loop doesn’t get a chance to process that change, and update the text, before we go out to lunch in ReadTheFile.

What we need to do to fix this is: do the file read operation on a different thread

The easiest way to do some work on a background thread, keeping the GUI responsive, is to use the BackgroundWorker class.

Iteration #2 – Using the BackgroundWorker Class

You should be doing very little actual work in GUI control event handlers like the Button.Click method.  It’s a good idea to:

• Move code that does actual work outside of the user interface class
• Do all work on a background thread.

We want to move code into a separate library or class, rather than having it in our Click event handler, to keep our user interface code separate from our functional code.  This is just a cleaner architecture and makes our code more maintainable, easier to test, and more extensible.

We also want to do as much work as possible on a different thread from the main thread handling the GUI.  If you do your work on the same thread, you risk locking up the user interface.  (As we saw in Iteration #1).

If you’re using the .NET Framework version 2.0 or later, the best way to do work on a background thread is to use the BackgroundWorker class.  This class gives us the ability to do some work on a background thread, provides progress and completed events “out of the box” and also ensures that these callbacks execute on the correct (GUI thread).

What do I mean by “execute on the correct thread”?  Here’s how it works.  To ensure that the GUI stays responsive, we want to do any non-trivial work on a background thread.  This thread can run in parallel to the GUI thread, so the user will still be able to interact with the GUI while the work is being done.

When the work finishes, we likely want to update something in the GUI to indicate this.  (E.g. change the text on a label to indicate that the operation is done).  Our GUI object will be notified by handling an event that the worker object fires.  But since we need to update the GUI, this event handler must be executing on the same thread as the user interface.

This last point is very important.  The core rule in Windows UI programming to remember is: the only thread that can update/change a user interface control is the thread that created it.  (This is true for Windows Forms applications, which use the Single Threaded Apartment model).

The beauty of the BackgroundWorker class is that it automatically handles all of this thread logic:

• It does work on a background thread
• It ensures that completed/progress events are fired on the original GUI thread

Let’s change our earlier file-reading example to use the BackgroundWorker.  This example can be found in the threadsafepubsub.codeplex.com project in the Form2/FileWorker2 classes.

Here’s the new Click event handler, where we create the background worker, attach our event handlers, and then tell it to go do some work.

private void btnSelect_Click(object sender, EventArgs e)
        private void btnSelect_Click(object sender, EventArgs e)
        {
            OpenFileDialog ofd = new OpenFileDialog();
            ofd.CheckFileExists = true;
            ofd.CheckPathExists = true;

            if (ofd.ShowDialog() == DialogResult.OK)
            {
                lblResults.Text = " ... reading the file ...";

                // Set up background worker object & hook up handlers
                BackgroundWorker bgWorker;
                bgWorker = new BackgroundWorker();
                bgWorker.DoWork += new DoWorkEventHandler(bgWorker_DoWork);
                bgWorker.RunWorkerCompleted += new RunWorkerCompletedEventHandler(bgWorker_RunWorkerCompleted);

                // Launch background thread to do the work of reading the file.  This will
                // trigger BackgroundWorker.DoWork().  Note that we pass the filename to
                // process as a parameter.
                bgWorker.RunWorkerAsync(ofd.FileName);
            }
        }

We first create an instance of the BackgroundWorker class and then wire up the DoWork and RunWorkerCompleted methods.  DoWork is the event that will fire when we call the RunWorkerAsync method.  And it will run asynchronously, in a background thread, freeing up the user interface.  Because RunWorkerAsync is launched in a background thread, control returns from the btnSelect_Click method quickly, and the UI is responsive, even while the file-read work is going on.

We also hook a handler to the RunWorkerCompleted event, which will fire when our bgWorker_DoWork method has finished doing the work.  This event, however, will execute on the original GUI thread–allowing is to update GUI elements directly within our gbWorker_RunWorkerCompleted handler.

Here’s the body of our DoWork handler.

        void bgWorker_DoWork(object sender, DoWorkEventArgs e)
        {
            FileReader2 fr = new FileReader2();

            // Filename to process was passed to RunWorkerAsync(), so it's available
            // here in DoWorkEventArgs object.
            string sFileToRead = (string)e.Argument;
            e.Result = fr.ReadTheFile(sFileToRead);
        }

Notice that we just use our earlier FileReader class to do the actual work of reading the file.  But there are two additions.

First, because this method is invoked from the BackgroundWorker object, we need to somehow get the name of the file to process.  We knew this filename back in the btnSelect_Click method and we hand it off by passing it as a parameter to RunWorkerAsync and then reading it out of the DoWorkEventArgs parameter.

Similarly, when we finish doing our work (reading the file), we need to make sure the result (# lines read) gets passed back to our RunWorkerCompleted handler.  We do this by setting the Result properly of the DoWorkEventArgs parameter.

Here’s the code for our RunWorkerCompleted event handler:

        void bgWorker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
        {
            if (e.Error != null)
            {
                MessageBox.Show(e.Error.Message);
            }
            else
            {
                int numLines = (int)e.Result;
                lblResults.Text = string.Format("We read {0} lines", numLines.ToString());
            }
        }

Here we see the other side of the e.Result handoff–we read the FileReader.ReadTheFile return value out of the RunWorkerCompletedEventArgs parameter.  We also check this parameter to see if an error occurred.

If you now run this example, you’ll see a couple of important things that work better than they did in iteration #1:

• We now correctly see the “reading the file” label, indicating that work is in progress
• While the file is being read, we can interact with the GUI normally

You can demonstrate the second part of this by clicking on the “Tell Me a Joke” button.  You’ll get a message box with a clever joke and you can then dismiss the dialog–all while the file read operation is still going on.

Iteration #3 – Application State and Cancel Logic

You might be tempted at this point to think that we’re done and our application has everything that it needs.  But we’re missing a few critical things.  Any time that you do work in a background worker thread, you should also consider:

• Busy indicator – making it easy for the user to know when work is being done in the background
• Application state – what can/can’t the user do while the work is in progress?
• Progress indicator – give the user a visual sense of how much work is left to be done
• Cancel logic – optionally, give the user a method to cancel the background work

Busy Indicator

Let’s start with the busy indicator.  It’s important to make it obvious to your users that something is happening in the background, and what that something is.

Application State

We have some subtle behavior in our current implementation that is probably not desirable.  Try the following:

• Click on the Read File button and select a file, to initiate a file read operation
• Before the read has completed, click on the button again and select a new file

You now have two file read operations running in parallel.  Is this really what we want?  Do we want to prohibit it?  If not, how do we handle the results of two different file read operations, when the operations complete?  How do we avoid mixing up the results?  How do we know which operation the results are coming from?  Is there a chance that the two operations will attempt to work on/with the same data?

For our purposes, let’s agree that we really only want to allow the user to do one operation at a time.  While one operation is in progress, a user cannot initiate another one.  We’ll modify the GUI to enforce this.

Progress Indicator

More than just indicating that some work is going on in the background, it would be nice to indicate how much work we’ve already done and how much work is left to do.  This lets a user judge how long the entire process will take.

Cancel Logic

Whenever you support doing some work on a background thread, you also need to consider whether a user might want to cancel this background activity.  Unless it’s something that happens quite quickly, it’s probably a good idea to allow a user to cancel the operation and return to the original state (no file is being read and they are able to select a new file to be read).

At this point, it’s probably a good idea to do a rough sketch of a state diagram, showing what a user can do and during what state:

Notice that we enter the “reading file” state when the user clicks the “Read File” button.  But while in this state, the user cannot press that button again–they either press the “Cancel” button, or we return to the original state when the file read operation completes.

Also note that we should be able to display a joke while in either state.  This confirms what we said earlier–the GUI won’t lock up during the file read operation.

Our Modified Example

Here’s how our file reader example works, after adding a progress indicator, cancel logic, and the ability to keep track of application state.  Here’s the new GUI during a file read operation:

Note that we now tell the user what file we’re reading and we display a progress indicator, showing how far into the read operation we are.  We also give them a Cancel button, allowing them to Cancel the operation before it completes normally.  Also notice that the Read File button is greyed out—the user can’t initiate another operation until the first one completes.

If the user lets the file read operaton complete normally, they’ll see the following:

Notice that when we finish reading the file, returning to the Idle state, we hide all of the progress/cancel widgets.  The Read File button is also enabled again.

If the user cancels the file read operation, they’ll see the following:

Again, all of the progress/cancel widgets are gone, since we’re back in the Idle state.  And the Read File button is available again.  But this time, we tell the user that they cancelled the operation.

The code for this iteration can be found in threadsafepubsub.codeplex.com, as Form3.cs and FileReader3.cs.

We added a couple of things at the top of the class–an enumeration to keep track of our state, and a class-level BackgroundWorker instance.  (We move this variable into class scope because our Cancel button will need access to the BackgroundWorker object.

    private enum AppStates { Idle, ReadingFile };

    private BackgroundWorker _worker;

Here’s our new Form3 constructor, where we now call a method to set the initial application state:

        public Form3()
        {
            InitializeComponent();

            // Set up initial state
            SetAppState(AppStates.Idle, null);
        }

Here’s the actual code for the new SetAppState function, as well as a helper function that sets visibility for several controls.

        // Set new application state, handling button sensitivity, labels, etc.
        private void SetAppState(AppStates newState, string filename)
        {
            switch (newState)
            {
                case AppStates.Idle:
                    // Hide progress widgets
                    SetFileReadWidgetsVisible(false);
                    btnSelect.Enabled = true;
                    break;

                case AppStates.ReadingFile:
                    // Display progress widgets & file info
                    SetFileReadWidgetsVisible(true);
                    lblProgress.Text = string.Format("Reading file: {0}", filename);
                    pbProgress.Value = 0;
                    lblResults.Text = "";
                    btnSelect.Enabled = false;
                    break;
            }
        }

        private void SetFileReadWidgetsVisible(bool visible)
        {
            lblProgress.Visible = visible;
            pbProgress.Visible = visible;
            btnCancel.Visible = visible;
        }

We’re basically just changing the visibility of the various progress widgets in the StatusStrip at the bottom of the form.  We also handle enabling/disabling the File Read button here.

The Click event handler for our File Read button is also slightly different. We add a line that sets the application state to indicate that a file is being read, we attach a handler to track progress, and we add an exception handler to ensure that the application state is set back to idle if anything goes wrong.

        private void btnSelect_Click(object sender, EventArgs e)
        {
            OpenFileDialog ofd = new OpenFileDialog();
            ofd.CheckFileExists = true;
            ofd.CheckPathExists = true;

            if (ofd.ShowDialog() == DialogResult.OK)
            {
                FileInfo fi = new FileInfo(ofd.FileName);
                SetAppState(AppStates.ReadingFile, fi.Name);

                try
                {
                    // Set up background worker object & hook up handlers
                    _worker = new BackgroundWorker();
                    _worker.DoWork += new DoWorkEventHandler(bgWorker_DoWork);
                    _worker.RunWorkerCompleted += new RunWorkerCompletedEventHandler(bgWorker_RunWorkerCompleted);
                    _worker.WorkerReportsProgress = true;
                    _worker.WorkerSupportsCancellation = true;
                    _worker.ProgressChanged += new ProgressChangedEventHandler(bgWorker_ProgressChanged);

                    // Launch background thread to do the work of reading the file.  This will
                    // trigger BackgroundWorker.DoWork().  Note that we pass the filename to
                    // process as a parameter.
                    _worker.RunWorkerAsync(ofd.FileName);
                }
                catch
                {
                    SetAppState(AppStates.Idle, null);
                    throw;
                }
            }
        }

Note also that we have to explicitly tell the BackgroundWorker that it should support both progress and cancellation functionality.

We also now have a new event handler for the ProgressChanged event, which looks like this:

        // Get info on progress of file-read operation (% complete)
        void bgWorker_ProgressChanged(object sender, ProgressChangedEventArgs e)
        {
            // Just update progress bar with % complete
            pbProgress.Value = e.ProgressPercentage;
        }

This one is pretty simple—we just set the value of the progress bar, which runs from 0 to 100, to the reported % complete value.

Our DoWork handler has just a few changes.  Here is the new version:

        // Do work--runs on a background thread
        void bgWorker_DoWork(object sender, DoWorkEventArgs e)
        {
            // Note about exceptions:  If an exception originates anywhere in
            // this method, or methods that it calls, the BackgroundWorker will
            // automatically populate the Error property of the RunWorkerCompletedEventArgs
            // parameter that gets passed into the RunWorkerCompleted event handler.
            // So we can handle the exception in that method.

            FileReader3 fr = new FileReader3();

            // Filename to process was passed to RunWorkerAsync(), so it's available
            // here in DoWorkEventArgs object.
            BackgroundWorker bw = sender as BackgroundWorker;
            string sFileToRead = (string)e.Argument;

            e.Result = fr.ReadTheFile(bw, sFileToRead);

            // If operation was cancelled (triggered by CancellationPending),
            // we bailed out of ReadTheFile() early.  But still need to set
            // Cancel flag, because RunWorkerCompleted event will still fire.
            if (bw.CancellationPending)
                e.Cancel = true;
        }

I added a note to remind us that exceptions originating in this chunk of code (or on this thread) are automatically made available to us in the RunWorkerCompleted handler.

Notice also that we’re now passing the BackgroundWorker object into the ReadTheFile method.  We do this because we need access to it, within this message, to check for user cancellation and to report progress.

Finally, we see a piece of the cancellation infrastructure here.  Below is another code chunk to help us understand how the cancel operation works—the click handler for the Cancel button.

        private void btnCancel_Click(object sender, EventArgs e)
        {
            _worker.CancelAsync();
        }

This is pretty simple.  When the user clicks the Cancel button, we tell the BackgroundWorker object to initiate a cancel operation.  Here’s a summary of the entire cancel operation (what happens when):

• User clicks Cancel button
• btnCancel_Click handler invokes BackgroundWorker.CancelAsync on active worker object
• Method doing actual work (reading file) periodically checks BackgroundWorker.CancellationPending and aborts if it sees this property set
• Control returns to bgWorker_DoWork method
• DoWork method checks CancellationPending property and sets DoWorkEventArgs.Cancel to true if operation was cancelled
• BackgroundWorker.RunWorkerCompleted fires
• We can check RunWorkerCompletedEventArgs.Cancelled, in our RunWorkerCompleted handler, to detect whether operation was cancelled

This is a little involved, but if you walk through the code, you’ll see how things work.

Finally, here is our RunWorkerCompleted event handler:

        void bgWorker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
        {
            try
            {
                if (e.Error != null)
                {
                    MessageBox.Show(e.Error.Message, "Error During File Read");
                }
                else if (e.Cancelled)
                {
                    lblResults.Text = "** Cancelled **";
                }
                else
                {
                    int numLines = (int)e.Result;
                    lblResults.Text = string.Format("We read {0} lines", numLines.ToString());
                }
            }
            finally
            {
                // State now goes back to idle
                SetAppState(AppStates.Idle, null);
            }
        }

There are just a couple of new things here.  We now check the Cancelled property and display a message if the operation was cancelled.  We also add a finally block, where we ensure that we transition back to the Idle state, whether things completed normally, the user cancelled, or there was an error.

I have one final block of code to share—the ReadTheFile method that does the actual work:

        public int ReadTheFile(BackgroundWorker bw, string fileName)
        {
            int numLines = 0;
            FileInfo fi = new FileInfo(fileName);
            long totalBytes = fi.Length;
            long bytesRead = 0;

            using (StreamReader sr = new StreamReader(fileName))
            {
                // Note: When BackgroundWorker has CancellationPending set, we bail
                // out and fall back to the _DoWork method that called us.
                string nextLine;
                while (((nextLine = sr.ReadLine()) != null) &&
                       !bw.CancellationPending)
                {
                    bytesRead += sr.CurrentEncoding.GetByteCount(nextLine);
                    numLines++;
                    int pctComplete = (int)(((double)bytesRead / (double)totalBytes)* 100);
                    bw.ReportProgress(pctComplete);
                    Thread.Sleep(10);  // ms
                }
            }

            return numLines;
        }

We’ve basically added two things here: support for cancellation and for progress reporting.

To support user-initiated cancellation, we just check to see if the operation has been cancelled, after each line in the file that we read.  The frequency with which you check for cancellation is important.  If you don’t check often enough, the application will appear to not be responding to the cancel request and the user may become frustrated.

We report progress (% complete) by invoking the ReportProgress method on the background worker.  We do this after calculating the actual progress, in terms of # bytes read so far.

When you’re connected using Remote Desktop and you need to kill a task, or to check on CPU or memory performance, how do you bring up Task Manager?  If you press Ctrl-Alt-Delete, you’ll get the Windows Security dialog in the host machine–not on the remote machine.

To bring up Task Manager in a remote session, just use the keyboard shortcut: Ctrl-Shift-ESC.  This will directly open the Windows Task Manager on the machine that you’re connected to.  Voila.

I’m in the process of deploying a VSTO solution that includes two DLLs–a data access layer DLL and an Excel Workbook (VSTO) project that contains that code-behind for the actual Excel workbook.  In my case, my Excel code creates controls that live on the Action Pane in Excel and allow the user to interact with pre-created graphs that are fed data from a database.

When you deploy a VSTO solution, you need to grant full trust to the class library associated with the Excel Workbook (or other Office document).  This in turn means that you need to sign your assembly, i.e. attach a strong name to it.

When I sign my main assembly (e.g. ExcelWorkbook1.dll), and try to build it, I now get the following error:

Error    1    Assembly generation failed — Referenced assembly ‘MyDataAccessLayer’ does not have a strong name

What’s going on here is that when you sign an assembly, all referenced assemblies must now also have strong names.  Let’s say that again, the rule to remember is:

All assemblies referenced by a strong-named assembly must also have a strong name.

This makes sense, when you think about security concerns.  The purpose of signing an assembly is to prevent someone from replacing your assembly with one that has the same API, but does something bad–i.e. spoofing it.  Signing your main assembly helps, but if it then references a weakly-named (not signed) assembly, someone could spoof that assembly and still make your assembly behave badly.  That’s a security hole.

So when you think about signing your assemblies, giving them strong names, remember that it’s a domino effect–you’ll need to (and want to) sign all of your assemblies.  And any third-party assemblies that you use/reference need to also have strong names.

But before I can start creating a Silverlight demo, I need a basic Twitter API wrapper in .NET.  So here’s a starting point–a simple example that uses LINQ to get a list of people that you follow.  This is a good starting point for later demos.

Twitter provides a simple REST API that lets you do basically everything you’d want to do using simple HTTP GET, POST and DELETE requests.

You can learn everything you need to know about the Twitter API at the Twitter API Wiki.

Basic Concepts

I’ll assume that you generally know how Twitter works–you follow some folks, some folks follow you, and you all post status messages–which your followers can read.  That’s the beauty of Twitter–pretty simple.

But here are some things that you should know about the Twitter API.

• How it works
  • You post an HTTP request to a URL
  • You get XML data back in the HTTP response
• Authentication
  • Some API method calls require authentication, using HTTP Basic Authentication.
  • Any app invoking calls that require authentication will need to supply the proper credentials.
• Rate limits
  • Your app is limited to 100 requests per hour.    (whether you’re authenticating or not)
  • You can receive a special dispensation from the Twitter gurus to be allowed up to 20,000 requests/hr.
• Paging
  • Many API methods requires multiple requests, retrieving a page of data at a time
  • The page parameter allows you to specify which page of data to retrieve
  • The count parameter allows specifying # items per page

What happens when you hit your rate limit?  Well, basically your application (your IP address, actually) can no longer make requests of Twitter–until the rate limit resets.

The API Calls That I Use

Here are the two Twitter API calls (URLs) that I use in this example:

• Get list of people someone follows
  • http://twitter.com/statuses/friends/screenname.xml?page=1
• Get info about a specific user
  • http://twitter.com/users/show.xml?screen_name=screenname

You can see how these work by just entering the above URLs into your browser and looking at the XML data stream that comes back.

Here’s an example of the data returned by the friends call:

An here’s an example of the data returned from the users call:

The Peep Class

Let’s start building a simple Twitter API wrapper in .NET with a very simple class to encapsulate information about a single user–either yourself, a follower, or someone that you follow.  This doesn’t cover absolutely everything that we can find out about a Twitter user, but encapsulates some of the basic stuff that we care about.

(For these examples, I’m using Visual Studio 2008 — C# 3.0).

Here’s the code for the Peep class:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Text;
using System.Xml;
using System.Xml.Linq;

namespace TwitterLibGUI
{
    public class Peep
    {
        public string ScreenName { get; set; }
        public string Name { get; set; }
        public string Location { get; set; }
        public string Description { get; set; }
        public Uri ProfileImageURL { get; set; }
        public Uri URL { get; set; }
        public int ID { get; set; }

        public int NumFollowers { get; set; }
        public int NumFollowing { get; set; }
        public int NumUpdates { get; set; }

        public string LastUpdateText { get; set; }
        public DateTime LastUpdateDateTime { get; set; }

        public new string ToString()
        {
            return string.Format("{0} - {1}", ScreenName, Name);
        }
    }
}

Super simple class, made much easier through the user of C#’s automatic properties.  As an example, using me as a Twitter user, my ScreenName would be “spsexton” and my Name would be “Sean Sexton”.

The Peeps Class

Now that we have an object that wraps a “peep”, let’s create a special class that represents a collection of Peep instances–or “peeps”.  For example, an instances of Peeps could be used to store a list of everyone that we follow (or everyone that follows us).

We’ll use our old friend, the List(T) class, from System.Collections.Generic, which implements a strongly typed collection.

Basically, a collection of Peep objects will look like this:  List<Peep>.  But we’ll create a subclass so that we can add a static method for building up a list of everyone that we follow.

Here’s the full code for Peeps.cs, followed by an explanation of how we do things.

using System;
using System.Collections.Generic;
using System.Globalization;
using System.Linq;
using System.Net;
using System.Text;
using System.Xml;
using System.Xml.Linq;

namespace TwitterLibGUI
{
    /// <summary>
    /// Peep collection class
    /// </summary>
    public class Peeps : List<Peep>
    {
        // Partial Twitter API
        private const string getFriendsURI = "http://twitter.com/statuses/friends/{0}.xml?page={1}";

        /// <summary>
        /// Return list of Peeps followed by a specified person
        /// </summary>
        ///
<param name="ScreenName">The Twitter username, e.g. spsexton</param>
        /// <returns></returns>
        public static Peeps PeopleFollowedBy(string ScreenName, out int RateLimit, out int LimitRemaining)
        {
            if ((ScreenName == null) || (ScreenName == ""))
                throw new ArgumentException("PeopleFollowedBy: Invalid ScreenName");

            int nPageNum = 1;
            int userCount = 0;      // # users read on last call

            int rateLimit = 0;          // Max # API calls per hour
            int limitRemaining = 0;     // # API calls remaining

            XDocument docFriends;
            Peeps peeps = new Peeps();

            // Retrieve people I'm following, 100 people at a time
            // (each call to Twitter API results in one "page" of results--up to 100 users)
            try
            {
                do
                {
                    // Example of constituting XDocument directly from the URI
                    // docFriends = XDocument.Load(string.Format(getFriendsURI, ScreenName, nPageNum));

                    // Manually create an HTTP request, so that we can pull information out of the
                    // headers in the response.  (Then later constitute the XDocument).
                    HttpWebRequest req = (HttpWebRequest)WebRequest.Create(string.Format(getFriendsURI, ScreenName, nPageNum));
                    HttpWebResponse resp = (HttpWebResponse)req.GetResponse();
                    TwitterUtility.GetInfoFromResponse(resp, out rateLimit, out limitRemaining);
                    XmlReader reader = XmlReader.Create(resp.GetResponseStream());
                    docFriends = XDocument.Load(reader);

                    IEnumerable<XElement> users = docFriends.Elements("users").Elements("user");

                    userCount = users.Count();
                    if (userCount > 0)
                    {
                        List<Peep> nextPage = (from user in users
                                               orderby (string)user.Element("screen_name")
                                               select new Peep
                                               {
                                                   ID = (int)user.Element("id"),
                                                   ScreenName = (string)user.Element("screen_name"),
                                                   Name = (string)user.Element("name"),
                                                   Location = (string)user.Element("location"),
                                                   Description = (string)user.Element("description"),
                                                   ProfileImageURL = TwitterUtility.UriFromString((string)user.Element("profile_image_url")),
                                                   URL = TwitterUtility.UriFromString((string)user.Element("url")),
                                                   NumFollowers = (int)user.Element("followers_count"),
                                                   LastUpdateDateTime = TwitterUtility.SafeUpdateDateTime(user.Element("status")),
                                                   LastUpdateText = TwitterUtility.SafeUpdateText(user.Element("status"))
                                               }).ToList();

                        peeps.AddRange(nextPage);
                    }
                    nPageNum++;
                } while (userCount > 0);
            }
            catch (WebException xcp)
            {
                throw new ApplicationException(
                    string.Format("Twitter rate limit exceeded, max of {0}/hr allowed. Remaining = {1}",
                        rateLimit,
                        limitRemaining),
                    xcp);
            }
            finally
            {
                RateLimit = rateLimit;
                LimitRemaining = limitRemaining;
            }

            return peeps;
        }
    }
}

Notice that all we have in the Peeps class at this point is a static method, PeopleFollowedBy, that returns a collection of Peep objects, one for each person that the specified screen name follows.

The first thing that you’ll notice about the code is a loop where we get consecutive pages from the Twitter \statuses\friends\screenname.xml page.  By default, you get only 100  users at a time when invoking this URL.  So the easiest way to get all people that someone follows (their “friends”), is to request consecutive pages until you get one back that contains no users.

At each step through the loop, we construct a List<Peep> object from the XML results and then add that collection to a master collection (which this function will return).

Before we look at the code at the top of the loop that constructs an HTTP request to get the next page, take a look at the commented out line at the top of the loop:

                    // Example of constituting XDocument directly from the URI
                    // docFriends = XDocument.Load(string.Format(getFriendsURI, ScreenName, nPageNum));

This is actually the simplest way to get the results of the Twitter API calll into an XDocument, and ready for querying.  Using this single line, you could replace the next five lines of code that end with another XDocument.Load.  What’s going on here is the core of what we want to do–load up an XDocument from the URI that represents the Twitter API call.

But in my code, I go to a little more effort to create an HttpWebRequest and then get the HttpWebResponse for that request.  I do this solely for the purpose of getting Twitter rate limit information out of the header of the response.  If you’ll recall, Twitter has a 100 calls per hour rate limit by default.  The nice thing is that the API tells us the rate limit, as well as the # calls remaining, after each request.  So we read that from the header and keep track of it.

For now, this rate limit information is just returned to the caller.  But my intent is to use it in a future example to actually slow down my Twitter calls, as needed.  This will be helpful when we want to batch up a large # of Twitter calls, but we don’t want to risk maxing out our rate limit.  More on this later.

I get the rate limit info from the header in the TwitterUtility.GetInfoFromResponse method, described below.

Here’s Where LINQ Comes In

Now for the LINQ part.  Once we load up the XDocument from Twitter’s response, we can build up a collection of XElement objects corresponding to the list of users in the XML stream.  But this isn’t quite what we want..  To get the data from the XElement objects into our List<Peep> collection, we need to do a simple LINQ query.

(Thanks to a post by Wally McClure on the basic idea for the LINQ query: Calling the Twitter API in C#).

The LINQ query is pretty simple–we grab each user element from the XML stream and create a Peep object for that user.  We initialize all the fields of the new Peep object for which we can get data from this XML stream.  (We can’t get NumFollowing or NumUpdates–we’ll have to make a different API call to get that information).

In most cases, we’re asking for the value of an XML element that is a child of the <user> element.  E.g. the <id> element.  And we call helper methods in some cases, since the elements that we’re trying to read might by null.  (Actually, I haven’t tested this thoroughly–some of the other elements might occasionally be null and so it wouldn’t be a bad idea to use a “safe” accessor method on all of the elements).

Finally, we need to convert the result of our query–which is IEnumerable<Peep>–to a List<Peep> by calling the ToList() method.  Then we add this new list to the master list that we are building.

Handling the Rate Limit Exception

One final thing remains for this function–handling the case when we exceed our rate limit.  I added a simple handler, to make it a little more obvious to the client that we’ve exceeded our rate limit, rather than letting the underlying WebException bubble up.  This is a little bit sloppy, since there are other things that might throw a WebException.  But this is a good start at giving the caller a little info on the rate limit issue.

The Helper Class

Here is the full code for the TwitterUtility class, which just contains a handful of helper methods that we make use of in the Peeps and Peep (see below) classes.

using System;
using System.Collections.Generic;
using System.Globalization;
using System.Linq;
using System.Net;
using System.Text;
using System.Xml;
using System.Xml.Linq;

namespace TwitterLibGUI
{
    /// <summary>
    /// Various global utility methods for Twitter library
    /// </summary>
    public class TwitterUtility
    {
        /// <summary>
        /// Convert a string to a valid Uri object (or null)
        /// </summary>
        ///
<param name="sUri">String represent Uri, e.g. http://blahblah.com</param>
        /// <returns></returns>
        public static Uri UriFromString(string sUri)
        {
            return ((sUri != null) && (sUri.Length > 0)) ? new Uri(sUri) : null;
        }

        /// <summary>
        /// Pull a couple fields out of the header--specifically, the Twitter API rate limit info.
        /// </summary>
        ///
<param name="resp"></param>
        ///
<param name="rateLimit"></param>
        ///
<param name="limitRemaining"></param>
        public static void GetInfoFromResponse(WebResponse resp, out int rateLimit, out int limitRemaining)
        {
            rateLimit = 0;
            limitRemaining = 0;

            for (int i = 0; i < resp.Headers.Keys.Count; i++)
            {
                string s = resp.Headers.GetKey(i);
                if (s == "X-RateLimit-Limit")
                {
                    rateLimit = int.Parse(resp.Headers.GetValues(i).First());
                }
                if (s == "X-RateLimit-Remaining")
                {
                    limitRemaining = int.Parse(resp.Headers.GetValues(i).First());
                }
            }
        }

        /// <summary>
        /// Parse twitter date string into .NET DateTime
        /// </summary>
        ///
<param name="dateString"></param>
        /// <returns></returns>
        public static DateTime ParseTwitterDate(string dateString)
        {
            return DateTime.ParseExact(dateString, "ddd MMM dd HH:mm:ss zzz yyyy", CultureInfo.InvariantCulture);
        }

        /// <summary>
        /// Return a valid DateTime for status.created_at and handle the case
        /// of the status element not being present.
        /// </summary>
        ///
<param name="user">Represents status element (child of user element)</param>
        /// <returns></returns>
        public static DateTime SafeUpdateDateTime(XElement user)
        {
            DateTime creAt = new DateTime();        // Default constructor is 1/1/0001 12AM

            if (user != null)
            {
                XElement elemCreAt = user.Element("created_at");
                if (elemCreAt != null)
                {
                    creAt = ParseTwitterDate((string)elemCreAt);
                }
            }

            return creAt;
        }

        /// <summary>
        /// Return a valid update text string, whether or not the <status> element
        /// was present.
        /// </summary>
        ///
<param name="user">Represents status element (child of user element)</param>
        /// <returns></returns>
        public static string SafeUpdateText(XElement user)
        {
            string sText = "";

            if (user != null)
            {
                XElement elemText = user.Element("text");
                if (elemText != null)
                {
                    sText = (string)elemText;
                }
            }

            return sText;
        }
    }
}

Here’s what’s in this class:

• UriFromString — “Safe” assignment, creating either a valid Uri object, or null
• GetInfoFromResponse — Read the Headers collection from the HTTP response to pull out the rate limit and # remaining API calls
• ParseTwitterDate — Parse the funky Twitter date/time string into a DateTime object
• SafeUpdateDateTime — Another “safe” method, filling in a DateTime object only if the created_at element exists
• SafeUpdateText — And a “safe” assignment from the text element

(Note: Both the <created_at> and <text> elements are under the <status> element).

NumFollowing and NumUpdates

My goal when I started throwing together this example was to fully populate the Peep class that I listed at the top of the post.  This includes not just # of followers for everybody in my “friends” list, but the # of people that they follow, and their total updates.  I can get everything from the API call that we just saw–the “friends” call.  But to get # following and # updates, I need to make a different call:

http://twitter.com/users/show.xml?screen_name=screenname

This method returns a bunch of info about a particular user, including # following and # updates.  (See the XML output at the top of the post).

So the obvious thing to do would be to add an assignment in our LINQ query, calling a helper method to go off and call this other Twitter API method, right?  For each user, we could call show.xml and get the remaining two fields.

The problem with including this 2nd Twitter call in the LINQ is that we’ll blow out our Twitter rate limit.  We only get 100 requests per hour, so we’d run out of steam trying to flesh out the first 100 users.  (And any Twitter user worth his salt follows at least 100 people).

So what is to be done?  For now, I add code to the Peep class (see below) to get the remaining info on a “peep by peep” basis, rather than getting everything all at once.  This is a bit of a cop out, since we leave it up to the client to decide how often to call this method.

I’ll do a 2nd post where I actually add code to make these additional calls, but in a “rate limit safe” manner.  (Hint–we’ll use timers to slow down our use of the Twitter API).

So until we get some “rate limit smart” code, here’s the expanded code for Peep.cs, including a method that calls show.xml to get the additional info.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Text;
using System.Xml;
using System.Xml.Linq;

namespace TwitterLibGUI
{
    public class Peep
    {
        private const string userInfoURI = "http://twitter.com/users/show.xml?screen_name={0}";

        public string ScreenName { get; set; }
        public string Name { get; set; }
        public string Location { get; set; }
        public string Description { get; set; }
        public Uri ProfileImageURL { get; set; }
        public Uri URL { get; set; }
        public int ID { get; set; }

        public int NumFollowers { get; set; }
        public int NumFollowing { get; set; }
        public int NumUpdates { get; set; }

        public string LastUpdateText { get; set; }
        public DateTime LastUpdateDateTime { get; set; }

        public new string ToString()
        {
            return string.Format("{0} - {1}", ScreenName, Name);
        }

        /// <summary>
        /// Calculate NumFollowing & NumUpdates, since these two fields'
        /// data isn't available from an API call that gets a list of
        /// multiple users, but must be retrieve for each user individually.
        /// </summary>
        public void CalcAddlInfo()
        {
            if ((ScreenName == null) || (ScreenName == ""))
                throw new ArgumentException("CalcNumFollowing: Invalid ScreenName");

            int rateLimit = 0;          // Max # API calls per hour
            int limitRemaining = 0;     // # API calls remaining

            XDocument docUser;

            try
            {
                HttpWebRequest req = (HttpWebRequest)WebRequest.Create(string.Format(userInfoURI, ScreenName));
                HttpWebResponse resp = (HttpWebResponse)req.GetResponse();
                TwitterUtility.GetInfoFromResponse(resp, out rateLimit, out limitRemaining);
                XmlReader reader = XmlReader.Create(resp.GetResponseStream());
                docUser = XDocument.Load(reader);

                XElement user = docUser.Element("user");

                NumFollowing = (int)user.Element("friends_count");
                NumUpdates = (int)user.Element("statuses_count");
            }
            catch (WebException xcp)
            {
                throw new ApplicationException(
                    string.Format("Twitter rate limit exceeded, max of {0}/hr allowed. Remaining = {1}",
                        rateLimit,
                        limitRemaining),
                    xcp);
            }

        }

        /// <summary>
        /// Variant that just takes screen name, rather than acting on existing
        /// instance.
        /// </summary>
        ///
<param name="ScreenName"></param>
        public void CalcAddlInfo(string screenName)
        {
            Peep p = new Peep { ScreenName = screenName };
            p.CalcAddlInfo();
        }
    }
}

The CalcAddlInfo method just invokes the show.xml API call and then reads the friends_count and statuses_count fields.

Hey, Where’s My GUI?

Ok, so at this point, we have the following code chunks:

• Peep.cs — wraps data for a single user and gives us method to get a few additional fields
• Peeps.cs — subclasses List<Peep> and gives us method to get list of people that we follow
• TwitterUtility.cs — some miscellaneous helper functions

Now let’s throw a simple Win Forms GUI on top of these classes, so that we can test things out.  Here’s what the final result will look like, after calling our PeopleFollowedBy method:

The code for this couldn’t be simpler.  I just call the Peeps.PeopleFollowedBy method, which returns an instance of the Peeps class (which is really a List<Peep>).  And then I bind the collection to a DataGridView.  Presto.

(If you’re paying attention, you’ll also notice that my rate limit is listed as 20,000/hr, rather than the default 100/hr.  This is because I requested “white list” status and the Twitter crew kindly consented to bump my rate limit.  This applies whenever I’m making API calls from my specific IP address).

For what it’s worth, here’s the event handler code for the Load Grid button in the GUI.  Notice that I also make a test call to the CalcAddlInfo method–so we can step through the call in the debugger and see how it works.

        private void btnLoadGrid_Click(object sender, EventArgs e)
        {
            int rateLimit;
            int limitRemaining;

            Cursor = Cursors.WaitCursor;
            Peeps peeps = Peeps.PeopleFollowedBy(txtScreenName.Text, out rateLimit, out limitRemaining);

            lblNumFollowing.Text = peeps.Count.ToString();
            lblRateLimit.Text = rateLimit.ToString();
            lblRemaining.Text = limitRemaining.ToString();

            peeps[5].CalcAddlInfo();

            dgvPeeps.DataSource = peeps;
            Cursor = Cursors.Default;
        }

Wrapping Up and Next Steps

That’s all there is to it–the process of making calls to the Twitter API from .NET code and consuming the resulting XML data using LINQ is pretty straightforward.

Where am I headed next, on my way to doing some Silverlight demos?  Here’s what I’ll cover in the next post:

• Making my API methods smart about rate limits, using timers to acquire Twitter data quietly in the background–at a rate that is just slow enough to not trigger the rate limit.
• Possibly caching the data on the client

If we were going to productize the code that I’ve presented, we’d also want to think about:

• Moving the Twitter API stuff out of the data objects and into a separate class
• Better exception handling
• Wrapping the entire Twitter API, rather than just a couple methods

Driving home the other night, I was teasing my 4-yr old daughter (as I often do).  We were talking about what sorts of games to play when we got home and I suggested that we could spend our time poking Lucy’s baby brother Daniel in the eye.  I also pointed out that we’d have to take turns and asked Lucy which of us should go first.

Lucy protested.  “Daddy”, she said excitedly, “we don’t have to take turns–Daniel has two eyeballs”!

After I stopped laughing at this, I realized that Lucy had seen something very important, which hadn’t even occurred to me:

Poking a baby in the eye is something that can be done in parallel!

Yes, yes, of course–you should never poke a baby in the eye.  And if you have a pre-schooler, you should never suggest eye-poking as a legitimate game to play, even jokingly.  Of course I did explain to Lucy that we really can’t poke Daniel in the eye(s).

But Lucy’s observation pointed out to me how limited I’d been in my thinking.  I’d just assumed that poking Daniel in the eye was something that we’d do serially.  First I would poke Dan in the eye.  And then, once finished, Lucy would step up and take her turn poking Dan in the eye.  Lucy hadn’t made this assumption.  She immediately realized that we could make use of both eyeballs at the same time.

There’s an obvious parallel here to how we think about writing software.  We’ve been programming on single-CPU systems for so long, that we automatically think of an algorithm as a series of steps to be performed one at a time.  We all remember the first programs that we wrote and how we learned about how computers work.  The computer takes our list of instructions and patiently executes one at a time, from top to bottom.

But, of course, we no longer program in a single-CPU environment.  Most of today’s desktop (and even laptop) machines come with dual-core CPUs.  We’re also seeing more and more quad-core machines appear on desktops, even in the office.  We’ll likely see an 8-core system from Intel in early 2010 and even 16-core machines before too long.

So what does this mean to the average software developer?

We need to stop thinking serially when writing new software.  It just doesn’t cut it anymore to write an application that does all of its work in a single thread, from start to finish.  Customers are going to be buying “faster” machines which are not technically faster, but have more processors.  And they’ll want to know why your software doesn’t run any faster.

As developers, we need to start thinking in parallel.  We have to learn how to decompose our algorithms into groups of related tasks, many of which can be done in parallel.

This is a paradigm shift in how we design software.  In the same way that we’ve been going through a multiprocessing hardware revolution, we need to embark on a similar revolution in the world of software design.

There are plenty of resources out there to help us dive into the world of parallel computing.  A quick search for books reveals:

Introduction to Parallel Computing – Grama, Karypis, Kumar & Gupta, 2003.

The Art of Multiprocessor Programming – Herlihy & Shavit, 2008.

Principles of Parallel Programming – Lin & Snyder, 2008.

Patterns for Parallel Programming – Mattson, Sanders & Massengill, 2004.

The following paper is also a good overview of hardware and software issues:

The Landscape of Parallel Computing Research: A View from Berkeley – Asanovic et al, 18 Dec 2006.

My point here is this:  As a software developer, it’s critical that you start thinking about parallel computing–not just as some specialized set of techniques that you might use someday, but as one of the primary tools in your toolbox.

After all, today’s two-eyed baby will be sporting 16 eyes before we know it.  Are you ready to do some serious eye-poking?

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()
        {
            InitializeComponent();
        }
    }

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>
        [System.Diagnostics.DebuggerNonUserCodeAttribute()]
        public void InitializeComponent() {
            if (_contentLoaded) {
                return;
            }
            _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="http://go.microsoft.com/fwlink/?LinkID=124807" style="text-decoration: none;">
            <img src="http://go.microsoft.com/fwlink/?LinkId=108181" alt="Get Microsoft Silverlight" style="border-style: none"/>
        </a>
    </object>

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="http://schemas.microsoft.com/client/2007/deployment" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    EntryPointAssembly="SilverlightApplication1"
    EntryPointType="SilverlightApplication1.App"
    RuntimeVersion="2.0.31005.0">
  <Deployment.Parts>
    <AssemblyPart x:Name="SilverlightApplication1" Source="SilverlightApplication1.dll" />
  </Deployment.Parts>
</Deployment>

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 :
  • Calls Application.LoadComponent, to reconstitute our App object from the .xaml  (like WPF, the XAML lives inside your assembly as compiled BAML)
• 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.

References

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

Posted in Silverlight Tagged: CoreCLR, Silverlight, Silverlight Plug-in, Silverlight Presentation Core, XAP File ]]> http://stuff.seans.com/2009/03/23/hello-silverlight-world-part-3-the-lifecycle-of-a-silverlight-control/feed/ 3 spsexton plugin-model Get Microsoft Silverlight silverlight-architecture silverlight-application-structure http://stuff.seans.com/2009/03/10/hello-silverlight-world-part-2-the-application-object/ http://stuff.seans.com/2009/03/10/hello-silverlight-world-part-2-the-application-object/#comments Tue, 10 Mar 2009 17:48:27 +0000 Sean http://stuff.seans.com/?p=659 ]]> 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”.

App.xaml

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.

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!

But every once in a while, someone discovers that a girl’s reputation is completely unfounded.  You actually get to know “the slut” and discover that the rumors all derive from some mean comments that one guy said about her several years ago.  (Ironically, likely because her behavior is the opposite of what the boy claims).

What’s interesting is how fast a negative impression can spread, whether it’s true or not.  In the case of the slut, word spreads quickly and pretty soon everyone simply labels her as “the slut”, without questioning where the label came from.  Even people who have never met her don’t bother to question the label.  It’s also not a reputation that she can hope to overturn, short of moving to a new school or changing her name.  People who get to know her might realize how untrue the label is.  But the majority of the school continues to think of her as the slut, because that’s what everyone says.

Windows Vista as the Slut

In the world of PC-based operating systems, Windows Vista is the slut.

Vista’s reputation has been trashed by bloggers, technical reviewers and pundits all over the web.  The bad impression is so pervasive that even the non-technical guy at the water cooler admits that he just special-ordered a PC with Windows XP because “Vista sucks”.  Even Google agrees with his assessment—the phrase “vista sucks” will net you 210,000 results, while “xp sucks” will only turn up 16,100.

Does Vista really suck?  If not, how did it get such a horrible reputation?

Vista does not suck.  In fact, many people believe that it works even better than Windows XP.  I’ve been running Vista on a number of machines for well over a year now and I haven’t had a single problem with it.  Every piece of software I’ve ever installed has worked fine.  Every hardware device I’ve hooked up to it has also worked fine.  The user experience is just prettier, cleaner, and more efficient than Windows XP.  Performance has been fine—it actually doesn’t seem to degrade over time like Windows XP used to, as you install more and more applications.  If you don’t believe me, go read some in-depth reviews done by people like Paul Thurrott and his Windows SuperSite.

Like the high school slut, Vista got her bad reputation mostly through word-of-mouth—and because people delight in sharing negative information.  Some high profile bloggers posted some very negative reviews when it first came out, and other bloggers wrote posts of their own, merely repeating the same bad impressions.  Before long, everyone’s bad impression of Vista was cemented, despite the fact that many people harshly critical of Vista had never installed or used it in any meaningful way.

That’s not to say that Vista didn’t have some problems when it was first released.  Many hardware vendors failed to write new drivers, so their older hardware just didn’t work with Vista.  If people tried upgrading an older system, or tried using older peripherals with Vista, they found that the hardware didn’t work.

The problem with drivers is really the fault of the hardware vendors, rather than Microsoft’s fault.  For these vendors, writing new drivers for old hardware is a low priority.  They’d much rather sell you new hardware (which did work with Vista) for your new machine.  This is also nothing new—we saw exactly the same thing with Windows XP when it first released, in that the older Windows NT drivers didn’t work.

The driver problems are old news, though.  These days, it’s hard to find a piece of hardware built in the past few years that doesn’t just work when you plug it into a Vista machine.

Should You Be Using Vista?

Like the slut, Vista’s reputation clears up completely once you get to know her.  Once you start using Vista on a regular basis, you start wondering what all the fuss is about.  And you find it hard to go back to Windows XP.

So should you use Vista?  If you’re buying a new machine, the answer is—absolutely, yes.  You’ll find that everything will just work, both hardware and software.  Unless you’re buying a really low-end machine, the performance will be just fine.  Just shoot for at least 1GB RAM (2GB is even better) and at least 2 GHz dual-core processor.  (You can get a Dell Inspiron 1525 laptop with 2GHz dual-core and 3GB RAM for under $500).

What about if you’re running an older machine—should you upgrade to Vista?  The simple answer is—no.  If you have an older machine running Windows XP and you’re happy with it, stick with it.  There’s no compelling reason to jump to Vista.  And—all other things being equal—Vista will perform more slowly than XP.  This has always been true.  If you had installed XP on your old Windows 98 box, it would have been pretty slow.  The truth is that hardware gets faster and faster all the time and newer versions of Windows take advantage of those performance gains.  That’s a good thing.

Where Do We Go From Here?

If we agree that Vista’s reputation has been unfairly tarnished, is there anything to be done about it?

No.

At this point, too many bad things have been said about Vista.  The damage has been done and it will never recover its reputation.

So, like the high school slut, Vista is doing the only thing it can do.  It’s moving, changing its name, making a new start.  Sometime later this year it will surface again—and we’ll be calling it “Windows 7″.

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

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

• Silverlight Application
• Silverlight Class Library

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

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

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

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

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

The Project Structure

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

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

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

Forms, Windows and Pages

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

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

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

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

Back to the Silverlight Project

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

The Application Manifest

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

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

AssemblyInfo

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

Resources

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

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

Settings File

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

Let’s Stop There

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

Here’s a picture of the final result.  Note the “famThings” folder, which is the custom folder that I wanted.  Also note that I was able to stick a file out here, as well as a sub-folder.

As far as I can tell, there is no way to add a whole new slot for a sub-menu here, other than the default built-in menus that are part of Windows.  You can turn them on or off by tweaking the Start Menu properties, but I didn’t see a way to create a new one.  Perhaps there’s a registry hack to do this, but a quick Google search didn’t turn anything up.

So what I did instead was to hijack one of the pre-canned special folders and use it as the folder that I wanted.  I chose “Favorites”, because I use Firefox and my favorites are not stored here anyway.

Here’s how you do it:

• If the Favorites folder doesn’t already show up here, turn it on:
  • Right-click start menu globe, select Properties
  • Go to Start Menu tab
  • Click Customize
  • Find entry “Favorites menu” and make sure that it’s checked
• In Windows Explorer, navigate to C:UsersmynameFavorites and delete all the junk in there (assuming you don’t use Internet Explorer and store your regular favorites here).
• Place whatever files you like in this folder, including files, sub-folders, or shortcuts
• Now rename the Favorites folder to whatever you like
• Log out and back in, or just restart the Explorer (e.g. by killing the explorer.exe process from Task Manager and then restarting)

Voila!  Now you have your very own custom menu at the top level of the Start Menu.

But Wait, That’s Not Enough

Here’s a little addendum, after the fact.  When I originally tried everything I described above, it worked—for a short time.  But then at some point, the directory name reverted back to “Favorites”.  What’s going on?

What’s happening here is that your Favorites folder is a “special folder”, in that it contains a little hidden file called desktop.ini that specifies some of the behavior of this folder in Windows Explorer.  Below is the original contents of desktop.ini :

[.ShellClassInfo]
LocalizedResourceName=@%SystemRoot%system32shell32.dll,-21796
IconResource=%SystemRoot%system32imageres.dll,-115
IconFile=%SystemRoot%system32shell32.dll
IconIndex=-173

This little file tells Windows Explorer a few tidbits about how the folder should be displayed, including its name and the icon used.  This overrides the actual folder name and the default folder icon normally displayed for folders.

So to achieve what we want, actually renaming the folder, we could just delete desktop.ini.  Alternatively, we could keep the file and just change the value of the LocalizedResourceName attribute to be what we want.  The other benefit of keeping this file is that you can change the actual icon displayed at the top of the Start Menu when you select the folder.

For example, let’s say that I have an icon file showing a cute little potted plant and I want that to be the icon associated with my famThings folder.  I could change desktop.ini to read:

[.ShellClassInfo]
LocalizedResourceName=famThings
IconFile=Plant.ico
IconIndex=0

Then I copy the Plant.ico file into the famThings (formerly Favorites) folder and set it to hidden.  (So that it doesn’t show up in the Start Menu).

Now you get what you want—a properly named special folder whose name won’t change.  And, at no extra charge, a custom icon for the folder.  Note that the special icon now shows up not just on the Start Menu, but as the folder icon anywhere in Windows Explorer:

I use Remote Desktop all the time to connect back to one or more machines on my home network.  I have a single static IP address and then have terminal server running on every box behind the router on a different port.  So I can connect to any of my machines remotely, by using a different port.

Being able to remote connect to any/all of my machines is huge.  I consider Remote Desktop to be one of the most critical tools that I use on a daily basis.

But  I occasionally find that there is something funky on one of my home machines that leads to my wanting to reboot it.  For example, I sometimes run into a situation where I can’t connect to the machine from outside my network, but I can still remote from a different machine in my home network.  So I remote to the “visible” machine, then remote over to the “invisible” machine.  Rebooting the problem machine seems to fix the problem.

The problem with rebooting is that the Shutdown and Restart options are removed from the Start Menu when you’re connected using Remote Desktop.

But not to worry–you can still reboot the machine, just using the command prompt.  Here’s the magic command (Windows 7, Vista or Windows XP):

shutdown -t 0 -r -f

That’s a “zero” after the -t option, indicating shutdown in zero seconds.  The -r option indicates a restart, rather than shutdown.  (Don’t forget this one)!  The -f option forces all applications to terminate.

So this is a critical command, worth remembering!

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.

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:

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.

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 silverlight.net 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.

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:

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:

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 silverlight.net 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:

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.

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:

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

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

The install then starts:

And we’re done.

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
   
3. Delete all cached toolbox items by removing all files beginning with “toolbox” from C:\Users\UserName\AppData\Local\Microsoft\VisualStudio\9.0.
   
   
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.

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:

And off we go..

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.

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 0.9.000.6.

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.

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

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!

Ouch.

The workaround is to either get the update to the Windows 7 Beta that fixes this problem, or to set all of your MP3 files to be read-only, prior to loading them into Media Player.

The last part is a suggestion on the part of Microsoft and a bit funny—Microsoft warning you to set some files to be read-only so that Media Player can’t harm them.  Sort of like sending your kids to a known dangerous school and just equipping them with Kevlar.

At any rate, no worries, and no blame.  This is a beta, after all.  So we definitely expect there to be some hiccups on the road to a final release.

This problem is KB #961367 and you can find full information here:  An update is available for Windows Media Center and Windows Media Player in Windows 7 Beta

As an added bonus, this app is a nice example of doing a little work on a background thread and then firing callbacks back to the GUI thread to report progress.  This is done using the BeginXxx/EndXxx pattern, as well as using the Invoke method the ensure that GUI updating is done on the correct thread.  I always forget the exact syntax for this, so it’s nice to have it here to refer to.

The bulk of this code comes directly from the MSDN documentation for the HttpWebRequest.BeginGetResponse method.  I’ve created a little client app around it, adding some GUI elements to show progress.  I’ve also extended it to support downloads using FTP.

I include code snippets in this article, but you can download the entire Visual Studio 2008 solution here.

The End Result

When we’re done, we’ll have a little Win Forms app that lets us enter an HTTP or FTP path to a file and then downloads that file.  During the download, we see the progress, as well as the average transfer rate.

For the moment, the application doesn’t actually write the file locally.  Instead, it just downloads the entire file, throwing away the data that it downloaded.  The intent is to stress the server and measure the transfer speed—not to actually get a copy of the file.

If we were to use HTTP and specify an HTML file to download, we’d basically be doing the same thing that a web browser does—downloading a web page from the server to the client.  In the example above, I download a 1.9MB Powerpoint file from the PDC conference, just so that we have something a little larger than a web page and can see some progress.

Using FTP Instead of HTTP

My little application does FTP, as well as HTTP.  If you enter an FTP-based URI, rather than an HTTP-based one, we automatically switch to using FTP to download the file.  Before the download can start, however, we need to ask the user for credentials to use to log into the FTP site.

Once we’ve gotten the FTP credentials, the download runs in much the same way that the HTTP-based download ran.

In this case, I’m downloading an ISO image of the first CD of a Fedora distribution.  Note that the FTP response string starts with “213″, which gives file status and represents a successful response from the FTP server.  The second part of the response string is the size of the file, in bytes.  In the case of HTTP, the response was just “OK”.

Where Are We?

So what do we really have here?  A little program that downloads a single file without really writing it anywhere.  At this point, we have something that’s mildly useful for testing a server, since it tells us the transfer rate.  Furthermore, we can launch a bunch of these guys in parallel and download the same file many times in parallel, to stress the server.  (Ideally, the application would let us pick #-of-simultaneous-downloads and just kick them all off, but that’s an enhancement to be added later).

Diving Into the Source Code

More interesting than what this little program does is how you go about using the HttpWebRequest and FtpWebRequest classes to do the actual work.

Here’s a quick look at the C# solution:

There’s really not much here—the main form (DownloadStressTestForm), the FTP credentials form (GetCredentialsForm) and a little helper class used to pass data around between asynchronous methods.

Most of the code lives in DownloadStressTestForm.cs.  Ideally, we’d split this out into the GUI pieces and the actual plumbing code that does the work of downloading the files.  But this is just a quick-and-dirty project.

Push the Button

Let’s take a look at the code that fires when you click the Get File button.

        private void btnGetFile_Click(object sender, EventArgs e)
        {
            try
            {
                lblDownloadComplete.Visible = false;

                WebRequest req = null;
                WebRequestState reqState = null;
                Uri fileURI = new Uri(txtURI.Text);

                if (fileURI.Scheme == Uri.UriSchemeHttp)
                {
                    req = (HttpWebRequest)HttpWebRequest.Create(fileURI);
                    reqState = new HttpWebRequestState(BUFFER_SIZE);
                    reqState.request = req;
                }
                else if (fileURI.Scheme == Uri.UriSchemeFtp)
                {
                    // Get credentials
                    GetCredentialsForm frmCreds = new GetCredentialsForm();
                    DialogResult result = frmCreds.ShowDialog();
                    if (result == DialogResult.OK)
                    {
                        req = (FtpWebRequest)FtpWebRequest.Create(fileURI);
                        req.Credentials = new NetworkCredential(frmCreds.Username, frmCreds.Password);
                        reqState = new FtpWebRequestState(BUFFER_SIZE);

                        // Set FTP-specific stuff
                        ((FtpWebRequest)req).KeepAlive = false;

                        // First thing we do is get file size.  2nd step, done later,
                        // will be to download actual file.
                        ((FtpWebRequest)req).Method = WebRequestMethods.Ftp.GetFileSize;
                        reqState.FTPMethod = WebRequestMethods.Ftp.GetFileSize;

                        reqState.request = req;
                    }
                    else
                        req = null;	// abort

                }
                else
                    MessageBox.Show("URL must be either http://xxx or ftp://xxxx");

                if (req != null)
                {
                    reqState.fileURI = fileURI;
                    reqState.respInfoCB = new ResponseInfoDelegate(SetResponseInfo);
                    reqState.progCB = new ProgressDelegate(Progress);
                    reqState.doneCB = new DoneDelegate(Done);
                    reqState.transferStart = DateTime.Now;

                    // Start the asynchronous request.
                    IAsyncResult result =
                      (IAsyncResult)req.BeginGetResponse(new AsyncCallback(RespCallback), reqState);
                }
            }
            catch (Exception ex)
            {
                MessageBox.Show(string.Format("EXC in button1_Click(): {0}", ex.Message));
            }
        }

The basic goal here is to create an instance of either the HttpWebRequest or FtpWebRequest class.  This is done by calling the corresponding Create method, and passing it the URI that the user entered.  Note that we use the Uri class to figure out if the user is entering an HTTP or an FTP URI.  We create an instance of the base class, WebRequest, which we’ll use to kick everything off.

We also create an instance of a class used to store some state information, either HttpWebRequestState or FtpWebRequestState.  These classes both derive from WebRequestState and are defined in this project, in WebRequestState.cs.

The idea of this state object is that we’ll hand it off to the asynchronous method that we use to do the actual download.  It then will get passed back to the callback that fires when an asynchronous method completes.  Think of it as a little suitcase of stuff that we want to carry around with us and hand off between the asynchronous methods.

Notice that if we’re doing an FTP transfer, we first pop up the credentials dialog to get the Username and Password from the user.  We then store those credentials in the FtpWebRequest object.

There’s one other difference between HTTP and FTP.  In the case of HTTP, we’ll fire off a single web request, with a GET command, to download the file.  But for FTP, we actually first send a command to read the file size, followed by the command to actually download the file.  To accomplish this, we set the Method property of the FtpWebRequest to WebRequestMethods.Ftp.GetFileSize.  We don’t set this property for HttpWebRequest because it just defaults to the GET command, which is what we want.

Towards the end of this function, you’ll see that I’m loading up the suitcase—setting the various properties of the WebRequestState object.  Along with the URI, we set up some delegates to point back to three callbacks in the DownloadStressTestForm class—SetResponseInfo, Progress, and Done.  These are the callbacks that actually update our user interface—when things start, during the file transfer, and when the file has finished downloading.

Finally, we call the BeginGetResponse method to actually launch the download.  Here, we specify a response callback—the method that will get called, not when the download has completed, but just when we get the actual HTTP response, or when the FTP command completes.  In the case of HTTP, we first get the response packet and then start reading the actual file using a stream that we get from the response.

What’s important here is that we push the work into the background, on another thread, as soon as possible.  We don’t do much work in the button click event handler before calling BeginGetResponse.  And this method is asynchronous—so we return control to the GUI immediately.  From this point on, we will only update the GUI in response to a callback.

Callbacks to Update the GUI

I mentioned the three callbacks above that we use to update the user interface—SetResponseInfo, Progress, and Done.  Here’s the declaration of the delegate types:

    public delegate void ResponseInfoDelegate(string statusDescr, string contentLength);
    public delegate void ProgressDelegate(int totalBytes, double pctComplete, double transferRate);
    public delegate void DoneDelegate();

And here are the bodies of each of these three callbacks, as implemented in DownloadStressTestForm.

        /// <summary>
        /// Response info callback, called after we get HTTP response header.
        /// Used to set info in GUI about max download size.
        /// </summary>
        private void SetResponseInfo(string statusDescr, string contentLength)
        {
            if (this.InvokeRequired)
            {
                ResponseInfoDelegate del = new ResponseInfoDelegate(SetResponseInfo);
                this.Invoke(del, new object[] { statusDescr, contentLength });
            }
            else
            {
                lblStatusDescr.Text = statusDescr;
                lblContentLength.Text = contentLength;
            }
        }

        /// <summary>
        /// Progress callback, called when we've read another packet of data.
        /// Used to set info in GUI on % complete & transfer rate.
        /// </summary>
        private void Progress(int totalBytes, double pctComplete, double transferRate)
        {
            if (this.InvokeRequired)
            {
                ProgressDelegate del = new ProgressDelegate(Progress);
                this.Invoke(del, new object[] { totalBytes, pctComplete, transferRate });
            }
            else
            {
                lblBytesRead.Text = totalBytes.ToString();
                progressBar1.Value = (int)pctComplete;
                lblRate.Text = transferRate.ToString("f0");
            }
        }

        /// <summary>
        /// GUI-updating callback called when download has completed.
        /// </summary>
        private void Done()
        {
            if (this.InvokeRequired)
            {
                DoneDelegate del = new DoneDelegate(Done);
                this.Invoke(del, new object[] { });
            }
            else
            {
                progressBar1.Value = 0;
                lblDownloadComplete.Visible = true;
            }
        }

This is pretty simple stuff.  To start with, notice the common pattern in each method, where we check InvokeRequired.  Remember the primary rule about updating controls in a user interface and asynchronous programming: the controls must be updated by the same thread that created them.  InvokeRequired tells us if we’re on the right thread or not.  If not, we use the Invoke method to recursively call ourselves, but on the thread that created the control (the one that owns the window handle).

Make note of this InvokeRequired / Invoke pattern.  You’ll use it whenever you’re doing background work on another thread and then you want to return some information back to the GUI.

The work that these callbacks do is very simple.  SetResponseInfo is called when we first get the reponse packet, as we start downloading the file.  We get an indication of the file size, which we write to the GUI.  Progress is called for each packet that we download.  We update the labels that indicate # bytes received and average transfer rate, as well as the main progress bar.  Done is called when we’re all done transfering the file.

The Response Callback

Let’s go back to where we called the WebRequest.BeginGetResponse method.  We we called this method, we specified our RespCallback as the method to get invoked when the response packet was received.  Here’s the code:

        /// <summary>
        /// Main response callback, invoked once we have first Response packet from
        /// server.  This is where we initiate the actual file transfer, reading from
        /// a stream.
        /// </summary>
        private static void RespCallback(IAsyncResult asyncResult)
        {
            try
            {
                // Will be either HttpWebRequestState or FtpWebRequestState
                WebRequestState reqState = ((WebRequestState)(asyncResult.AsyncState));
                WebRequest req = reqState.request;
                string statusDescr = "";
                string contentLength = "";

                // HTTP
                if (reqState.fileURI.Scheme == Uri.UriSchemeHttp)
                {
                    HttpWebResponse resp = ((HttpWebResponse)(req.EndGetResponse(asyncResult)));
                    reqState.response = resp;
                    statusDescr = resp.StatusDescription;
                    reqState.totalBytes = reqState.response.ContentLength;
                    contentLength = reqState.response.ContentLength.ToString();   // # bytes
                }

                // FTP part 1 - response to GetFileSize command
                else if ((reqState.fileURI.Scheme == Uri.UriSchemeFtp) &&
                         (reqState.FTPMethod == WebRequestMethods.Ftp.GetFileSize))
                {
                    // First FTP command was GetFileSize, so this 1st response is the size of
                    // the file.
                    FtpWebResponse resp = ((FtpWebResponse)(req.EndGetResponse(asyncResult)));
                    statusDescr = resp.StatusDescription;
                    reqState.totalBytes = resp.ContentLength;
                    contentLength = resp.ContentLength.ToString();   // # bytes
                }

                // FTP part 2 - response to DownloadFile command
                else if ((reqState.fileURI.Scheme == Uri.UriSchemeFtp) &&
                         (reqState.FTPMethod == WebRequestMethods.Ftp.DownloadFile))
                {
                    FtpWebResponse resp = ((FtpWebResponse)(req.EndGetResponse(asyncResult)));
                    reqState.response = resp;
                }

                else
                    throw new ApplicationException("Unexpected URI");

                // Get this info back to the GUI -- max # bytes, so we can do progress bar
                if (statusDescr != "")
                    reqState.respInfoCB(statusDescr, contentLength);

                // FTP part 1 done, need to kick off 2nd FTP request to get the actual file
                if ((reqState.fileURI.Scheme == Uri.UriSchemeFtp) && (reqState.FTPMethod == WebRequestMethods.Ftp.GetFileSize))
                {
                    // Note: Need to create a new FtpWebRequest, because we're not allowed to change .Method after
                    // we've already submitted the earlier request.  I.e. FtpWebRequest not recyclable.
                    // So create a new request, moving everything we need over to it.
                    FtpWebRequest req2 = (FtpWebRequest)FtpWebRequest.Create(reqState.fileURI);
                    req2.Credentials = req.Credentials;
                    req2.UseBinary = true;
                    req2.KeepAlive = true;
                    req2.Method = WebRequestMethods.Ftp.DownloadFile;

                    reqState.request = req2;
                    reqState.FTPMethod = WebRequestMethods.Ftp.DownloadFile;

                    // Start the asynchronous request, which will call back into this same method
                    IAsyncResult result =
                      (IAsyncResult)req2.BeginGetResponse(new AsyncCallback(RespCallback), reqState);
                }
                else    // HTTP or FTP part 2 -- we're ready for the actual file download
                {
                    // Set up a stream, for reading response data into it
                    Stream responseStream = reqState.response.GetResponseStream();
                    reqState.streamResponse = responseStream;

                    // Begin reading contents of the response data
                    IAsyncResult ar = responseStream.BeginRead(reqState.bufferRead, 0, BUFFER_SIZE, new AsyncCallback(ReadCallback), reqState);
                }

                return;
            }
            catch (Exception ex)
            {
                MessageBox.Show(string.Format("EXC in RespCallback(): {0}", ex.Message));
            }
        }

The first thing that we do in this method is to open our suitcase–our WebRequestState object, which comes back in the AsyncState property of the IAsyncResult.

The other main thing that we do in this method is to get the actual WebResponse object.  This contains the information that we actually got back from the server.  We do this by calling the EndGetResponse method.

Notice the standard Begin/End pattern for asynchronous programming here.  We could have done all of this synchronously, by calling GetResponse on the original HttpWebRequest (or FtpWebRequest object).  GetResponse would have returned an HttpWebResponse (or FtpWebResponse object).  Instead, we call BeginGetResponse to launch the asynchronous method and then call EndGetResponse in the callback to get the actual result—the WebResponse object.

At this point, the first thing that we want from the response packet is an indication of the length of the file that we’re downloading.  We get that from the ContentLength property.

It’s also at this point that we call the ResponseInfo delegate, passing it the status string and content length, to update the GUI.  (Using the respInfoCB field in the WebRequestState object).

Let’s ignore FTP for the moment and look at the final main thing that we do in this method—get a stream object and kick off a read of the first packet.  We get the stream from that WebReponse object and then go asynchronous again by calling the BeginRead method.  Are you seeing a pattern yet?  Again, if we wanted to do everything synchronously, we could just set up a loop here and call the stream’s Read method to read each buffer of data.  But instead, we fire up an asynchronous read, specifying our method that should be called when we get the first packet/buffer of data—ReadCallback.

FTP Download, Step 2

Let’s go back to how we’re doing FTP.  Remember that we set the FtpWebRequest.Method property to GetFileSize.  And in ReadCallback, if we see that we just did that first command, we send the file size back to the GUI.  And then we’re ready to launch the 2nd FTP command, which is DownloadFile.  We do this by creating a 2nd FtpWebRequest and calling the BeginGetResponse method again.  And once again, when the asynchronous method completes, we’ll get control back in ReadCallback.  We don’t risk recursing indefinitely because we store an indication of which command we’re doing in our suitcase—in WebRequestState.FTPMethod.

Gettin’ the Data

Finally, let’s take a look at the code where we actually get a chunk of data from the server.  First, a quick note about buffer size.  Notice that when I called BeginRead, I specified a buffer size using the BUFFER_SIZE constant.  For the record, I’m using a value of 1448 here, which is based on the size of a typical TCP packet (packet size less some header info).  We could really use any value here that we liked—it just seemed reasonable to ask for the data a packet at a time.

Here’s the code for our read callback, which first fires when the first packet is received, after calling BeginRead.

        /// <summary>
        /// Main callback invoked in response to the Stream.BeginRead method, when we have some data.
        /// </summary>
        private static void ReadCallback(IAsyncResult asyncResult)
        {
            try
            {
                // Will be either HttpWebRequestState or FtpWebRequestState
                WebRequestState reqState = ((WebRequestState)(asyncResult.AsyncState));

                Stream responseStream = reqState.streamResponse;

                // Get results of read operation
                int bytesRead = responseStream.EndRead(asyncResult);

                // Got some data, need to read more
                if (bytesRead > 0)
                {
                    // Report some progress, including total # bytes read, % complete, and transfer rate
                    reqState.bytesRead += bytesRead;
                    double pctComplete = ((double)reqState.bytesRead / (double)reqState.totalBytes) * 100.0f;

                    // Note: bytesRead/totalMS is in bytes/ms.  Convert to kb/sec.
                    TimeSpan totalTime = DateTime.Now - reqState.transferStart;
                    double kbPerSec = (reqState.bytesRead * 1000.0f) / (totalTime.TotalMilliseconds * 1024.0f);

                    reqState.progCB(reqState.bytesRead, pctComplete, kbPerSec);

                    // Kick off another read
                    IAsyncResult ar = responseStream.BeginRead(reqState.bufferRead, 0, BUFFER_SIZE, new AsyncCallback(ReadCallback), reqState);
                    return;
                }

                // EndRead returned 0, so no more data to be read
                else
                {
                    responseStream.Close();
                    reqState.response.Close();
                    reqState.doneCB();
                }
            }
            catch (Exception ex)
            {
                MessageBox.Show(string.Format("EXC in ReadCallback(): {0}", ex.Message));
            }
        }

As I’m so fond of saying, this is pretty simple stuff.  Once again, we make use of recursion, because we’re asynchronously reading a packet at a time.  We get the stream object out of our suitcase and then call EndRead to get an indication of how many bytes were read.  This is the indicator that will tell us when we’re done reading the data—in which case # bytes read will be 0.

If we’re all done reading the data, we close down our stream and WebResponse object, before calling our final GUI callback to tell the GUI that we’re done.

But if we did read some data, we first call our progress callback to tell the GUI that we got another packet and then we fire off another BeginRead.  (Which will, of course, lead to our landing back in the ReadCallback method when the next packet completes).

You can see that we’re passing back some basic info to the GUI—total # bytes read, the % complete, and the calculated average transfer rate, in KB per second.

If we actually cared about the data itself, we could find it in our suitcase—in WebRequestState.bufferRead.  This is just a byte array that we specified when we called BeginRead.  In the case of this application, we don’t care about the actual data, so we don’t do anything with it.

Opening the Suitcase

We’ve looked at basically all the code, except for the implementation of the WebRequestState class that we’ve been using as our “suitcase”.  Here’s the base class:

    /// <summary>
    /// Base class for state object that gets passed around amongst async methods
    /// when doing async web request/response for data transfer.  We store basic
    /// things that track current state of a download, including # bytes transfered,
    /// as well as some async callbacks that will get invoked at various points.
    /// </summary>
    abstract public class WebRequestState
    {
        public int bytesRead;           // # bytes read during current transfer
        public long totalBytes;            // Total bytes to read
        public double progIncrement;    // delta % for each buffer read
        public Stream streamResponse;    // Stream to read from
        public byte[] bufferRead;        // Buffer to read data into
        public Uri fileURI;                // Uri of object being downloaded
        public string FTPMethod;        // What was the previous FTP command?  (e.g. get file size vs. download)
        public DateTime transferStart;  // Used for tracking xfr rate

        // Callbacks for response packet info & progress
        public ResponseInfoDelegate respInfoCB;
        public ProgressDelegate progCB;
        public DoneDelegate doneCB;

        private WebRequest _request;
        public virtual WebRequest request
        {
            get { return null; }
            set { _request = value; }
        }

        private WebResponse _response;
        public virtual WebResponse response
        {
            get { return null; }
            set { _response = value; }
        }

        public WebRequestState(int buffSize)
        {
            bytesRead = 0;
            bufferRead = new byte[buffSize];
            streamResponse = null;
        }
    }

This is just all of the stuff that we wanted to pass around between our asynchronous methods.  You’ll see our three delegates, for calling back to the GUI.  And you’ll also see where we store our WebRequest and WebResponse objects.

The final thing to look at is the code, also in WebRequestState.cs, for the two derived classes—HttpWebRequestState and FtpWebRequestState.

    /// <summary>
    /// State object for HTTP transfers
    /// </summary>
    public class HttpWebRequestState : WebRequestState
    {
        private HttpWebRequest _request;
        public override WebRequest request
        {
            get
            {
                return _request;
            }
            set
            {
                _request = (HttpWebRequest)value;
            }
        }

        private HttpWebResponse _response;
        public override WebResponse response
        {
            get
            {
                return _response;
            }
            set
            {
                _response = (HttpWebResponse)value;
            }
        }

        public HttpWebRequestState(int buffSize) : base(buffSize) { }
    }

    /// <summary>
    /// State object for FTP transfers
    /// </summary>
    public class FtpWebRequestState : WebRequestState
    {
        private FtpWebRequest _request;
        public override WebRequest request
        {
            get
            {
                return _request;
            }
            set
            {
                _request = (FtpWebRequest)value;
            }
        }

        private FtpWebResponse _response;
        public override WebResponse response
        {
            get
            {
                return _response;
            }
            set
            {
                _response = (FtpWebResponse)value;
            }
        }

        public FtpWebRequestState(int buffSize) : base(buffSize) { }
    }

The whole point of these classes is to allow us to override the request and response fields in the base class with strong-typed instances—e.g. HttpWebRequest and HttpWebResponse.

Wrapping Up

That’s about it—that’s really all that’s required to implement a very simple HTTP or FTP client application, using the HttpWebRequest and FtpWebRequest classes in System.Net.

This is still a pretty crude application and there are a number of obvious next steps that we could take if we wanted to improve it:

• Allow user to pick # downloads and kick off simultaneous downloads, each with their own progress bar
• Prevent clicking Get File button if a download is already in progress.  (Try it—you do actually get a 2nd download, but the progress bar goes whacky trying to report on both at the same time).
• Add a timer so that we can recover if a transfer times out
• Allow the user to actually store the data to a local file
• Log the results somewhere, especially if we launched multiple downloads

In my 9-5 life, I’ve been a member of a software development team since 1985.  That’s 23 years as a software developer—ouch!

Like many developers who have been around for a few years, at least some of my grey hair can be attributed to having worked on hellish projects, or on projects that failed outright.  Over the years, I’ve gradually added to my mental list of “worst practices”—things that tend to lead to project failure, or at least hide a failing project until it’s too late to turn it into a successful one.

It’s much easier to compile a list of worst practices than it is to pick some “perfect” development process.  But worst practices can lead to best practices simply by avoiding the bad practices.  At a minimum, we should at least avoid making the same mistakes over and over again.

If I had to pick a single worst practice (there are many), it would be this:

Not building the product that the customer really needed

This happens all of the time.  We (the developers) build a product that is bug-free, efficient, scalable, and does exactly what we intended it to do.  We even occasionally get the work done in something close to the amount of time that we said it would take.

But our well-built software still fails—for a variety of reasons.

• It’s too hard to use
• Users are unable to use it efficiently/effectively
• It’s missing one or more critical features
• Users don’t have a need for the software in the first place
• It’s too expensive, given what it does

In order to be “successful”, software has to meet a critical need that the user has.  Good software solves a pressing problem.  Great software does so in a way that seems natural to the users.

So what do I mean when I talk about software “failure”?  Simply put, “failed” software is: software that doesn’t get used.

What are the consequences of failure?  For internal software projects, it means wasted time and energy that could have been spent on things that the organization does need.  For consulting houses, it means possibly not getting hired back by the client, or seeing your reputation diminished.  For ISVs developing software/services to sell, it means lost revenue or even bankruptcy.

For developers, failure means knowing that you’ve wasted your time, intellect and energy on something that no one is going to use.  That sucks.

Our goal then as developers is to build great software.  We want to see users working with our stuff, to see it making their lives better, and to see them excited about it.  That’s the true Holy Grail that many of us work towards.

The Remedy

So how do we develop great software?  We can’t all be Steve Jobs, or hire him into our organization.  So without brilliant insight, how do we figure out what the users truly need?

To understand what users need—truly, madly, deeply—we need to think beyond developing products and start thinking about developing an understanding of our users.

This focus on a Customer Development Process, rather than a Product Development Process, is the point of the book The Four Steps to the Epiphany, by Steven Gary Blank.

Blank’s main thesis is that we should work towards an understanding of our customers and their needs much earlier in the development lifecycle.  We need to fully understand what customers need and whether we can sell them our product before we go too far down the path of building that product.

Blank proposes a very detailed Customer Development Process and talks a little bit about when it should occur, relative to the typical phases of a Product Development Process.  This is a little tricky.  If we wait too long to learn about our customers, we risk building the wrong product.  But if we talk to them too early, before we’ve had time to think a little bit about our vision, we’re not really innovating, but just trying to build what they tell us to build.  That also can lead to failure.

My Take on the Product Development Process

Having worked as a software developer for so many years, I’ve seen lots of different software lifecycles.  In my first job, with Control Data Corp in Bloomington, MN, we were a Dept of Defense shop and rigidly followed DOD-STD-2167A—a very rigidly-defined classic waterfall process.

I’ve also done my share of agile development, working in groups that used various agile methods.

My main takeaway on software process is that it’s important to develop iteratively.  For me, that’s the most critically important piece of the agile movement.  Many of the other techniques, like pair programming and test driven development might be important, but don’t seem quite as critical as being able to build your product iteratively.  Short iterations allow agility.

For me, one book that really made a lot of sense in laying out a framework for an iterative lifecycle was The Rational Unified Process Made Easy, by Per Kroll.

For a lot of people, when they think about RUP (Rational Unified Process), they think: heavyweight and lots of modeling/diagramming.  But Kroll explains that RUP doesn’t necessarily mean heavy.  He refers to the number of artifacts that you’re required to produce as your level of ceremony.  And he describes RUP as:

An iterative approach with an adaptable level of ceremony

Again, iterative is the important part.  An iterative approach with very little ceremony would basically be an agile methodology.  But sometimes you work on projects that require a bit more ceremony—some project tracking, etc.  On these projects, you can still be iterative, but with more ceremony.  Here’s a picture:

RUP talks about general phases of the lifecycle being: Inception, Elaboration, Construction and Transition.  But Kroll is quick to point out that this does not just map to the classic waterfall model.  (Requirements, Analysis/Design, Implementation, Testing).  Rather, you’d typically perform some of each of the classic waterfall activities during each iteration of RUP.  You’d likely be doing a lot more requirements-gathering in your Inception phases, but you’d also be doing some implementation.  And you’d spend a lot of time writing code during Construction phases, but you might also still be tweaking some requirements.

Here’s a nice picture of how RUP typically plays out.  Again, note that the idea of iterations is important:

Personally, I like this view of the development lifecycle a lot.  This model is how I think about software development.  Work in an iterative fashion, but be aware of what main phase you’re in and adjust your activities accordingly.

Over the years, I’ve taken lots of notes to answer the question, “what activities should I be doing at each step”?  Kroll has a lot of good information in his book, but I’ve borrowed liberally from other sources.  What I ended up with was a fairly detailed “a la carte” list of activities that you might engage in across the lifecycle.

I say “a la carte” because every project will not engage in every step.  But I think it’s a nice master list to draw from.  And I think that I have the activities listed in a pretty reasonable order.

So here’s my list of high-level activities for the Product Development Lifecycle.  (See below for more detail for each activity):

• Vision
• Initial Requirements Gathering  (Inception)
• GUI Conceptualizing
• Identify Candidate Architecture
• Define Non-Functional Tasks
• Define Iterations  (Project Planning)
• Write Development Plan
• Execute Inception iterations
• Write Business Plan
• Write Test Plan
• Write Deployment Plan
• Execute Construction Iterations
• Initiate Test Plan
• Deploy Alpha Release
• Write Customer Support Plan
• Execute Deployment Iteration
• Deploy Beta Release
• Launch Product
• Begin Planning Next Release

The Customer Development Process

I love the idea of the Customer Development Process, as Blank presents it in The Four Steps to the Epiphany.  He talks about discovering who your customers are, figuring out what they need, and then testing your hypotheses.  In other words—iterate not just on the product, but also on your model of who the customers are.  This includes not just an understanding of the customers and their needs, but also gets into the actual selling proposition and marketing of your product.

Here are the top-level activities in Blank’s customer development process:

• Customer Discovery
• Customer Validation
• Customer Creation
• Company Building

Lining Things Up

The trick is to figure out how the Product Development Process and the Customer Development Process relate to each other.  If you listed out the various phases of each process side by side, how would they line up?  At what point in your product development process should you start the customer development process?  Or should it be the other way around?

Here’s a first stab at lining the two processes up.  My goal was to come up with a high-level roadmap for doing new (green field) development, which would cover developing both the product and the customers.

Should I Keep Reading?

The rest of this post expands on each of the activities in the table above, listing details of what happens during each phase.  This is the outline that I use when I’m trying to figure out “what to do next”.

Note again—this process is very much geared towards green-field development, and in a market where you are developing a product or service to sell to end-users.

Product Development Process—Details

Here’s the detailed breakdown of the steps involved in the Product Development Process.  Much of this content comes from the books I list at the end of the article, primarily The Rational Unified Process Made Easy and Head First Software Development.  But a lot of it is just my own concept of what you typically do during each phase.

Note that iterations occur in the Inception and Construction phases.

Vision

• Do a short description of a handful of possible products
  • For each, describe:
    • Market or market segment  (which group of users, short description)
      • What is the problem that they experience
      • How painful to the users?  What workarounds are in place?
    • Short description of product that might help them solve this problem
    • Short feature list (<10 items, single sentence)
    • How does this product specifically solve the customer’s problem?
• Expand on top one or two possible products.
  (For each, expand information to include):
  • Write up SIMs (Specific Internet Market Segment, Walsh pg 158..)
    • Lots of details about the targeted user group
  • Other user information
    • How often do you expect each user group to user the product?
    • Why might they stop using the product?
    • Rough guess as to size of this market, e.g. # potential users?
  • Are there other non-primary users?
    (E.g. users who didn’t purchase, or just different group of users)
    • Also describe their “problem” and how product solves it
    • Are they also potential buyers, or just users?
    • What subset of the feature list might they use?
    • What else differentiates them from primary user group?
    • Also write up SIM for this user group
  • Bluesky one or more revenue models.  Answer for each:
    • What would this customer pay for this product?
      • Specify target price or range that might be tolerable
    • One-time purchase or ongoing subscription?  (or a combination)
    • Pricing tiers?  If so, describe
    • Trial period?  If so, describe
    • If >1 user group, repeat for other groups
    • What level of certainty do you have that they will purchase?
    • Why might they not purchase?  List reasons.
    • Possible ways to mitigate non-purchase reasons.
    • Does revenue model depend on continued use of the product?
    • How will you collect money?
    • What is your distribution channel?  (i.e. how do they receive product)
    • If ongoing subscription, describe what happens when they stop paying
      (E.g. limited access)?
  • Revenue model/estimates  (per yr)
    • Make rough estimate of ongoing costs, per user or account
    • List expected revenue per user, single or ongoing, per yr
    • Starting with desired annual revenue, describe # customers required to meet goal
  • Marketing / Sales vision
    • How might product be branded?
    • How is product positioned (e.g. tagline)
    • How might you reach desired users?  (make aware)
    • What is selling proposition (argument to buy)?
  • Competitive analysis
    • Assess and summarize competitive products that do similar/same thing as yours
    • What are their strengths/weaknesses?
    • Where can you improve on them?  To what degree?
    • What are you missing that competitors might have?

Initial Requirements Gathering
(Chap 2 of Head First Software Development)

• Generate quick list of basic ideas, 1-3 sentences each, Title/Description
• Ask user questions to flesh out the list
• Bluesky to generate feature lists (Title/Description)
  • Use other people
  • Okay to spit out non-functional stuff, like specific GUI thoughts, or architecture
• Build User Stories
  • Describe one thing
  • Language of the customer
  • Title/Description
  • 1-3 sentences
• Pull out non-customer stories, save for later (design)
• Refine initial set of user stories, w/customer feedback
• Provide estimates for each user story
  • Include assumptions
• Team estimation and revision
• Clarify assumptions w/users, if necessary
• Break apart users stories that are >15 days
• Add up estimates to get estimate for total project

GUI Conceptualizing

• Select key use cases that need GUI concept
• User interaction goals
  • Outline some key goals of user interaction model
    (E.g. discoverability, efficiency, slick animation, etc)
  • Describe user action requirements verbally for specific use cases
• Assess similar products’ GUIs for similar use cases
  • Pros/cons of each
• For each use case selected
  • Paper prototype one or more possible GUIs
  • Storyboard any dynamic behavior
  • Brainstorm alternative approaches and paper prototype
• Identify common sequences of use cases  (e.g. find/edit)
  • Storyboard use case sequences
  • Brainstorm ways to optimize the storyboard/sequence
• Assess GUI model against several measures of good GUI design
• Technical review of GUI feasibility
  • Build it, buy it, or freebie (part of tool or freeware)?
  • If build, rough guess as to effort
  • If buy, what is the cost?  One-time & ongoing.
• Assess technical risk
  • Are there any aspects of GUI that need to be proven out?
• Hammer looking for nails
  • Make short list of most compelling GUI models in new products
  • Is there anywhere in product that you might use these models?
• Brainstorm user assistance model (help, wizards, demos, etc.–learning)
• GUI models from competitors
  • If there are competitive products that compete in same space, summarize their main GUI elements.
  • Assess—is their GUI or user interaction model an asset or a liability?
• Review
  • Early review internally (not w/customers)
  • Review static screen mockups (e.g. paper prototypes)
  • Look at discoverability–obvious what it’s used for?
  • Aesthetics

Identify Candidate Architecture

• Identify one possible architecture that could support the product
• Identify any areas of technical risk
• Discuss pros/cons/risks
• [For more details, see Kroll]

Define Non-Functional Tasks

• Define additional tasks to be completed during inception that are NOT use cases
• Possible examples include:
  • GUI proof-of-concept, for technical & usability
  • Building candidate architecture  (must do)
  • Technical proof-of-concept
  • Capacity testing for architecture (e.g. scalability)
• Provide priorities and estimates for all tasks
  (will feed into iteration planning, along w/use cases)

Define Iterations
(Chap 3 of Head First Software Development)

• Set target date for first (next) release
• Work w/customer to prioritize user stories
• Also feed non-functional tasks into process
• Select subset of user stories to meet target date  (Milestone 1)
  • If the features don’t fit target date, re-prioritize
  • Focus on user stories that are absolutely critical
  • Baseline functionality–smallest set of features so that SW is at all useful to customers
• Prioritize user stories in Milestone 1.0  (1-5, with 1 as highest priority)
• Assign user stories to iterations, using 20-day iterations
  • Based on priority
  • Or user stories required to implement other user stories
  • Use velocity of 0.7  (0.7days effort for each real day)
    I.e. Each iteration should contain 14 person-days of estimated work
• Reassess schedule and adjust schedule and/or content
  • Because of velocity, things likely can’t fit
  • Add iteration(s), change M1 date, or both
• Get iterations & user stories into tracking spreadsheet
• Construct burn-down graph for 1st iteration
  • X axis is calendar days
  • Y axis is person-days of work accomplished
  • Draw diagonal line as ideal burn-down rate

Write Development Plan

• Describe everything that will happen from here on out
• Include
  • Iterations and contained user stories & tasks
  • Milestones
  • Review points and staff
  • High-level test plan
  • alpha/beta/release plan
  • Staff
  • Schedule
  • Tools
  • Show steps in Product Development process
  • Show steps in Customer Development process
  • Show how the two processes line up
  • Include calendar alignment, if appropriate

Execute Inception Iterations
(Chap 4 of Head First Software Development – User stories & tasks)

• Break down each user story into tasks
  • Title/Description/Estimate
  • Provide estimate for each task
  • E.g. Create class, create GUI prototype, create schema, create SQL scripts
  • Each task should be 0.5 – 5 days
• Plot where you are on burn-down graph
  • Calendar day vs. new estimate of person-days of work left
• Update spreadsheet w/tasks & their estimates
  • Task estimates replace user story estimates
  • Also track burn-down in spreadsheet
  • Put stickies on big board, tasks, In Progress/Complete, etc. (pg 116 of Pilone/Miles)
• Start working on first tasks
  • Move stickies on board when they are In Progress
• Daily stand-up meetings to track progress
  • First thing in the morning
  • Track progress–what has each person accomplished
  • Update burn-down rate
  • Update tasks
  • What happened yesterday, what is plan for today
  • Talk about any problems
  • 5-15 mins long
• Add unplanned tasks to iteration, if necessary
  • Add user story, estimate, break into tasks, review w/customer, add to board
  • Use red stickies
  • Update burn-down, showing that you’re off
• Next iteration
  (Chap 10 of Head First Software Development)
  • End of iteration review (pg 342-343 of Pilone/Miles)
  • Verify SW passes all tests
  • Demo/review w/customer
  • Plan next iteration
    • Add new user stories, if required
    • Update priority/estimates for everything
    • Adjust velocity
    • Feed in bug backlog as tasks
    • Priority tradeoffs include bug-fixes vs. new features
  • Follow steps from Pilone/Miles chap 4 (break down into tasks and estimate)

Write Business Plan

• Goal isn’t to get funding, but to make a case for the product/business
  (at least on paper)
• Include stuff like
  • Market description
  • Customer description
  • Description of competitors’ products/services
  • Product proposition
    • What is customers’ problem?
    • What is your vision for product/service
    • How does product/service solve their problem?
  • Outline of development plan
  • Outline of Product/Customer Development processes
  • Summarize revenue model
  • Summarize marketing/sales plan
  • Business structure: staffing, organization, etc.
• Add other typical business plan elements

Write Test Plan

• What to test, how to test, when to test
• Plan for test-driven development, using appropriate TDD tools
• Plan automated/nightly builds and automation of testing
• See Pilone/Miles, chap 7, among others

Write Deployment Plan

• How/when will software be deployed?
• Map out alpha/beta/launch
• Where does testing fit into the plan?
• How will customers get the software?
• How will they pay for it?
• How do you track customers?

Execute Construction Iterations
(Chap 4 of Head First Software Development – User stories & tasks)

• Break down each user story into tasks
  • Title/Description/Estimate
  • Provide estimate for each task
  • E.g. Create class, create GUI prototype, create schema, create SQL scripts
  • Each task should be 0.5 – 5 days
• Plot where you are on burn-down graph
  • Calendar day vs. new estimate of person-days of work left
• Update spreadsheet w/tasks & their estimates
  • Task estimates replace user story estimates
  • Also track burn-down in spreadsheet
  • Put stickies on big board, tasks, In Progress/Complete, etc. (pg 116 of Pilone/Miles)
• Start working on first tasks
  • Move stickies on board when they are In Progress
• Daily stand-up meetings to track progress
  • First thing in the morning
  • Track progress–what has each person accomplished
  • Update burn-down rate
  • Update tasks
  • What happened yesterday, what is plan for today
  • Talk about any problems
  • 5-15 mins long
• Add unplanned tasks to iteration, if necessary
  • Add user story, estimate, break into tasks, review w/customer, add to board
  • Use red stickies
  • Update burn-down, showing that you’re off
• Next iteration
  (Chap 10 of Head First Software Development)
  • End of iteration review (pg 342-343 of Pilone/Miles)
  • Verify SW passes all tests
  • Demo/review w/customer
  • Plan next iteration
    • Add new user stories, if required
    • Update priority/estimates for everything
    • Adjust velocity
    • Feed in bug backlog as tasks
    • Priority tradeoffs include bug-fixes vs. new features
  • Follow steps from Pilone/Miles, chap 4 (break down into tasks and estimate)

Initiate Test Plan

• Begin regular testing
• Functional, integration, system test (no customer testing yet)

Deploy Alpha Release

• Outline goals for beta and exit criteria
• Identify potential customers/users
• Communicate w/users about goals & feedback mechanism
• Feeds into appropriate spot in Customer Development process
  • Possibly at end of each construction iteration
• Gather feedback and feed into development
  • E.g. Changes desired/required?

Write Customer Support Plan

• How will customers be supported after software is deployed?
• List main goal(s)
• Decide on tools, e.g.
  • External issue tracking
  • FAQ sheets for tech support staff
• Decide on process(es), e.g.
  • Communication w/customer
  • Looking for answer in FAQ
  • How to communicate answer, if known
  • Get closure
  • 2nd tier–investigate, look for workaround
  • Interaction between staff (e.g. support/development)
  • 3rd tier–reported bug, e.g. give bug # and have traceback mechanism
• Escalation process

Execute Deployment Iteration

• Working on deployment tasks, e.g.
  • Installs/uninstalls
  • Distribution/delivery
  • Payment
  • Customer tracking

Deploy Beta Release

• Outline goals for beta and exit criteria
• Identify potential customers/users
• Communicate w/users about goals & feedback mechanism
• Feeds into appropriate spot in Customer Development process
  • Likely after Deployment Iteration
• Gather feedback and feed into development
  • E.g. Changes desired/required?
• Beta should not last indefinitely

Launch Product

• Announce product
• Launch it
• Throw a big party

Begin Planning Next Release

• Post-mortem for Product/Customer Development processes
• Lessons learned
• Changes to process
• Assess organize outstanding bugs
  • Prioritize, estimate
• Organize list of possible future features
  • Plan mechanism for using existing customers to get feedback on priorities
  • Prioritize, estimate
• Decide on schedule for next release
• Map out iterations
  • Each iteration either bug-fixing or new development
  • Bug-fixing phase likely first
• Goal: All bugs fixed prior to next release
• Continued refinement of plan, based on ongoing customer feedback
• Back to start of Product/Customer Development processes for next release
  (follow same processes, including updating relevant plans)

Customer Development Process—Details

Here’s the detailed breakdown of the steps involved in the Customer Development Process.  This comes directly from Four Steps to the Epiphany.

Customer Discovery

• State hypotheses
  • Write briefs, state assumptions about product, customers, pricing, demand, competitors
• Test problem hypotheses
  • Test in front of potential customers
• Test product concept
  • Test product features in front of customers
  • Solves their problem?
  • Also test business model
    • Must-have?
    • Pricing
    • Distribution
• Verify
  • You understand the customer’s problems
  • Your product solves these problems
  • Customers will pay for the product
  • You have in mind a profitable business model
• Repeat if necessary

Customer Validation

• Get Ready to Sell
  • Articulate value proposition
  • Prep sales materials & collateral plan
  • Develop distribution channel plan
  • Develop sales roadmap
  • Hire sales closer
  • Synch up Product/Customer Dev teams on features/dates
  • Formalize advisory board
• Sell to Visionary Customers
  • Sell unfinished product
  • Answer all sales roadmap questions
• Develop Positioning
  • Initial positioning
  • Articulate belief about product and its place in the market
• Verify
  • Enough orders to prove we can sell?
  • Profitable sales model?
  • Profitable business model?
  • Can you scale the business?
• Repeat, if necessary

Customer Creation

• Get Ready to Launch
  • Market Type Questionnaire
  • Choose Market Type
  • Choose 1st Year Objectives
• Position company & product
  • Select PR agency
  • Positioning audits
  • Positioning to market type
• Launch company & product
  • Select launch type
  • Select customer audience
  • Select the messengers
  • Craft the messages
  • Message context
• Create demand
  • Demand creation strategy
  • Demand creation measurements
  • Iterate or exit

Company Building

• Reach mainstream customers
  • Change “earlyvangelists” into mainstream customers
  • Manage sales growth by market type
• Review management / Create mission culture
  • Review management
  • Develop “mission-centric” culture
• Transition to functional departments
  • Set department mission statement
  • Set department roles by market type
• Build fast-response departments
  • Implement mission-centric management
  • Create an “information culture”
  • Build a “leadership culture”

Closing Thoughts

The key takeaway for me from Blank’s book was as follows:

It’s not enough to build a great product.  You must also build a product that the customers need and that they will buy.  It’s also criticial to find a workable business model to sell to the right customers at the right price.

If you haven’t yet read Four Steps to the Epiphany, I’d really encourage you to go out and read it.  Then you can start thinking about how to develop your customers, as well as your product.

Sources

I’ve used the following sources, in varying degrees, for this post:

• Four Steps to the Epiphany, Blank, cafepress.com, 2006.
• The Business of Software, Cusumano, Free Press, 2004.
• The Rational Process Made Easy: A Practitioner’s Guide to the RUP, Kroll, Addison-Wesley, 2003.
• Rapid Development, McConnell, Microsoft Press, 1996.
• Head First Software Development, Pilone & Miles, O’Reilly, 2008.
• Eric Sink on the Business of Software, Sink, Apress, 2006.
• Micro-ISV – From Vision to Reality, Walsh, Apress, 2006.

The obvious place to start in Win 7 is with the installation process.  I’ll put up more posts later with screenshots of various bits and pieces in Windows 7.  But this first post will just contain: every damn Windows 7 installation screen.

Ok, admittedly, looking through install screens is about as exciting as watching bacon fat congeal.  But really—there are people out there who will eat this stuff up.  So it’s for them that I’ve suffered an endless series of screen captures.  Enjoy.

The Environment

I installed my copy of Windows 7 to a VMWare virtual machine.  The only “gotcha” was that VMWare creates a SCSCI virtual hard drive by default—which Windows 7 failed to recognize.  Simple fix—just delete the default hard drive and create an IDE drive in VMWare.

The Screens

Ok, here we go.

You just get shivers as you start to install a new Microsoft OS for the first time, don’t you?

Then we switch from a DOS-looking progress bar to a cute Windows-looking progress bar:

Next we get the first Windows 7 install screen.  This is the spot to insert the angelic music.

After picking an install language, you get to the main install kick-off window:

I once met a guy who actually read these EULAs.  Can you believe it?

This next dialog is just as confusing in Windows 7 as it was in Vista.

In my first try, I went with the Upgrade option, which only got me this next confusing empty dialog.  Nice.

Restarting everything and instead choosing Custom gets us where we want to go:

If you click on the link that reads “Drive options (advanced)”, you’ll see some options for managing hard disk partitions:

Finally, the actual installation begins.

At some point, near the end of the installation, Windows boots for the first time.  It lives!

This was an interesting detail during the boot process:

All of the services apparently start firing up, as the boot process continues.  (Hallelujah)!

And for some reason, we’re allowed to go back and look at this status dialog one more time.

And then back to the main boot screen.  (Are you starting to feel as if you were really there)?

Oh, this is a nice little touch.  No screen flickers or anything, but nice to know that it’s “checking” my video performance.  (Whatever that means).

Now Windows is more or less running and we start doing some of the final configuration stuff.  First, we specify a default username.  This will be the Administrator user account.  Seeing a PC name of “PC” also makes me think of John Hodgman and the Mac switcher ads.

And I enter my password:

And (of course) the product activation key.  Wouldn’t it be cool if every key had a barcode and I could use a barcode scanner at this point?  (My key did not have a barcode).

I also get to set my time and time zone.

This is an interesting one.  Right out of the gate, I’m asked to specify whether my network is public or not.  Like Vista, this dictates some default security settings.

I picked Home network and Windows 7 did some remaining network configuration work.

Ok, here’s one of the first really new things to show up.  A “homegroup” is basically a relabeled “workgroup”—something short of a domain.  I’m wondering if I’d chosen Work location in the earlier screen, if I’d now be joining a domain.

Finally, we are “welcomed” to Windows 7.

We’re so close, I can taste it.

And voila!  The Windows 7 installation is complete and we’re sitting at the desktop screen.  Note that I don’t have that cool new taskbar in the build that was handed out at PDC.  More on that next time—the new taskbar is actually in the build and Rafael Rivera has found a hack to unlock it.

David Teitlebaum
Program Manager
WPF Team

My final session at PDC 2008 was a talk about the improvements in WPF graphics that are available in .NET Framework 3.5 SP1.  David also touched briefly some possible future features (i.e. that would appear in .NET Framework 4.0).

David’s main topic was to walk through the details of the new Shader Effects model, which replaces the old Bitmap Effects feature.

What are Bitmap Effects?

These are effects that are applied to an individual UI element, like a button, to create some desired visual effect.  This includes things like drop shadow, bevels and blur effects.

BitmapEffect

The BitmapEffect object was introduced in Framework 3.0 (the first WPF release).  But there were some problems with it, that led to now replacing it with Shader Effects in 3.5SP1.

Problems with BitmapEffect:

• They were rendered in software
• Blur operations were very slow
• There were various limitations, including no ClearType support, no anisotripic filtering, etc.

New Shader Effects

Basic characteristics in the new Shader Effects include:

• GPU accelerated
• Have implemented hardware acceleration of the most popular bitmap effects
  • But did not implement outer glow
• Can author custom hardware-accelerated bitmap effects using HLSL
• There is a software-only fallback pipeline that is actually faster than the old Bitmap Effects
• New Shader Effects run on most video cards
  • Require PixelShader 2.0, which is about 5 years old

How Do You Do Shader Effects?

Here’s an outline of how you use the new Shader Effect model:

• Derive a custom class from the new ShaderEffect class (which derives from Effect)
• You write your actual pixel shader code in HLSL, which is used for doing custom hardware-accelerated stuff using Direct3D
  • Language is C-like
  • Compiled to byte-code, consumed by video driver, runs on GPU
• Some more details about HLSL, as used in WPF
  • DirectX 10 supports HLSL 4.0
  • WPF currently only supports Pixelshader 2.0

So what do pixel shaders really do?  They basically take in a texture (bitmap) as input, do some processing on each point, and return a revised texture as an output.

Basically, you have a main function that accepts the coordinates of the current single pixel to be mapped.  Your code then accesses the original input texture through a register, so it just uses the input parameter (X/Y coordinate) to index into the source texture.  It then does some processing on the pixel in question and returns a color value.  This resultant color value just represents—the resulting RGB color at the specified coordinate.

The final step is to create, in managed code, a class that derives from ShaderEffect and hook it up to the pixel shader code (e.g. xyz.ps file) that you wrote.  You can then apply your shader to any WPF UIElement using XAML.  (By setting the Effect property).

Direct3D Interop

David’s next topic was to talk a bit about interop’ing with Direct3D.  This just means that your WPF application can easily host Direct3D content by using a new class called D3DImage.

This was pretty cool.  David demoed displaying a Direct3D wireframe in the background (WPF 3D subsystem can’t do wireframes), with WPF GUI elements in the foreground, overlaying the background image.

The basic idea is that you create a Direct3D device in unmanaged code and then hook it to a new instance of a WPF D3DImage element, which you include in your visual hierarchy.

WPF Futures

Finally, David touched very briefly on some possible future features.  These are things that may show up in WPF 4.0 (.NET Framework 4.0), or possibly beyond that.

Some of the features likely included in WPF 4.0 include:

• Increased graphical richness  (e.g. Pixelshader 3.0)
• Offloading more work to the GPU
• Better rendering quality
  • Integrate DirectWrite for text clarity
  • Layout rounding

And some of the possible post-4.0 features include:

• Better exploitation of hardware
• Vertex shaders
• Shader groups
• Shaders in WPF 3D
• 3D improvements
• Better media extensibility

References

You can get at David’s PDC08 slide deck for this talk here: http://mschnlnine.vo.llnwd.net/d1/pdc08/PPTX/PC07.pptx

And you can find full video from the session at:  http://mschnlnine.vo.llnwd.net/d1/pdc08/WMV-HQ/PC07.wmv

Allison Klein

I jumped off the Azure track (starting to be a bit repetitive) and next went to a session focused on Direct3D.

Despite the title, this session really had nothing to do with Windows 7, other than the fact that it talked a  lot about Direct3D 11, which will be included in Windows 7 and available for Windows Vista.

Direct3D 10

Direct3D 10 is the currently shipping version, and supported by most (all?) modern video cards, as well as integrated graphics chips.  I’m not entirely sure, but I think that Direct3D 10 shipped out-of-the-box with Windows Vista.  It is also available for Windows XP.

Allison spent about half of the talk going through things that are different in Direct3D 10, as compared with Direct3D 9.

I’m not inclined to rehash all of the details.  (I’ll include a link to Allison’s slide deck when it is available).

The main takeaway was that it’s very much worth programming to the v10 API, as opposed to the v9 API.  Some of the reasons for this include:

• Much more consistent behavior, across devices
• Cleaner API
• Elimination of large CAPS (device capability) matrix, for a more consistent experience across devices
• Built-in driver that allows D3D10 to talk to D3D9 hardware
• Addition of WARP 10 software rasterizer, to support devices that don’t support WDDM directly.  This is actually quite a bit faster than earlier software-only implementations

Direct3D 11

In the second half of her talk, Allison talked about the advances coming in Direct3D 11.  She mentioned that D3D11 will ship with Windows 7 and also be available for Windows Vista.

Again, the details are probably more appropriate for a game developer.  (See the slide deck).  But the high level points are:

• Direct3D 11 is a strict superset of 10—there are no changes to existing 10 features
• Better support for character authoring, for denser meshes and more detailed characters
• Addition of tessellation to the rendering pipeline, for better performance and quality
• Much more scalable multi-threading support.
  • Much more flexibility in what can be distributed across threads
• Dynamically linking in custom shaders
• Introduction of object-oriented features (interfaces/classes) to HLSL
• New block compression
• Direct3D11 will be available in the Nov 2008 SDK

Futures

Finally, Allison touched briefly on some future directions that the Direct3D is thinking about.

The main topic that she talked about here was in potentially using the GPU to perform highly parallel general purpose compute intensive tasks.  The developer would use HLSL to write a “compute shader”, which would then get sent to the GPU to do the work.  As an example, she talked about using this mechanism for post-processing of an image.

Eugenio Pace

My second session on Thursday was a continuation of the cloud services symposium from the first session.  There was a third part to the symposium, which I did not attend.

The presenter for this session, Eugenio, was not nearly as good a presenter as Gianpaolo from the previous session.  So it was a bit less dynamic, and harder to stay interested.

The session basically consisted of a single demo, which illustrated some of the possible solutions to the Identity, Monitoring, and Integration challenges mentioned in the previous session.

Identity

Eugenio pointed out the problems involved in authentication/authorization.  You don’t want to require the enterprise users to have a unique username/password combination for each service that they use.  And pushing out the enterprise (e.g. Active Directory) credential information to the third party service is not secure and creates a management nightmare.

The proposed solution is to use a central (federated) identity system to do the authentication and authorization.  This is the purpose of the Azure Access Control service.

Management

The next part of the demo showed how Azure supports remote management, on the part of IT staff at an individual customer site, of their instance of your application.  The basic things that you can do remotely include:

• Active real-time monitoring of application health
• Trigger administrative actions, based on the current state

The end result (and goal) is that you have the same scope of control over your application as you’d have if it were on premises.

Application Integration

Finally, Eugenio did some demos related to “process integration”—allowing your service to be called from a legacy service or system.  This demo actually woke everyone up, because Eugenio brought an archaic green-screen AS400 system up in an emulator and proceeded to have it talk to his Azure service.

Takeaways

The conclusions were recommendations to both IT organizations and ISVs:

• Enterprise IT organization
  • Don’t settle for sub-optimal solutions
  • Tap into the benefits of Software+Services
• ISV
  • Don’t give them an excuse to reject your solution
  • Make use of better tools, frameworks, and services

Gianpaolo Carraro

As the last day of PDC starts, I’m down to four sessions to go.  I’ll continue doing a quick blog post on each session, where I share my notes, as well as some miscellaneous thoughts.

The Idea of a Symposium

Gianpaolo started out by explaining that they were finishing PDC by doing a pair of symposiums, each a series of three different sessions.  One symposium focused on parallel computing and the other on cloud-based services.  This particular session was the first in the set of three that addressed cloud services.

The idea of a symposium, explained Gianpaolo, is to take all of the various individual technologies and try to sort of fit the puzzle pieces together, providing a basic context.

The goal was also present some of the experience that Microsoft has gained in early usage of the Azure platform over the past 6-12 months.  He said that he himself has spent the last 6-12 months using the new Services, so he had some thoughts to share.

This first session in the symposium focused on taking existing business applications and expanding them to “the cloud”.  When should an ISV do this?  Why?  How?

Build vs. Buy and On-Premises vs. Cloud

Gianpaolo presented a nice matrix showing the two basic independent decisions that you face when looking for software to fulfill a need.

• Build vs. Buy – Can I buy a packaged off-the-shelf product that does what I need?  Or are my needs specialized enough that I need to build my own stuff?
• On-Premises vs. Cloud – Should I run this software on my own servers?  Or host everything up in “the cloud”?

There are, of course, tradeoffs on both sides of each decision.  These have been discussed ad infinitum elsewhere, but the basic tradeoffs are:

• Build vs. Buy – Features vs. Cost
• On-Premises vs. Cloud – Control vs. Economy of Scale

Here’s the graph that Gianpaolo presented, showing six different classes of software, based on how you answer these questions.  Note that on the On-Premises vs. Cloud scale, there is a middle column that represents taking applications that you essentially control and moving them to co-located servers.

This is a nice way to look at things.  It shows that, for each individual software function, it can live anywhere on this graph.  In fact, Gianpaolo’s main point is that you can deploy different pieces of your solution at different spots on the graph.

So the idea is that while you might start off on-premises, you can push your solution out to either a co-located hosting server or to the cloud in general.  This is true of both packaged apps as well as custom-developed software.

Challenges

The main challenge in moving things out of the enterprise is dealing with the various issues that show up now when your data needs to cross the corporate/internet boundary.

There are several separate types of challenges that show up:

• Identify challenges – as you move across various boundaries, how does the software know who you are and what you’re allowed to access?
• Monitoring and Management challenges – how do you know if your application is healthy, if it’s running out in the cloud?
• Application Integration challenge – how do various applications communicate with each other, across the various boundaries?

Solutions to the Identity Problem

Gianpaolo proposed the following possible solutions to this problem of identity moving across the different boundaries:

• Federated ID
• Claim-based access control
• Geneva identity system, or Cardspace

The basic idea was that Microsoft has various assets that can help with this problem.

Solutions to the Monitoring and Management Problem

Next, the possible solutions to the monitoring and management problem included:

• Programmatic access to a “Health” model
• Various management APIs
• Firewall-friendly protocols
• Powershell support

Solutions to the Application Integration Problem

Finally, some of the proposed solutions to the application integration problem included:

• ServiceBus
• Oslo
• Azure storage
• Sync framework

The ISV Perspective

The above issues were all from an IT perspective.  But you can look at the same landscape from the perspective of an independent software vendor, trying to sell solutions to the enterprise.

To start with, there are two fundamentally different ways that the ISV can make use of “the cloud”:

• As a service mechanism, for delivering your services via the cloud
  • You make your application’s basic services available over the internet, no matter where it is hosted
  • This is mostly a customer choice, based on where they want to deploy
• As a platform
  • Treating the cloud as a platform, where your app runs
  • Benefits are the economy of scale
  • Mostly an ISV choice
  • E.g. you could use Azure without your customer even being aware of it

When delivering your software as a service, you need to consider things like:

• Is the feature set available via cloud sufficient?
• Firewall issues
• Need a management interface for your customers

Some Patterns

Gianpaolo presented some miscellaneous design considerations and patterns that might apply to applications deployed in the cloud.

Cloudbursting

• Design for average load, handling the ‘peak’ as an exception
• I.e. only go to the cloud for scalability when you need to

Worker / Queue / Blob Pattern

Let’s say that you have a task like encoding and publishing of video.  You can push the data out to the cloud, where the encoding work happens.  (Raw data places in a “blob” in cloud storage).  You then add an entry to a queue, indicating that there is work to be done, and a separate worker process eventually does the encoding work.

This is a nice pattern for supporting flexible scaling—both the queues and the worker processes could be scaled out separately.

CAP: Pick 2 out of 3

• Consistency
• Availability
• Tolerance to network Partitioning

Eventual Consistency (ACID – BASE)

The idea here is that we are all used to the ACID characteristics listed below.  We need to guarantee that the data is consistent and correct—which means that performance likely will suffer.  As an example, we have a process submit data synchronously because we need to guarantee that the data gets to its destination.

But Gianpaolo talked about the idea of “eventual consistency”.  For most applications, while it’s important for your data to be correct and consistent, it’s not necessarily for it to be consistent right now.  This leads to a model that he referred to as BASE, with the characteristics listed below.

• ACID
  • Atomicity
  • Consistency
  • Isolation
  • Durability
• BASE
  • Basically Available
  • Soft state
  • Eventually consistent

Fundamental Lesson

Basically the main takeaway is:

• Put the software components in the place that makes the most sense, given their use

Arash Ghanaie-Sichanie

Throughout the conference, I bounced back and forth between Azure and Live Mesh sessions.  I was trying to make sense of the difference between them and understand when you might use one vs. the other.

I understand that Azure Services is the underlying platform that Live Services, and Live Mesh, are built on.  But at the outset, it still wasn’t quite clear what class of applications Live Services were targeted at.  Which apps would want to use Live Services and which would need to drop down and use Azure?

I think that after Arash’s talk, I have a working stab at answering this question.  This is sort of my current understanding, that I’ll update as things become more clear.

Question: When should I use Live Services / Live Mesh ?

Answer:

• Create a Live Mesh application (Mesh-enabled) if your customers are currently, or will become, live.com customers.
• Otherwise, use Azure cloud-based services outside of Live, or the other services built on top of Azure:
  • Azure storage services
  • Sync Framework
  • Service Bus
  • SQL Data Services

Unless I’m missing something, you can’t make use of features of the Live Operating Environment, either as a web application or a local desktop client, unless your application is registered with Live.com, and your user has added your application to his account.

The one possible loophole that I can see is that you might just have your app always authorize, for all users, using a central account.  That account could be pre-created and pre-configured.  Your application would then use the same account for all users, enabling some of the synchronization and other options.  But even this approach might not work—it’s possible that any device where local Mesh data is to be stored needs to be registered with that Live account and so your users wouldn’t normally have the authorization to join their devices to your central mesh.

Three Takeaways

Arash listed three main takeaways from this talk:

• Live Services add value to different types of applications
• Mesh-enabled web apps extend web sites to the desktop
• The Live Framework is a standards-based API, available to all types of apps

How It All Works

The basic idea is to start with a “Mesh-enabled” web site.  This is a web site that delivers content from the user’s Mesh, including things like contacts and files.  Additionally, the web application could store all of its data in the Mesh, rather than on the web server where it is hosted.

Once a web application is Mesh-enabled, you have the ability to run it on various devices.  You basically create a local client, targeted at a particular platform, and have it work with data through the Live Framework API.  It typically ends up working with a cached local copy of the data, and the data is automatically synchronized to the cloud and then to other devices that are running the same application.

This basically implements the Mesh vision that Ray Ozzie presented first at Mix 2008 in Las Vegas and then again at PDC 2008 in Los Angeles.  The idea is that we move a user’s data into the cloud and then the data follows them around, no matter what device they’re currently working on.  The Mesh knows about a user’s:

• Devices
• Data, including special data like Contacts
• Applications
• Social graph  (friends)

The User’s Perspective

The user must do a few things to get your application or web site pointing at his data.  As a developer, you send him a link that lets him go sign up for a Live.com account and then register your application in his Mesh.  Registration, from the user’s perspective, is a way for him to authorize your application to access his Mesh-based data.

Again, it’s required that the user has, or get, a Live.com account.  That’s sort of the whole idea—we’re talking about developing applications that run on the Live platform.

Run Anywhere

There is still work to be done, on the part of the developer, to be able to run the application on various devices, but the basic choices are:

• Locally, on a client PC or Mac
• In a web browser, anywhere
• From the Live Desktop itself, which is hosted in a browser

(In the future, with Silverlight adding support for running Silverlight-sandboxed apps outside of the browser, we can imagine that as a fourth option for Mesh-enabled applications).

The Developer’s Perspective

In addition to building the mesh application, the developer must also register his application, using the Azure Services Portal.  Under the covers, the application is just an Azure-based service.  And so you can leverage the Azure standard goodies, like running your service in a test mode and then deploying/publishing it.

One other feature that is made available to Mesh application authors is the ability to view basic Analytics data for your application.  Because the underlying Mesh service is aware of your application, wherever it is running, it can collect data about usage.    The data is “anonymized”, so you can’t see data about individual users, but can view general metrics.

Arash talked in some detail about the underlying security model, showing how a token is granted to the user/application.

Conclusions

Mesh obviously seems a good fit for some applications.  You can basically run on a platform that gives you a lot of services, as well as access to useful data that may already exist in a particular user’s Mesh environment.  There is also some potential for cross-application sharing of data, once common data models are agreed upon.

But the choice to develop on the Mesh platform implies a decision to sign your users up as part of the Mesh ecosystem.  While the programming APIs are entirely open, using basic HTTP/REST protocols, the platform itself is owned/hosted/run exclusively by Microsoft.

Not all of your users will want to go through the hassle of setting up a Live account in order to use your application.  What makes it a little worse is that the process for them is far from seamless.  It would be easier if you could hide the Live branding and automate some of the configuration.  But the user must actually log into Live.com and authorize your application.  This is a pretty high barrier, in terms of usability, for some users.

This also means that your app is betting on the success of the Live.com platform itself.  If the platform doesn’t become widely adopted, few users will live (pardon the pun) in that environment.  And the value of hosting your application in that ecosystem becomes less clear.

It remains to be seen where Live as a platform will go.  The tools and the programming models are rich and compelling.  But whether the platform will live up to Ozzie’s vision is still unclear.

Pablo Castro

I attended a second session with Pablo Castro (the previous one was the session on Azure Tables).  This session focused on a future capability in ADO.NET Data Services that would allow taking data services “offline” and then occasionally synching them with the online data.

Background – Astoria

ADO.NET Data Services was recently released as part of the .NET Framework 3.5 SP1 release.  It was formerly known as project “Astoria”.

The idea of ADO.NET Data Services is to allow creating a data service that lives on the web.  Your data source can be anything—a SQL Server database, third-party database, or some local data store.  You wrap your data source using the Entity Data Model (EDM) and ADO.NET Data Services Runtime.  Your data is now available over the web using standard HTTP protocols.

Once you have a data service that is exposed on the web, you can access it from any client.  Because the service is exposed using HTTP/REST protocols, you can access your data using simple URIs.  By using URIs, you are able to create/read/update/delete your data (POST/GET/PUT/DELETE in REST terms).

Because we can access the data using HTTP, our client is not limited to a .NET application, but can be any software that knows about the web and HTTP.  So we can consume our data from Javascript, Ruby, or whatever.  And the client could be a web-based application or a thick client somewhere that has access to the web.

If your client is a .NET client, you can use the ADO.NET Data Services classes in the .NET Framework to access your data, rather than having to build up the underlying URIs.  You can also use LINQ.

So that’s the basic idea of using ADO.NET Data Services and EDM to create a data service.  For more info, see:

• ADO.NET Data Services home page on MSDN
• ADO.NET Entity Framework home page on MSDN
• Alex Barnett’s blog post with basic info on REST

The Data Synchronization Landscape

Many of the technologies that made an appearance at PDC 2008 make heavy use of data synchronization.  Data synchronization is available to Azure cloud services or to Live Mesh applications.

The underlying engine that handles data synchronization is the Microsoft Sync Framework.  The Sync Framework is a synchronization platform that allows creating sync providers, sitting on top of data that needs to be synchronized, as well as sync consumers—clients that consume that data.

The basic idea with sync is that you have multiple copies of your data in different physical locations and local clients that make use of that data.  Your client would work with its own local copy of the data and then the Sync Framework would ensure that the data is synched up with all of the other copies of the data.

What’s New

This session talked about an effort to add support in ADO.NET Data Services for offline copies of your Astoria-served data, using the Sync Framework to do data synchronization.

Here are the basic pieces (I’m too lazy to draw a picture).  This is just one possible scenario, where you want to have an application that runs locally and makes use of a locally cached copy of your data, which exists in a database somewhere:

• Data mainly “lives” in a SQL Server database.  Assume that the database itself is not exposed to the web
• You’ve created a data service using ADO.NET Data Services and EDM that exposes your SQL Server Data to the web using a basic REST-based protocol.  You can now do standard Create/Read/Update/Delete operations through this interface
• You might have a web application running somewhere that consumes this data.  E.g. A Web 2.0 site built using Silverlight 2, that allows viewing/modifying the data.  Note that the web server does not have a copy of your data, but goes directly to the data service to read/write its data.
• Now you create a thick client that also wants to read/write your data.  E.g. A WPF application.  To start with, you assume that you have a live internet connection and you configure the application to read/write data directly from/to your data service

At this point, you have something that you could build today, with the tools in the .NET Framework 3.5 SP1.  You have your data out “in the cloud” and you’ve provided both rich and thin clients that can access the data.

Note: If you were smart, you would have reused lots of code between the thin (Silverlight 2) and thick (WPF) clients.  Doing this gives your users the most consistent GUI between online and offline versions.

Now comes the new stuff.  Let’s say that you have cases when you want your thick WPC client to be able to work even though the Internet connection is not present.  Reasons for doing this include:

• You’re working on a laptop, somewhere where you don’t have an Internet connection (e.g. airplane)
• You want the application to be more reliable—i.e. app is still usable even if the connection disappears from time to time
• You’d like the application to be slightly better performing.  As it stands, the performance depends on network bandwidth.  (The “lunchtime slowdown” phenomenon).

Enter Astoria Offline.  This is the set of extensions to Astoria that Pablo described, which is currently not available, but planned to be in Alpha by the end of the year.

With Astoria Offline, the idea is that you get a local cache of your data on the client PC where you’re running your thick client.  Then what happens is the following:

• Your thick (WPF) application works directly with the offline copy of the data
• Performance is improved
• Much more reliable—the data is always there
• You initiate synchronization (or set it up from time to time) to synch data back to the online copy

This synchronization is accomplished using the new Astoria Offline components.  When you do synchronize, the synchronization is two-ways, which means that you update both copies with any changes that have occurred since you last synched:

• All data created locally is copied up to the online store
• Data created online is copied down
• Changes are reconciled—two-way
• Deletions are reconciled—two-way

Pablo did a basic demo of this scenario and it worked just as advertised.  He showed that the client worked with the local copy of the data and that everything synched properly.  He also showed off some early tooling in Visual Studio that will automate much of the configuration that is required for all of this to work.

Interestingly, it looked like in Pablo’s example, the local copy of the data was stored in SQL Server Express.  This was a good match, because the “in the cloud” data was stored in SQL Server.

How Did They Do It?

Jump back to the description of the Microsoft Sync Framework.  Astoria Offline is using the sync framework to do all of the underlying synchronization.  They’ve written a sync provider that knows about the entity data model and interfaces between EDM and the sync framework.

Extensibility Points

I’m a little fuzzier on this area, but I think I have a general sense of what can be done.

Note that the Sync Framework itself is extensible—you can write your own sync providers, providing synchronized access to any data store that you care to support.  Once you do this, you get 2-way (or more) synchronization between your islands of custom data.

But if I understood Pablo correctly, it sounds like you could do this a bit differently with Astoria Offline in place.  It seems like you could pump your custom data from the Entity Framework, by building a custom data source so that the EDM can see your data.  (EntityFrameworkSyncProvider fits in here somewhere).  I’m guessing that once you serve up your data in a relational manner to the EDM, you can then synch it using the Astoria Offline mechanisms.  Fantastic stuff!

Going Beyond Two Nodes

One could imagine going beyond just an online data source and an offline copy.  You could easily imagine topologies that had many different copies of the data, in various places, all being synched up from time to time.

Other Stuff

Pablo talked about some of the other issues that you need to think about.  Conflict detection and resolution is a big one.  What if two clients both update the same piece of data at the same time?  Classic synchronization issue.

The basic things to know about conflicts, in Astoria Offline, are:

• Sync Framework provides a rich model for detecting/resolving conflicts, under the covers
• Astoria Offline framework will detect conflicts
• The application provides “resolution handlers” to dictate how to resolve the conflict
  • Could be locally—e.g. ask the user what to do
  • Or online—automatic policies

Pablo also talked briefly about the idea of Incremental Synchronization.  The idea is that you might want to synch things a little bit at a time, in a batch-type environment.

There was a lot more stuff here, and a lot to learn.  Much of the concepts just bubble up from the Sync Framework.

Takeaways

Astoria Offline is potentially game-changing.  In my opinion, of the new technologies presented at PDC 2008, Astoria Offline is the one most likely to change the landscape.  In the past, vendors have generally had to pick between working with live data or local data.  Now they can do both.

In the past, the online vs. offline data choice was driven by whether you needed to share the data across multiple users.  So the only apps that went with offline data were the ones that didn’t need to share their data.  What’s interesting about Astoria Offline is that these apps/scenarios  can now use this solution to leave their data essentially local, but make the data more mobile, across devices.  Imagine an application that just stores local data that only it consumes.  But now if you want to run that app on multiple machines, you have to manually copy the data—or move it to a share seen by both devices.  With Astoria Offline, you can set up a sync to an online location that each device synchs to, as needed.  So you can just move from device to device and your data will just follow you.  So you can imagine that this makes it much easier to move apps out to mobile devices.

This vision is very similar to what Live Mesh and Live Services promise.  But the difference is that here you don’t need to subscribe to your app and its data living in the MS Live space.  Your data can be in whatever format you like, and nobody needs to sign up with MS Live.

When Can I Get It?

Pablo mentioned a basic timeline:

• Early Alpha by the end of the year
• CTPs later, i.e. next year

Resources

In addition to the links I listed above, you might also check out:

• Project Astoria Team Blog
• Design Walkthrough of Astoria Offline Alpha Preview

Pablo Castro, Niranjan Nilakantan

Pablo and Niranjan did a session that went into some more detail on how the Azure Table objects can be used store data in the cloud.

Context

This talk dealt with the “Scalable Storage” part of the new Azure Services platform.  Scalable Storage is a mechanism by which applications can store data “in the cloud” in a highly scalable manner.

Data Types

There are three fundamental data types available to applications using Azure Storage Services:

• Blobs
• Tables
• Queues

This session focused mainly on Tables.  Specifically, Niranjan and Pablo addressed the different ways that an application might access the storage service programmatically.

Tables

Tables are a “massively scalable” data type for cloud-based storage.  They are able to store billions of rows, are highly available, and “durable”.  The Azure platform takes care of scaling out the data automatically to multiple servers, if necessary.  (With some hints on the part of the developer).

Programming Model

Azure Storage Services are accessed through the ADO.NET Data Services (Astoria).  Using ADO.NET Data Sercices, there are basically two ways for an application to access the service.

• .NET API   (System.Data.Services.Client)
• REST interface   (using HTTP URIs directly)

Data Model

It’s important to note that Azure knows nothing about your data model.  It does not store data in a relational database or access it via a relational model.  Rather, you specify a Table that you’d like to store data in, along with a simple query expression for the data that you’d like to retrieve.

A Table represents a single Entity and is composed of a collection of rows.  Each row is uniquely defined by a Row Key, which the developer specifies.  Additionally, the developer specifies a Partition Key, which is used by Azure in knowing how to split the data across multiple servers.

Beyond the Record Key and Partition Key, the developer can add any other properties that she likes, up to a total of 255 properties.  While the Record and Partition Keys must be string data types, the other properties support other data types.

Partitioning

Azure storage services are meant to be automatically scalable, meaning that the data will be automatically spread across multiple servers, as needed.

In order to know how to split up the data, Azure uses a developer-specified Partition Key, which is one of the properties of each record.  (Think “field” or “column”).

The developer should pick a partition key that makes sense for his application.  It’s important to remember two things:

• Querying for all data having a single value for a partition key is cheap
• Querying for data having multiple partition key values is more expensive

For example, if your application often retrieves data by date and shows data typically for a single day, then it would make sense to have a CurrentData property in your data entity and to make that property the Partition Key.

The way to think of this is that each possible unique value for a Partition Key represent a “bucket” that will contain one or more records.  If you pick a key that results in only one record per bucket, that would be inefficient.  But if you pick a key that results in a set of records in the bucket that you are likely to ask for together, this will be efficient.

Accessing the Data Programmatically

Pablo demonstrated creating the classes required to access data stored in an Azure storage service.

He started by creating a class representing the data entity to be stored in a single table.  He selected and defined properties for the Partition and Record key, as well as other properties to store any other desired data in.

Pablo also recommended that you create a single class to act as an entry point into the system.  This class then acts as a service entry point for all of the data operations that your client application would like to perform.

He also demonstrated using LINQ to run queries against the Azure storage service.  LINQ automatically created to corresponding URI to retrieve, create, update, or delete the data.

Miscellaneous

Pablo and Niranjan also touched on a few other issues that most applications will deal with:

• Dealing with concurrent updates  (uses Etag and if-match)
• Pagination  (using continuation tokens)
• Using Azure Queues for pseudo-transactional deletion of data

Takeaways

Pablo and Niranjan demonstrated that it was quite straightforward to access Azure storage services from a .NET application.  It’s also the case that non-.NET stacks could make use of the same services using a simple REST protocol.

It was also helpful to see how Pablo used ADO.NET Data Services to construct a service layer on top of the Azure storage services.  This seems to make consuming the data pretty straightforward.

(I still might have this a little confused—it’s possible that Astoria was just being used to wrap Azure services, rather than exposing the data in an Astoria-based service to the client.  I need to look at the examples in a little more detail to figure this out).

Original Materials

You can find the video of the session at:  http://mschnlnine.vo.llnwd.net/d1/pdc08/WMV-HQ/ES07.wmv

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:

Summary

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:  http://mschnlnine.vo.llnwd.net/d1/pdc08/WMV-HQ/PC35.wmv

You can play with “live” samples of the various controls at: http://silverlight.net/samples/sl2/toolkitcontrolsamples/run/default.html

Charting samples can be found at:  http://silverlight.net/samples/sl2/toolkitchartsamples/run/default.html

Ori Amiga

My next session dug a bit deeper into the Live Framework and some of the architecture related to building a Live Mesh application.

Ori Amiga was presenting, filling in for Dharma Shukla (who just became a new Dad).

Terminology

It’s still a little unclear what terminology I should be using.  In some areas, Microsoft is switching from “Mesh” to just plain “Live”.  (E.g. Mesh Operating Environment is now Live Operating Environment).  And the framework that you use to build Mesh applications is the Live Framework.  But they are still very much talking about “Mesh”-enabled applications.

I think that the way to look at is this:

• Azure is the lowest level of cloud infrastructure stuff
• The Live Operating Environment runs on top of Azure and provides some basic services useful for cloud applications
• Mesh applications run on top of the LOE and provide access to a live.com user’s “mesh”: devices, applications and data that lives inside their mesh

I think that this basically means that you could have an application that makes use of the various Live Services in the Live Operating Environment without actually being a Mesh application.  On the other hand, some of the services in the LOE don’t make any sense to non-Mesh apps.

Live Operating Environment  (LOE)

Ori reviewed the Live Operating Environment, which is the runtime that Mesh applications run on top of.  Here’s a diagram from Mary Jo Foley’s blog:

This diagram sort of supports my thought that access to a user’s mesh environment is different from the basic stuff provide in the LOE.  According to this particular view, Live Services are services that provide access to the “mesh stuff”, like their contact lists, information about their devices, the data stores (data stored in the mesh or out on the devices), and other applications in that user’s mesh.

The LOE would contain all of the other stuff—basic a set of utility classes, akin to the CLR for desktop-based applications.  (Oh wait, Azure is supposed to be “akin to the CLR”). *smile*

Ori talked about a list of services that live in the LOE, including:

• Scripting engine
• Formatters
• Resource management
• FSManager
• Peer-to-peer communications
• HTTP communications
• Application engine
• Apt(?) throttle
• Authentication/Authorization
• Notifications
• Device management

Here’s another view of the architecture (you can also find it here).

Also, for more information on the Live Framework, you can go here.

Data in the Mesh

Ori pointed out an important point about how Mesh applications access their data.  If you have a Mesh client running on your local PC, and you’ve set up its associated data store to synch between the cloud and that device, the application uses local data, rather than pulling data down from the cloud.  Because it’s working entirely with locally cached data, it can run faster than the corresponding web-based version (e.g. running in the Live Desktop).

Resource Scripts

Ori talked a lot about resource scripts and how they might be used by a Mesh-enabled application.  An application can perform actions in the Mesh using these resource scripts, rather than performing actions directly in the code.

The resource scripting language contains things like:

• Control flow statements – sequence and interleaving, conditionals
• Web operation statements – to issue HTTP POST/PUT/GET/DELETE
• Synchronization statements – to initiate data synchronization
• Data flow constructs – for binding statements to other statements(?)

Ori did a demo that showed off a basic script.  One of the most interesting things was how he combined sequential and interleaved statements.  The idea is that you specify what things you need to do in sequence (like getting a mesh object and then getting its children), and what things you can do in parallel (like getting a collection of separate resources).  The parallelism is automatically taken care of by the runtime.

Custom Data

Ori also talked quite a bit about how an application might view its data.  The easiest thing to do would be to simply invent your own schema and then be the only app that reads/writes the data in that schema.

A more open strategy, however, would be to create a data model that other applications could use.  Ori talked philosophically here, arguing that this openness serves to improve the ecosystem.  If you can come up with a custom data model that might be useful to other applications, they could be written to work with the same data that your application uses.

Ori demonstrated this idea of custom data in Mesh.  Basically you create a serializable class and then mark it up so that it gets stored as user data within a particular DataEntry.  (Remember: Mesh objects | Data feeds | Data entries).

This seems like an attractive idea, but it seems a bit clunky.  The custom data is embedded into the standard AtomPub stream, but not in a queryable way.  It looked more like it was jammed into an XML element in the <DataEntry> element.  This means that your custom data items would not be directly queryable.

Ori did go on to admit that custom data isn’t queryable or indexable, but really only for “lightweight data”.  This is really at odds with the philosophy of a reusable schema for other applications.

Tips & Tricks

Finally, Ori presented a handful of tips & tricks for working with Mesh applications:

• To clean out local data cache, just delete the DB/MR/Assembler directories and re-synch
• Local metadata is actually sotred in SQL Server Express.  Go ahead and peek at it, but be careful not to mess it up.
• Use the Resource Model Browser to really see what’s going on under the covers.  What it shows you represents the truth of what’s happening between the client and the cloud
• One simple way to track synch progress is to just look at the size of the Assembler and MR directories
• Collect logs and send to Microsoft when reporting a problem

Summary

Ori finished with the following summary:

• Think of the cloud as just a special kind of device
• There is a symmetric cloud/client programming model
• Everything is a Resource

Rick Rashid

Rick Rashid, Senior Vice President of Microsoft Research, delivered the final PDC 2008 keynote.

Rick described how Microsoft Research is organized and talked about their mission statement:

• Expand state of the art in each area in which we do research
• Rapidly transfer innovative technologies into Microsoft products
• Ensure that Microsoft products have a future

The Microsoft behemoth is truly impressive.  Here are a couple of tidbits:

• 10-30% of papers presented at most CSci and Software Engineering academic conferences are  by Microsoft Research
• Microsoft Research employees about 850 Ph.D. researchers—about as large a staff as most research-oriented universities

Mr. Rashid made a good case for why we do basic research.  It’s not so much for the immediate applications.  Instead, he argued the goals are to enable a company to respond quickly to change, based on an existing reservoir of people and technologies that can be brought to bear on new problems.

I for one was expecting some cool demos at the Research keynote.  There were several demos, but they started out as fairly mundane.

Feng Zhao – Energy Sensing

The first demo was by Feng Zhao, a Principal Researcher.  He talked about a little climate sensor that Microsoft developed and which they been using to gather climate data.

The first example was indoors.  Microsoft had actually hung a large number of these sensors from the ceiling of the keynote auditorium.  They’d then been acquiring basic temperature data for several days and transmitting that data back to a server.  Feng was able to show all kinds of graphs showing the temperature map of the room, including how it warmed up a little when people came in.

Feng also explained how they are using similar sensors in outdoor climactic research projects.  For example, they collect various data about Alpine climate data in Switzerland.

World Wide Telescope

The next demo was definitely a notch above the energy sensing.

The WorldWide Telescope is a Microsoft Research project that went public earlier this year.  It’s a web site that ties together a huge database of space images from all different sources.  The end result is a 3D virtual universe that you can fly around in, navigating to and viewing various objects.  As you zip around in the universe, you automatically see stitched together images of whatever objects would be in your view.

Microsoft announced in this keynote a new version of WorldWide Telescope, being released today.  It included lots of new images, as well as improved views of our solar system.

The demo of the new WorldWide Telescope site was truly awe-inspiring.

Boku

The energy level  went up a little bit more as Matt MacLaurin came out to demo Boku—an animated world used to teach kids how to program.

In the Boku world, kids create “programs” visually by selecting objects and then icons indicating what those objects should do.  Actions can include things like moving towards other objects, eating objects, or shooting at objects.

The demo was pretty impressive.  The little Boku world was rendered beautifully in 3D and Matt was able to very quickly create and animate objects.  More important is that he said that kids find the resulting “programming” environment very intuitive to use.  This allows them to learn basic logic and programming skills at a very early age.

Boku was great, but nothing compared to what came next.

SecondLight

Most of us have seen the online videos and demos of the Microsoft Surface.  The basic idea is that a PC projects an image of a user interface surface up onto a flat table that you can interact with by touching.  It’s sort of a combination coffee table and touchable PC screen.

The big thing about Surface is that it supports something called “multi-touch”.  So not only can you move things around on the surface by touch/dragging with one finger, you can initiate more complicated gestures by using two fingers at the same time.  For example, you might  use your thumb and forefinger to zoom into a photo by putting both fingers down and then spreading them apart.

Surface also includes an infrared camera that allows it to “see” things placed on the surface itself.  This allows user interaction with simple objects, or even something like a user’s arm.  (Think about a Poker game that would flip your cards over when it saw you put your arm down to block them from another player’s view).

That’s the basic idea of Surface.  It’s available today, for something like $15,000.

But at today’s keynote, several of the guys from the Surface team demoed the next big extension to Surface, which they called SecondLight.

The basic idea of SecondLight is to extend both the project area and the infrared detection mechanism out into the space above the surface.  So if I held up a piece of tracing paper 8-10” above the surface, I’d see an image on it, as well as the surface.  Ok, no big deal, right?  Well, the big deal is that the image on the tracing paper is different from the image on the surface below it?

The guys’ demo showed how this might work.  Let’s say you’re looking at a Virtual Earth map that showed an aerial view of some location.  The Surface would display the standard aerial view of the place.  Now let’s say that you hold a little sheet of tracing paper above the Surface, over one particular area of the map.  Surface might project out a street view, rather than aerial view onto your paper.  But the main surface of the table will continue to show the original aerial view.  Other applications might be to provide a photo on the Surface and then some description about that photo on the paper that you hold over it.

How the hell do they do that?  Well, they explained that their projector down under the table can actually interlace two completely separate images—one that they project up to the surface and one that they project beyond the surface.  This happens at such a high frequency that you don’t see any flicker and see both images simultaneously.

But wait, there’s more!  Now the guys demonstrated how Surface can also detect objects above the table with its infrared camera.  They took a little picture frame with a plastic see-through surface—something about 4-5” across.  To start with, there was a silhouette of a man on the main Surface.  Now when they held the see-through frame above the Surface, the man moved from the Surface up to the surface of their handheld picture frame.  Truly a “holy shit” moment.  Even more incredible, the presenter started slowly tilting the picture frame from horizontal to vertical.  As he did this, the aspect ratio of the man on the frame stayed the same—as opposed to the projection becoming narrower.  The effect was as if you’d grabbed the silhouette off the flat surface and stood it up.  Unbelievable.

How did they do this last part?  Well, simple—the infrared camera can see the outline of the handheld frame, so it knows its dimensions.  And it then pre-foreshortens the image of the man, so the entire image of the man is mapped to the entire size of the picture frame.  The result is that the man stands up.

This final demo was truly the highlight of the keynote and it made up for all of the boring opening acts.  There are many ways that you can imagine using GUI technology like this.  Just think of a computer that can recognize your face and see where you are.  We’re in for some truly amazing advances in user interaction over the next few years.

You can find a video of the demo at: http://www.youtube.com/watch?v=XfzplPIrzjY

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

Tools

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.

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.

Mike Flasko

Ok, I’m finally starting to understand the very basics of Astoria (now branded ADO.NET Data Services), as well as how it relates to the Entity Data Model and SQL Data Services.

There have been a lot of new data-related services and features coming out of Microsoft lately.  Astoria, SQL Data Services, the Entity Data Model, dynamic data in ASP.NET, etc.  Without understanding what each of them does, it’s hard to see how they all fit together, or when you’d use the different services.

Mike Flasko started this session by talking at the “data services landscape”.  (He had a nice picture that I’d include here if I had a copy).  There are a few points to be made about the various data services:

• A wide spectrum of data services available
• Some you create yourself, some 3rd party
• Some on-premises, some hosted/cloud
• Characteristics of Microsoft-supplied services
  • Simple REST interface
  • Uniform interface  (URIs, HTTP, AtomPub) — i.e. underlying data is different, but you access it in the same way, no matter the service used

(By the way, the new buzzword at PDC 2008 is “on premises” data and services—to be contrasted with data and services that reside “in the cloud”).

ADO.NET Data Services fits in as follows—it’s a protocol for serving up data from different underlying sources using feeds and a REST-ful interface.

The basic idea behind REST and feeds is that this is a simple HTTP-based protocol—which means that any tool running on any platform or development stack can make use of it.  For example, because we use a simple HTTP GET request to read data, any browser or software that knows how to access the web can read our data.

REST is basically a way to piggyback classic CRUD data operations on top of existing HTTP verbs.  Here’s how they map:

• HTTP POST – Create a data item(s?)
• HTTP GET – Read one or more data items
• HTTP PUT – Update a data item(s?)
• HTTP DELETE – Delete a data item(s?)

As an example of how you might use ADO.NET Data Services to provide a uniform API to multiple data sources, Mike talked about an application reading/writing data from several different locations:

• From an on-premises SQL Server database
• From SQL Data Services

In both cases, you access the data through the ADO.NET Data Services framework, instead of going to SQL Server or the SQL Data service directly.  You can easily add an ADO.NET Data Services layer that sits on top of an on-premises SQL Server databases.  And Mike said that SQL Data Services will support the ADO.NET Data Services conventions.

Mike did a nice demo showing exactly how you might consume on-premises SQL Server data through an ADO.NET Data Services API.  He started by creating a data model using the Entity Data Model framework.  The Entity Data Model is basically just an object/relational mapper that allows you to build a logical data model on top of your physical database.  Once you’ve done this, you just create a service that wires up to the Entity Data Model and exposes its data through ADO.NET Data Services (i.e. a REST-ful interface).

Mike then walked through the actual code for accessing the service that he created.  At this point, you can do everything (Create/Read/Update/Delete) using HTTP POST/GET/PUT/DELETE and simple ASCII URIs.  For example, you can read one or more data elements by just entering the correct URI in your browser.  (Because the browser does an HTTP GET by default).

But… This does not mean that your application has to traffic exclusively in an HTTP-based API.  It would be ugly to have your .NET managed code doing all of its data access by building up URI strings.  Instead, there is a standard .NET namespace built on top of the REST-based interface that you’d use if you were writing managed code.

This layering of APIs, REST and .NET, might seem crazy.  But the point is that everything that goes across the wire is REST.  Microsoft has done this because it’s an open standard and opens up their services to 3rd parties.  It also easily bypasses problems with firewalls.  Finally, they provide an object model on top of the URI goo so that .NET applications can work with managed objects and avoid all of the URI stuff.

Miscellaneous Stuff

Mike also showed how a Silverlight 2 application might make use of ADO.NET Data Services to get its data.  Again, using ADO.NET Data Services gives us a lot of flexibility in how we architect the solution.  In Mike’s case, he had the middle tier (app server) store some data in a local SQL Server and some data up in the cloud using SQL Data Services.

Mike did an excellent job at showing how ADO.NET Data Services fits into the data services landscape at Microsoft.  I’m also glad that he brought the Entity Data Model into his examples, so that we could see where it fits in.

Now I’m just wondering if Mike and his team curse the marketing department every time they have to type “ADO.NET Data Services” rather than “Astoria”.

Don Gillett

In my next session, Don Gillett explained how he wrote one of the first Live Mesh applications.  Jot is a little note-taking application that allows synchronizing simple lists across instances running on a PC, a phone, or as a “Mesh application” running in your web browser.

Mesh is all about data synchronization and Jot demonstrates how this works.  To start with, the following preconditions must all be set up:

• User has created a Live Mesh account  (this is free and comes with a free/default amount of storage)
• Jot has been installed to the PC and the phone
• Jot has been installed in the Mesh desktop as a “Mesh application”

At this point, Jot will be able to take advantage of the Mesh platform to automatically synchronize its lists with all three endpoints.

Here’s one possible scenario:

• John is at home, fires up Jot on his PC and adds “toilet paper” to the “Groceries” list in Jot
• Data is automatically synchronized to the other devices in the Mesh—Jot running on the Mesh desktop and John’s wife’s phone
• John’s wife stops at the grocery store on the way home, fires up Jot on her phone and gets the current grocery list, which now includes toilet paper

Jot is a very simple application, but it demonstrates the basics of how the Mesh platform works.  It’s primary goal is to synchronize data across multiple devices.

Out of the box, you can synchronize data without creating or running Mesh applications.  You just create a data folder up on the Mesh desktop and then set it up to synchronize on the desired devices.  Changes made to files in the corresponding folders on any of the devices will be automatically pushed out to the other devices, as well as to the folder on the Mesh desktop.

In this out-of-the-box data synch scenario, because the data lives in the Mesh desktop, this supports two main things:

• Data is always being backed up “to the cloud” because it’s stored in the Mesh
• You can access the data from any public web access point by simply going to the Mesh web site

Writing Your Own Mesh-Enabled Application

Applications written to support Mesh can take advantage of this cross-device synchronization, but only for users who have signed up for a Live Mesh account.

Because this technology is useful only for users who are using Mesh, it remains to be seen how widespread it will be.  If Live Services and Live Mesh aren’t widely adopted, the ecosystem for Mesh applications will be equally limited.

But if do you write an application targeted at Mesh users, the API for subscribing to and publishing Mesh data is very easy to use.  It is simply another .NET namespace that you can get at.  And if you’re writing non-.NET applications, all of the same functionality is available through HTTP, using a REST interface.

What Types of Data Can You Synchronize?

It’s important to remember the Mesh applications aren’t just limited to accessing shared files in shared folders.  Every Mesh application can basically be thought of as a custom data provider and data consumer.  This means two things:

• It can serve data up to the mesh in any format desired (not just files)
• That format is understood by the same app running on other devices

As an example, your Mesh application might serve up metadata about files, the files themselves, and combine it with other data local to that device.

The Data Model

Don talked about the underlying data model that your application uses when publishing or consuming data.  It looks something like this:

Mesh Objects

Data Feeds

Data Entries — optionally pointing to Enclosures

Mesh Objects are the top-level shareable units that your Mesh application traffics in.  They can contain one or more Data Feeds.  If they are too large, synchronization will be too costly, because they will change too often.  If they are too small, or fine-grained, users may get shared data that is incomplete.  What’s important is that a Mesh application gets to decide what data units it wants to serve up to the mesh.

Data Feeds represent a collection of data.

Data Entries are the individual chunks of data within a Data Feed.  Each is uniquely identified.  These are the smallest logical storage units and the chunks that will be synchronized using the underlying synchronization technology.

Enclosures are used when your data grows too large to store directly in an text-based feed.  They are owned by and pointed to by an associated Data Entry.  Media files are an example of data that would be stored in an Enclosure, rather in the Data Entry itself.

The Evolution of a Meshified Application

Don presented a nice plan for how you might start with a simple application and then work towards making it a fully Mesh-aware application:

1. Persist (read/write) data to a local file
2. Read/write data from/to a local DataFeed object
3. Utilize FeedSync to read/write your data from/to the Mesh “cloud”

Don then walked through an example, building a tiny application that would synch up a list of simple “checklist” objects, containing just a string and an IsChecked Boolean.

Final Thoughts

Don mentioned additional Live Services APIs that your application can take advantage of, in addition to data synchronization:

• Live ID
• Authentication
• Contact lists
• News Feeds  (who is changing what in Mesh)

He also mentioned a couple of tools that are very useful when writing/debugging Mesh applications:

• Resource Model Browser  (available in the Live Framework SDK)
• Fiddler 2, third-party web traffic logger, from fiddlertool.com

Don Box, Chris Anderson

Don and Chris’ presentation was notable in that they did not use a single Powerpoint slide.  The entire presentation consisted of Don and Chris writing code in Visual Studio.

This will be a short post because Don and Chris went so fast and covered so much stuff that I didn’t make any attempt to take notes on specific techniques.

Their basic demo was to build a simple Azure (cloud-based) service that served up a list of processes running on the server.  They started by writing this service as a “classic” local WCF service, then publishing it on the ServiceBus, to make it available on the cloud.  And finally, they deployed the service into the cloud so that it was being hosted by the Azure servers.

The most important takeaway from this talk was that the service that they wrote was at every point accessible through standards-based protocols.  Azure-based services are accessible through a simple “REST-ful” interface.  The idea of REST is to use the existing GET/PUT/POST/DELETE verbs in HTTP to execute corresponding Read/Update/Create/Delete data operations on the server side.

This session was the hardest to keep up with, mentally, but also the most fun.  Don and Chris traded off talking and coding.  Both were equally quick at talking through explanations of what they’d do next, in moving from a local service to a service published up in the Azure cloud.  And both were equally quick to write the corresponding code in Visual Studio.  They probably used fewer code snippets than any of the other presenters so far at PDC.

All in all, an excellent session, though it did make my head spin.

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)

Media

• 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

Devices

• 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

Gadgets

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

Miscellaneous

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

Decrease

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

Increase

• 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.

Tesco.com Demo of Rich WPF Client Application

Here we got our obligatory partner demo, as a guy from Tesco.com 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.