MSDN Unleashed Silverlight 3 Content

You can download the Silverlight 3 and RIA Services tools here but be aware that they cannot be installed along with Silverlight 2 tools! If you do not have a separate test environment to install into you can still install Blend 3 (which now includes a code editor) next to your existing Silverlight 2 environment to work with SL 3 projects.

Completed demo code:


Thanks to Rob Bagby, who created the demo application. He has the Coho Winery database used for the application available from his blog. Look for the link on the lower right.

Be sure to check out Brad Abrams’ original session from MIX.

Initial Thoughts on Blend 3 MIX Preview

After trying out the new features in Blend 3 I’m definitely looking forward to the full release. It already seems to be more responsive than Blend 2 SP1 while navigating around files, templates, selected elements, etc, even at this pre-Beta stage. I was disappointed to see SketchFlow missing from the Preview, but look forward to it being included when it’s stable enough.

There are a bunch of nice UI tweaks:

  • Tool Panels now allow pinning (like in VS) to autohide. Data and Objects and Timeline are also now their own panels so they can move around freely. The left side tool strip now floats and docks too.
  • The Active Container is no longer a static setting. It’s still possible to set it to a fixed object, but now it must be done from the right click menu (Pin Active Container) instead of double clicking. I was annoyed by this at first and wondering why there was no yellow selection border, but then realized that Blend was inferring a container based on what I was doing. Double clicking to add an element now uses the current selection as the container to add to, or its parent if it doesn’t support children. A blue border takes the place of the yellow indicator in these cases.

Even better, when adding by dragging directly on the design surface, the container is inferred graphically and switches (with blue border) as you move the cursor around.

  • Like the active container setting, elements are similarly highlighted with a blue border as you mouse around with the selection arrow tool, making it easy to find elements. This includes elements that are buried in layers of panels, and selecting an element is as easy as clicking on it when it’s highlighted, virtually eliminating the need for using the right click “Set Current Selection” menu item (although it is still available). I haven’t had to use it yet once.
  • Design-time sizing is available on more root container than before, including both Control and Data Templates. Rather than being set on the template itself the size is set on the first element in the tree.

  • The old Gradient tool that was pretty much only useful for rotating gradients now allows direct setting of stops on the design surface. Each one is shown as a circle and can be dragged to a different spot or edited in place (with popup color picker) by double clicking. Alt-clicking adds new stops and dragging a stop out of the gradient area removes it. The Properties panel brush editor itself has also added the ability to set a gradient stop position as a numeric percentage (great for translating from Illustrator) and reverse the order of gradient stops.

  • Annotations allow for design notes to be added directly to the UI that only show up in Blend (think comments for designers). I tried adding some in a real WPF project and the attached properties they created didn’t seem to have any effect on VS or Blend 2. I haven’t figured out where the AnnotationManager class lives so I’m hesitant to leave notes on files that other people need to edit without Blend 3 but at least they didn’t cause any immediate backward compatibility issues on my own box.
  • New keyboard shortcuts abound. Look around the menus to find them – the help hasn’t been updated yet.

My favorite part of the new version is design time data – something I’ve been doing awkward workarounds for since I started using Blend. There are lots of options, but my favorite so far is the generated sample data source. I first tried importing an XML file, which gave me a full set of data and showed all the available fields, including nested collections. I then set up another data source from scratch, using only the Blend UI to define the data structure:

Anywhere there’s a “+” a simple, complex or collection property can be added. Simple properties can be set as String, Number, Image, or Boolean types, with further options for each. String properties can be set to things like Names, Dates or Phone numbers to provide realistic looking data. Images of chairs are provided out of the box but can be replaced by pointing to a folder of image files of your choice.

All of this results in a generated class that includes a bunch of dummy data and is declared as a resource in location of your choice. Any element from the data source can then be dragged onto the design surface to set up a binding or generate a bound control. I haven’t quite gotten the hang of predictably hooking up data by dragging but through a combination of dragging elements and using Blend’s data binding window (which consistently displayed my test data structure through the Data Context tab) I managed to quickly set up a complete multi-level master detail UI for the structure I set up without jumping into XAML at all. An option allows you to switch between using the data only at design time (d:DataContext) or at design and run-time (DataContext) – this should be good for initial testing of a UI.

