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!

Yes, I know the party line on WPF development runs something like this:

• Every dev team should have at least 1 developer and 1 designer
• Developers can’t design decent-looking GUIs to save their soul
• Designers can’t be trusted with code, or anything close to code (excepting XAML)
• Devs will open a project in Visual Studio and do all of their work there
• Designers will open the same project in Blend and do all of their work there
• Devs wear button-up shirts that don’t match their Dockers
• Designers wear brand-name labels and artsy little berets

I don’t quite buy into the idea of a simple developer/designer separation, with one tool for each of them.  (I also don’t wear Dockers).

It’s absolutely true that Blend makes it easier for a designer to be part of the team and work directly on the product.  The old model was to have the designers do static mockups in Photoshop and then have your devs painstakingly reproduce the images, working in Visual Studio.  The old model sucks.

The new model, having Blend work directly with XAML and even open the same solution file as Visual Studio, is a huge advancement.  Designers get access to all of the flashy photoshoppy features in Blend, which means that they can do their magic and create something that actually looks great.  And devs will instantly get the new GUI layout when they use Visual Studio to open/run the project.

The problem that I have with the designer/developer divide is as follows.  To achieve an excellent user experience takes more than just independently creating form and function and then marrying the two together.  A designer might create GUI screens that are the most beautiful thing on the planet.  And the dev working with him might write the most efficient and elegant code-behind imaginable.  But this isn’t nearly enough to guarantee a great user experience.

User experience is all about user interaction.  Poorly done user interaction will lead to a failed or unused application far more quickly than either an ugly GUI or poorly performing code.

So what exactly is “user interaction”?  In my opinion, it’s everything in the application except for the code and the GUI.  User interaction is all about how the user uses your application to get her work done (or to create what she wants to create).  Does the application make sense to her?  Does using it feel natural?  Allow her to be efficient?  Are features discoverable?  Does the flow of the application match her existing workflow?

The only way to get user interaction correct is to know your user.  This means truly understanding the problem that your users are trying to solve, as well as what knowledge they have about the problem space.

There is an easy four step process to get at this information: 1) talk to the users; 2) prototype; 3) observe them using the prototype; 4) repeat.

There are a whole host of specific strategies to help you in this process, including things like: use cases, user stories, storyboarding, etc.  The literature is full of good processes and techniques for working early and often with users to get both the right set of functionality and a great user experience.

But let’s get back to designers and developers.  The reason that I don’t buy into the clean GUI/code split (or code + markup, if you’re a Petzold fan) is that good user interaction requires both code and markup.  Somebody needs to be responsible for the user interaction model and it should come first, requiring some code and some markup.

If you do buy into the devs-Studio/designers-Blend party line for WPF development, there are two simplistic approaches that you might be tempted to take, both equally bad:

• Developer codes up all required functionality, puts API on it and designer creates screens that call into the API
• Designer mocks up screens and then developers create code behind those screens to get desired functionality

The problem behind both approaches is, of course, that no one is focused on how the user is using the application.  The designer is thinking about the user in aesthetic terms and that’s a huge improvement over a battleship grey GUI.  But it’s not nearly enough–not if your goal is to achieve a great user experience.

If someone needs to be responsible for the user experience, it should be the developer.  If you are lucky enough to be working with a designer, the developer is still the team member that drives the entire process.  The designer is likely working in support of the developer, not the other way around.  (Note: I’m talking here about developing rich WPF client software, rather than web-based sites or applications.  With web-based projects, it’s likely the designer that is driving the project).

My vote is for a process that looks something like the following:

• Developer initiates requirements gathering through user stories and use cases
• Developer starts sketching up storyboards, with input from designer
• Developer builds prototype, using both Visual Studio and Blend
• Team presents prototype to user, walks through use cases, gets feedback, iterates
  • Important to focus here on how the user works w/application, rather than how it looks
• As pieces of user interaction solidify
  • Designer begins refining those pieces of GUI for aesthetics, branding, etc.
  • Developer begins fleshing out code behind and full functionality
• Continue iterating/reviewing with user

You might agree with this process, but say that the developer should work exclusively in Visual Studio to generate the prototypes.  Why is it important for them to use Blend for prototyping and iterating with the user?

The simple truth is that Blend is far superior to Visual Studio for doing basic GUI layout.  Using Visual Studio, you can definitely set property values using the property grid or by entering XAML directly.  But the property editors in Blend make it much easier to quickly set properties and tweak controls.

Given that the developer should be doing the GUI prototyping, I think it makes sense for them to use both Blend and Visual Studio, rather than just Visual Studio alone.

The bottom line is this: the choice of using Blend vs. Visual Studio should be based on the task that you are doing, rather than who is doing that task.  Instead of Blend just being a tool for designers and Visual Studio a tool for developers, it’s more true that Blend is a tool for doing GUI design and Visual Studio a tool for writing/debugging code.  Given that I think the developer should be the person responsible for early prototyping of the GUI, they should be using both Blend and Visual Studio during the early phases of a project.

So if you’re a developer just getting into WPF, don’t write off Blend as an artsy-fartsy tool for designers.  Instead, just think of it as a GUI design tool.  Though you may not be great at putting together beautiful user interfaces, it’s definitely your job to create the early GUI prototypes.  You may not be responsible for the design of the GUI, but you should be responsible for designing the GUI.  So if you WPF, you really ought to Blend.  Who knows?  You might like it so much that you start wearing a beret.