Luckily .Net 4.0 / Silverlight 4.0 / C# 4.0 comes with the Dynamic Language Runtime (DLR).  I had previous used the new dynamic pseudo-type that ties into the DLR to call Iron Python.  I figured I would see if I could use this same technique to call into COM. Back in ancient times (circa 1990s) I called into COM all the time from VB and ASP. I knew the libraries were all there to do what I needed to do.

I was not surprised to find I wasn’t the first person down this path, and quickly encountered multiple articles and postings about working with the file system via COM this exact way.  With the knowledge that it was possible I plowed forward.

To access COM from Silverlight one uses the AutomationFactory to instantiate a COM library.  I wanted to use the good ol’ Scripting.FileSystemObject.  In my test case I had a Silverlight app running locally OOB with elevated privileges.  This Silverlight app has a single list box which will display the drive letters once I can get access.  Via COM, the code looks like this:

dynamic fs = AutomationFactory.CreateObject("Scripting.FileSystemObject");

foreach (dynamic drive in fs.Drives)
{
  filesListBox.Items.Add(drive.DriveLetter);
}

Its really that simple. The dynamic keyword and COM do all the heavy lifting. The most work I had to do was lookup the object model to use in the FSO, as no intellisense is available. The runtime does late binding onto these properties via the DLR. This did a nice end-route around the missing Silverlight IO libraries and provided me with a nice list of drives.

C# will be gaining some new language functionality with the .Net 4.0 release.  C# now supports option parameters, named parameters and default parameter values to assist with those situations where overloads are cumbersome.  C# 4.0 also supports a type of covariance and contravariance for collections.

The .Net 4.0 framework was delayed because of performance issues.  I am glad they waited to get it right.

Silverlight 4.0 is scheduled to be released later this week.  ASP.Net MVC 2.0 was released a couple of weeks ago, which takes advantages of a couple of new .Net 4.0 scenarios.

In Silverlight, one can write code to handle any unhandled exception in the application.  This type of functionality exists in Winforms, WPF and ASP.Net, so I wasn’t terrible surprised to find it available.  This is incredibly convenient.  I can attack areas likely to cause exceptions such as web service calls with specific logging and exception handling code, and catch everything else with a few lines of general-purpose logging.

As soon as I implemented this catch all I immediately started getting log messages stating:

No XAML was found at the location ”.

at System.Windows.Navigation.PageResourceContentLoader.EndLoad(IAsyncResult asyncResult)

at System.Windows.Navigation.NavigationService.ContentLoader_BeginLoad_Callback(IAsyncResult result)

at System.Windows.Navigation.PageResourceContentLoader.BeginLoad_OnUIThread(AsyncCallback userCallback, PageResourceContentLoaderAsyncResult result)

at System.Windows.Navigation.PageResourceContentLoader.<>c__DisplayClass4.<BeginLoad>b__0(Object args)

Well, that was really helpful.  And after some Google searches I soon realized that I wasn’t going to find a solution on the web.  Well, I guess this is why I actually get paid to program.  After some testing I discovered that the only time I saw this error (and it was just logging, it never bubbled up to the UI) it was when leaving the Silverlight app for another page in our web application.

Our app takes advantage of Silverlight’s Frame + Page navigation handling, which can map one URI to another.  In practice this is basically REST.  When the frame “hears” a new URI entered it converts the URI  to an internal, component-based URI with the location of the Silverlight page to display.  These mappings are configured during our bootstrap process which rides on top of Prism.

As it turns out, when the user (me) clicks on a link to leave the Silverlight app, the frame “hears” a new URI.  The browser is navigating, and the frame tries to handle it.  But it doesn’t have a mapping for the URI, which is curiously an empty string no matter where outside the Silverlight app one is navigating.  The frame barf, and produces the above exception.  But no one sees it because the app is closed within a split second of all this happening.

After poking and prodding with various ways of squashing this, I finally figured out that in the Navigating event of the Frame I can just set e.Cancel = true, which tells the frame to not navigate.  My conditional logic simply checks to see if the URI is empty.  The browser continues on with its business, and the Silverlight app ignores the navigation from that point on.

Hopefully this entry helps someone else doing REST in Silverlight.

The editor allows one to highlight existing code and export it into a snippet file.  This is a great launch pad for snippet development.  The editor runs in Visual Studio, and once a snippet is saved with a shortcut it is immediately available in the IDE.  The editor also allows the editing of existing snippet files.