Through a few hours of working on a live WPF project I haven’t had any problems using the new version and hopping back and forth to VS. I even tried opening in Blend 2, 3, and VS and making changed in all 3 with no problems. I haven’t done much more than start up a new Silverlight 3 project but that worked fine too and the Preview install doesn’t appear to have negatively impacted my existing Silverlight 2 dev environment.

Get the preview here

and if you’re using TFS look at for the hotfix needed to hook up the Preview’s source control integration.

Presentation Materials for Code Camp

Thanks to everyone for coming!

Intro to Blend for Developers : Slides

Leveraging Blend in the XAML Application Development ProcessSample Code also a more complete implementation of M-V-VM (we didn’t look at this in the session)

More samples are available in other posts here and also at my old blog.

Presentation Materials for TechDays ’08

Sample Applications:



Toolbar application only | Toolbar code


Demo Code:

When first opening the code there will be a warning due to a custom build step generated by Blend related to font embedding. Select the option to load normally.

Some things to look for in the demo application:

  • Built-in and Toolkit controls
  • OpenFileDialog (FileAccessPage.xaml)
  • Methods of accessing servers (NetworkingPage.xaml)
    • REST Service
    • RSS
    • Web Service
    • WCF Service
    • WCF Duplex
  • HTML DOM Interop using the HTML Bridge (HtmlInteropPage.xaml and Default.aspx)
  • Cross-domain server access (clientaccesspolicy.xml in WcfSilverlightServices)
  • Custom splash page (Splash.xaml in SilverlightConcepts.Web)
  • Font Embedding (HtmlInteropPage.xaml, look at the ListBox ItemTemplate’s TextBlock Font settings in Blend)
  • Basic data binding (ControlsPage.xaml, HtmlInteropPage.xaml, NetworkingPage.xaml)

Resource links:

Silverlight Toolkit

L.A. Code Camp October 2008 Presentation Materials

Shrinking your Code-behind with WPF Data Binding


Demo code including both WPF and Silverlight versions:

To switch between the two WPF UIs look in App.xaml for the commented out StartupURI. The sample data includes resumes but not images. If you want to try out your own images they should be added to the SampleData/Images folder and referenced in SampleData/ApplicationData.xml in place of the current 01.jpg reference.

More information on the change notification memory leak that we discussed:

Dynamic UI Layout in XAML


Demo code for layout concepts:

Demo application code for WPF and Silverlight: (see notes above)

Also check out my other blog posts here and at my old blog for other examples related to both topics. Thanks for coming!

Setting Up Test Data for Blend

One of the big challenges in using Blend to set up an application that relies heavily on dynamic data is that without realistic data available at design-time, what you see isn’t what you get at run-time. Blend includes some basic built in data generation that can be useful for simple data structures but this won’t really help much if you have conditional layout that is expecting specific values.

If all you need is a generic set of data to fill out an ItemsControl you can use Blend to generate design-time data for itself. Select the control to generate data for and open the data binding dialog for the ItemsSource property (either directly or through the “Bind ItemsSource to Data…” context menu option). Locate the collection to bind to and click the “Define Data Template” button at the bottom. This dialog can set up a basic data template (that will probably need some tweaking later) and more importantly includes the “Generate sample data” checkbox at the bottom. Selecting this adds a new d:UseSampleData=”True” setting on the ItemsControl (along with the d and mc xmlns’s used by Blend) which signals Blend to create data for the types of the items in the bound collection. Unfortunately, the values generated are pretty limited. Strings are fruits, ints are small values, and enums are chosen at random (in the latest 2.0 SP1 version; earlier versions didn’t do enums).

When the built in generation isn’t enough test data can be made available in a number of ways but there are some challenges to getting it to show up. In most cases the key to getting Blend specific data relies in some way on a check of the DesignerProperties.IsInDesignMode Attached Property. This value is false at run-time and true at design-time in Blend. It can be checked with a call to DesignerProperties.GetIsInDesignMode, passing a DependencyObject instance or statically with the more verbose (bool)DependencyPropertyDescriptor.FromProperty(DesignerProperties.IsInDesignModeProperty, typeof(DependencyObject)).Metadata.DefaultValue.

Since Blend skips the constructor and many initialization event handlers declared in the code-behind of the view being loaded, anything that is hooked up in those methods will not be called in Blend. This can make it tricky to even get to code that can check IsInDesignMode and generate your data. To ensure code gets called it needs to somehow be referenced from XAML. A few ways to do this:

  • A property assignment of a new object with generation code in the constructor

    <local:ViewModel />

  • A Binding to a property that includes generation code

DataContext=”{Binding RelativeSource={RelativeSource Self}, Path=ViewModel}”

  • An assignment to a custom attached property that includes generation code in its set method

For any of these methods you should either use an IsInDesignMode check or make sure that everything being run will work at both Blend design-time and run-time. See my post on debugging Blend errors for more on Blend unsafe code. The simplest way to actually get the test data from your code to Blend is by assigning it to a DataContext property of some element (as in the examples above). If you plan ahead you should be able to get both your run-time and design-time data through the same DataContext properties which will keep your Binding behaviors consistent.

Sharing Assemblies Between Silverlight and WPF

One of the significant benefits of Silverlight is the ability to share code with WPF desktop applications. Unfortunately, in practice there are quite a few hurdles to sharing code, due mainly to the restricted set of classes available in Silverlight’s framework.

One consequence of the way Silverlight is built is that class library projects can only be referenced if they are created specifically as Silverlight projects, and Silverlight class libraries can’t be used by standard .NET projects. The standard workaround for this is to create 2 projects, one Silverlight, the other standard .NET, and share all of the code files by either keeping the projects in a shared folder or by adding them as links to one of the assemblies. This is ok but creates a dual-maintenance headache and also requires that all “shared” projects are actually compiled twice into separate assemblies that must each be managed.

Fortunately, the restrictions on referencing projects are primarily a mechanism in Visual Studio and if you’re careful it’s actually possible to trick it into using a single project that can be referenced by Silverlight or full .NET applications. If you can keep to basic parts of the BCL that are available everywhere you can even compile to a single assembly that will work in both environments!

I’m still working out how to get this completely set up in a practical application but I’ll post more when I do.

Silverlight 2 and DHTML

The purpose of Silverlight 2 in demo applications has so far primarily been to provide enhanced graphics to self contained applications. While the graphics capabilities are attention-grabbing, some of the other powerful features that are available seem to get overlooked. For example, Silverlight has the ability to interact with the HTML DOM and Javascript which allows you to use it to enhance existing web applications. To try out some of these features, I took a basic data entry form (in this case just plain HTML that’s not actually hooked up to anything on the server) and added a toolbar that gives the user some editing features to help fill out the form.


The toolbar provides

  • Unlimited Undo/Redo
  • Clearing of all form data
  • Saving multiple sets of the entire contents of the form locally on the client
  • Reloading of any set of data that is saved on the client

The only javascript that is required for this functionality is some boilerplate to connect to the Silverlight C# code.

For the toolbar I used the DHTML-Silverlight connections in both directions. The DataCache class in the application is decorated with the ScriptableType attribute and has methods decorated with the ScriptableMember attribute. This is the first step in making code available to javascript. The next is to call HtmlPage.RegisterScriptableObject(“objectName”, theScriptableObjectInstance) from the Silverlight UserControl’s code-behind. A good place to do this is in a handler for the Loaded event. These methods are now available to call from javascript by getting a reference to the Silverlight application like this:

var agEControl = document.getElementById(“SilverlightElementId”);
var content = agEControl.content;
var scriptableObject = content.objectName;

Here objectName is the string used above to register the object and “SilverlightElementId” is the HTML id of your Silverlight control (“Xaml1” by default in a VS generated project). Once you have scriptableObject you can just call any method on it just as you would in C#.