ExpandoObject allows for addition of member properties and methods are run-time similar to popular scripting languages like Javascript.  Yet ExpandoObject is a real .Net type, and implements a couple of  interesting .Net interfaces: IDictionary<string, object> and INotifyPropertyChanged.  A dictionary of members is provides through the dictionary interface, and property changed events are fired through the property changed interface.  The only way to really leverage the power of ExpandoObject is with the dynamic keyword/type, which skips compile-time checking.  Method and property calls are not shown in intellisense.  You don’t know if your code will execute property until run-time.  So to access the above mentioned interfaces, the ExpandoObject’s dynamic reference must be cast to the interface type.

Here is some very simple, sample code that illustrates the concepts discussed (runs in Visual Studio 2010 / .Net 4.0 Beta 2):

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Dynamic;

namespace DynamcMethodExample
{
    class Program
    {
        static void Main(string[] args)
        {
            dynamic person = new ExpandoObject();
            person.Name = "John";
            person.Gender = 'm';
            person.Age = 10;

            Console.WriteLine(person);
            Console.WriteLine(person.Name);
            Console.WriteLine(person.Gender);
            Console.WriteLine(person.Age);
            Console.ReadKey();

            person.MakeTacos = (Func<string>)(() => "Tacos are ready!");
            Console.WriteLine(person.MakeTacos());
            Console.ReadKey();

            ((INotifyPropertyChanged)person).PropertyChanged += (s, e) =>
                {
                    IDictionary<string, object> personAsDictionary = (IDictionary<string, object>)person;
                    Console.WriteLine("Property {0} changed to {1}.", e.PropertyName, personAsDictionary[e.PropertyName]);
                };

            person.Name = "Jane";
            person.Gender = 'f';
            person.Age = 11;
            Console.ReadKey();

        }
    }
}

• Enum.HasFlag(Enum enum)
  I have written this code a couple of times before.  It detects whether a bit is set in an enum Flag value.
• Enum.TryParse<EnumType>(string value, out EnumType result)
  I have also had to write this.  I think every core value-type should have a TryParse, which leads to:
• Guid.TryParse(string value, out Guid result)
• String.Join and String.Concat now take IEnumerable<T>!  I have written string.Join(“,”, values.Select(v=>v.ToString()).ToArray()) more that a few times.

I am really looking forward to .Net 4.0.  If you want to get your hands on it now .Net 4.0 and Visual Studio 2010 are available for download here.

At my current employer I have found myself working with a very mature (and very good) code-base that does not lend itself to unit testing.  It has probably been a year since I have written a unit test at work.  So when I started diving back into Silverlight I made it a goal to write our new framework to be as compatible with unit testing as possible.  This will help lesson the burden on our QA team, which has already written a lot of UI testing for our current ASP.Net web application.  We will also receive all the benefits mentioned above.

To start off I needed a unit testing framework.  NUnit is my old unit-testing friend and was my first thought.  However, NUnit and other unit testing frameworks don’t work in Silverlight-land, since Silverlight relies on a slightly different set of core .Net assemblies.  I did discover that there is a Silverlight version of NUnit and I considered it.  I also found the Silverlight Unit Testing Framework from Microsoft thanks to a post over on Scott Gu’s website.  The Silverlight Unit Testing Framework is based on the Microsoft library for normal .Net (which is also based on NUnit) but runs in Silverlight, in the browser.

Ultimately I chose the Microsoft library for a couple of important reasons.  First, there seems to be more acceptance and more example of the Microsoft library.  Second, the Silverlight Unit Testing Framework does one thing that is very unique compared to other unit testing frameworks: it runs the tests in the UI thread.  Jeff Wilcox, one of the authors of the framework, has an excellent post here about why Microsoft chose to do this, and it really makes sense.  Silverlight is a graphical library, and bugs will best be found if testing is written from a user-interaction standpoint.  Many things run on the UI thread, or are marshaled back and forth.  The Microsoft Silverlight Unit Testing Framework can work both as a unit testing framework and as a kind of integration testing framework.  The framework makes it very easy to test off the UI thread, and test asynchronously.  I found this excellent post on using the async features of the Silverlight Unit Testing Framework.  It really boils down to the testing environment being the same as the real run-time.  I have run across enough idiosyncrasies in the way Silverlight handles UI thread interaction to know that testing without it will miss a lot of bugs.

I have developed some “test” tests on business objects.  I also tested a thread manager I wrote using the built-in async functionality.  With the experience so far, I feel happy with the results.  My next step is to look at pluging in the unit tests into the automated build at work…