In the scriptable methods I use the connection in the other direction to go back to the calling HTML and retrieve values from the page’s controls. This basically takes one step to get the current value of an element:

HtmlElement element = HtmlPage.Document.GetElementById(“controlId”);
string value = element.GetAttribute(“value”);

It looks just like what you would do in javascript with the exception of the HtmlElement and HtmlPage classes that provide the access to the DOM. HtmlElement allows you to do all sorts of manipulation including attaching event handlers and playing with the structure of elements on the page.

Another interesting thing I ran into when I decided to blog this is the simplicity of deployment with the current structure of a Silverlight application. If you’re working in Visual Studio your application is compiled into a single file with a .xap extension. You probably also have a web project of some type to host the application. When running your application the built-in web server is spun up to serve up the page to the browser.

If you happen to be using a plain HTML host and not using server-side code you can also open the .htm directly in your browser as a file. This gave me the idea to try xcopy deploying my app to my blog’s downloads folder, which is just a basic file share. Starting out with a minimum set of files I copied the .htm and .js files that make up my page (no generated files) and the .xap file in ClientBin. This didn’t work at first due I think to extension filtering that disallowed the browser from pulling down the xap file. Fortunately zip files are allowed to download and (big secret) xap files are actually just zip files containing your assemblies and a manifest. If you rename your xap to zip you can just open it up and see your dlls inside. Once I did this and adjusted the reference in the HTML accordingly the entire page with toolbar loaded in my browser over http from a simple file share! Compare this to what you need to stand up a simple AJAX application and you can see the advantage.

Download the sample code HERE. Try out the functional page HERE. You’ll need the Silverlight 2 Beta 1 runtime (it should ask to install itself). Sets of data are saved by Last Name and ID so you may notice the Save button being enabled/disabled as you change fields. The Load and Delete buttons will become enabled after you save a form. The set selector is kind of clunky because there’s no ComboBox control yet in Beta 1 so I just squeezed in a small ListBox instead.

**UPDATE** – Silverlight 2 Beta 2 was just released and I’ve updated the functional version and put it alongside the original HERE. **

First Silverlight 1.1 App

After all the MIX announcements and releases I started playing with the Silverlight 1.1 Alpha. For my first app I was inspired by the MS Chess demo to make a TicTacToe game. I decided not to make a computer player since the point was really just to work with Silverlight. After working on full WPF going to the 1.1 Alpha sort of feels like going from Visual Studio to NotePad. There are very few controls at this point and even the classes that are available are often missing methods and properties. Brushes, for example, doesn’t exist yet and Colors only has a few basic named colors (hence the crazy color palette in my first app). Having said that, the stuff that is there really is a good foundation to start on and seems to be working great. Even though this stuff is only Alpha I haven’t had the tools or the browser plugin crash yet. 

I’m still working on setting up stable hosting for my first app so I can embed it here but at this point it’s just running on my dev box. There are instructions in the SDK docs for setting up IIS to host Silverlight which are also posted here. For now here are some screenshots: 

TicTacToe1 TicTacToe2 

If you just want to run a Silverlight app locally you don’t need any IIS configuration. Running from file://… pointed at the html file works just the same but without any extra configuration. The code for my app is here. To run it you need to have Silverlight 1.1 Alpha installed. Extract the folder somewhere, open up TestPage.html and it should start right up (I can’t be held accountable if it doesn’t – it’s only Alpha!). To actually edit the project you will additionally need Orcas Beta 1 and the Silverlight Tools Alpha for Orcas Beta 1. It can also be opened in Blend 2 May Preview. Download links for everything are at

So what’s actually going on when you open up TestPage.html? I’m still digging into the mechanics of it but basically there’s a div tag in the html page which is populated by Javascript. In Javascript a Silverlight object is created by referencing the Page.xaml file. Page.xaml in turn points at the dll compiled from the .cs code behind. Once all this stuff gets to the browser, the Silverlight CLR has everything it needs to start running just like a normal .NET app and off you go.