public class HealthVaultException : Exception
{
    public HealthVaultException(int errorCode, string errorText)
    : base(errorText)
    {
        this.ErrorCode = errorCode;
    }

    public int ErrorCode { get; set; }
}

Next, is the HealthVaultOperation class. The pattern with this class is that DoOperations yields one of these with the information about the HealthVaultRequest, and when control returns after the yield, the response data will be filled out. It also has a helper function to throw a HealthVaultException in the case of an error. But, it’s up to the DoOperations implementation to call ThrowOnError.

public class HealthVaultOperation
{
    public HealthVaultOperation(string methodName, string methodVersion, XElement info)
    {
        this.MethodName = methodName;
        this.MethodVersion = methodVersion;
        this.Info = info;
    }

    public string MethodName { get; private set; }
    public string MethodVersion { get; private set; }
    public XElement Info { get; private set; }

    public HealthVaultResponseEventArgs Response { get; set; }

    public void ThrowOnError()
    {
        if (this.Response.HasError)
        {
            throw new HealthVaultException(this.Response.ErrorCode, this.Response.ErrorText);
        }
    }
}

Finally, here is the HealthVaultTask class. The only really interesting code is in RunEnumerator, which enumerates through the HealthVaultOperations returned by DoOperation, creating a HealthVaultRequest for it and executing it. At first glance, this function may look recursive, but the other RunEnumerator call is actually in a lamda function that will be called from the request callback. It also has the code to marshal the result (in case of success or failure) to the right callback function on the UI thread.

public abstract class HealthVaultTask
{
    public HealthVaultTask(HealthVaultService service)
    {
        this.Service = service;
    }

    public void Run(Dispatcher dispatcher, Action successCallback, Action<Exception> errorCallback)
    {
        RunEnumerator(dispatcher, successCallback, errorCallback, DoOperations().GetEnumerator());
    }

    private void RunEnumerator(Dispatcher dispatcher, Action successCallback, Action<Exception> errorCallback,
                               IEnumerator<HealthVaultOperation> operations)
    {
        try
        {
            if (operations.MoveNext())
            {
                HealthVaultOperation operation = operations.Current;
                HealthVaultRequest request = new HealthVaultRequest(operation.MethodName, operation.MethodVersion,
                                                     operation.Info, (o, e) =>
                    {
                        operation.Response = e;
                        RunEnumerator(dispatcher, successCallback, errorCallback, operations);
                    });
                this.Service.BeginSendRequest(request);
            }
            else
            {
                dispatcher.BeginInvoke(() => successCallback());
            }
        }
        catch (Exception e)
        {
            dispatcher.BeginInvoke(() => errorCallback(e));
        }
    }

    protected abstract IEnumerable<HealthVaultOperation> DoOperations();

    protected HealthVaultService Service { get; private set; }
}

If this doesn’t make sense, please let me know and I’ll explain further.

There’s one design consideration I didn’t think about until after I’d implemented it. One problem with this implementation is that you can’t compose HealthVaultTasks with other HealthVaultTasks. It would be nice if you could build up layers of reusable service code. This could be accomplished by having a common base class between HealthVaultTask and HealthVaultOperation where HealthVaultTask.DoOperation would be an IEnumerable of the base class. That would let you yield either operations or tasks. This addition is left as an exercise to the reader

Finally, a note on unit testing. This framework actually makes the HealthVaultTasks you write very easily unit tested. All you have to do is call GetEnumerator on your task, then call MoveNext/Current to simulate running the task. After you call MoveNext, you can make sure you get the expected operation in Current and you can push whatever results you want into the HealthVaultOperation. What’s great is that the HealthVaultService is completely out of the picture.

I hope this is useful!

The HealthVault SDK for Windows Phone 7 provides a HealthVaultRequest class for making calls to HealthVault, calling into a callback when done. Using lambda expressions, you can make fairly readable code for simple calls as follows:

service.BeginSendRequest(new HealthVaultRequest(methodName, methodVersion, xml,
                         (object sender, HealthVaultResponseEventArgs e) =>
{
    dispatcher.BeginInvoke(() =>
    {
        if (e.HasError)
        {
            // Handle error.
        }

        // Parse results.
    });
}));

But, I needed to do some more complex things like do multiple requests in a loop, have branching based on sync state, and so on. This turns into incredibly messy and hard to follow code with callback functions and/or lambdas. A common trick for making asynchronous code read more like synchronous code is to use the yield keyword in C# so that the compiler will build the state machine for you. Jeffrey Richter has a series of articles about using it with the standard async pattern which you can read here. I decided to apply this technique to the HealthVaultService and HealthVaultRequests, which I present here. I hope people will find it useful with HealthVault on Windows Phone 7, or will see how to apply it to similar problems.

My basic approach is to create a HealthVaultTask class, which runs a series of HealthVaultRequests. This is done by implementing an IEnumerable function that returns a series of HealthVaultOperations. HealthVaultOperation is a new class I am using to encapsulate a HealthVaultRequest and response. So, the way you implement a task looks something like:

protected override IEnumerable<HealthVaultOperation> DoOperations()
{
    HealthVaultOperation myOperation = new HealthVaultOperation(methodName, methodVersion, xml);
    yield return myOperation;
    myOperation.ThrowOnError(); // See discussion below.
    // Parse response from myOperation.Response
}

The magic of this pattern is that you can have loops, if branches, etc in DoOperations so that the code in DoOperations looks like serial code. But, under the covers it will all be asynchronous.

There are a couple of design decisions I had to make up front. The first was about how to handle errors. There can be errors returned from the operations, and exceptions could be thrown from DoOperations itself. One approach would be to put an error code in HealthVaultOperationTask and have the caller check for the error. However, I prefer having all errors just be thrown from DoOperations method and wrapped up by the code that runs the task. To make it simple, HealthVaultOperation has a helper function called ThrowOnError() that throws an exception if there is an error returned from the HealthVault service (wrapped in a new HealthVaultException class).

The other design decision was around the threading model and how the results are communicated to the caller. I considered two basic approaches:

1. DoOperations is always called on the UI thread and can update models/UI as necessary.
2. DoOperations is not called on the UI thread, bundles up its results into properties on the task class, and is marshaled to the UI thread when complete.

I opted for #2. It eliminates potentially unnecessary thread context switching and keeps the code that does the network operation separated from any model/UI code. As a result, the signature of the method to run the task is as follows:

public void Run(Dispatcher dispatcher, Action successCallback, Action<Exception> errorCallback)

When the task is run, either the successCallback will be called or the errorCallback will be called. The call will be dispatched to the UI thread. Here’s an example:

MyHealthVaultTaskTask task = new MyHealthVaultTaskTask (service, ...);
task(dispatcher,
() => {
    // pull results off task and update model/UI.
},
(e) => {
    // Handle updating model/UI with exception e.
});

In part 2, I’ll share the code that implements HealthVaultTask.

The trick is to use an appdata: url to refer to your original image. For example, if your standard tile image is called “background.png”, then you can use the following to reset it:

        public static void ResetTile()
        {
            StandardTileData newTileData = new StandardTileData();
            newTileData.BackgroundImage = new Uri("appdata:background.png");

            ShellTile appTile = ShellTile.ActiveTiles.First();
            appTile.Update(newTileData);

        }

Note: If you have changed any other properties like the BackContent, you will want to reset them by setting them to “”. Passing in null will leave the values unchanged.

I wanted to share the workaround I used. It’s pretty ugly, but the basic idea is that after the page loads, it injects some JavaScript to go remove the target on any links with target=”_blank”. For this to work, you need to have IsScriptEnabled=true on the control. And, it’s possible that some pages might block eval or otherwise block this from working. But, it worked in my case.

First, you need to hook up the LoadCompleted event on the web browser control. This fires after a page loads:

        public MyPagel()
        {
            InitializeComponent();

            _webBrowser.LoadCompleted += OnWebBrowserLoadCompleted;
        }

Then, OnWebBrowserLoadCompleted injects JavaScript to fix up the links:

        private void OnWebBrowserLoadCompleted(object sender, NavigationEventArgs e)
        {
            try
            {
                _webBrowser.InvokeScript("eval",
@"
window.FixupAnchors=function()
{
    var elems=document.getElementsByTagName('a');
    for (var i=0;i<elems.length;i++)
    {
        if (elems[i].getAttribute('target')!=null && elems[i].getAttribute('target').indexOf('_blank')==0)
        {
            elems[i].removeAttribute('target');
        }
    }
}");
                _webBrowser.InvokeScript("FixupAnchors");
            }
            catch
            {
                // ignore exceptions.
            }
        }

It’s a bit ugly, and some of my coworkers will give me a hard time for swallowing all exceptions here. But, it is working for me and hopefully someone will find it useful.

I am going to pick up blogging again. It’s been a while! First off, I want to give an update on what I’ve been up to for the last few years since my last post. I was the development lead on SkyDrive from its initial release up through our Wave 4 release about 4 years ago. It was a lot of fun helping SkyDrive grow from a small beta (Windows Live Folders) up to a major service that tightly integrates with several other properties in Microsoft including Office and Windows Phone 7.

As of a year ago, I’ve moved over to be the development manager in the Engineering Platform team in Windows Live. My team is in charge of the infrastructure that runs Windows Live. This includes:

• Our build system including our automated test and builds to keep the team running efficiently.
• Our system for packaging and deploying client builds, including Windows Live Essentials and the new Windows 8 applications.
• The system we use to manage our services (Hotmail, Messenger, SkyDrive, etc) including deployment, monitoring and repair.
• Our analytics system that is used to monitor service health and understand how users are using our clients and services.

There are lots of hard problems in these areas and I’ve been learning a lot over the last year.

I’ve also been doing some Windows Phone development in my free time and recently published my first application (WiFi Scale Tracker). I’m planning to do some blog posts both about Windows Phone development and what we are doing in Windows Live.

I’m sorry I haven’t been posting much lately There are a bunch of topics I want to write about, like ASP.NET MVC, PowerShell and Silverlight!

Helge Klein » Blog Archive » Finally! Font Smoothing Over RDP/ICA on Server 2003

1. Run Disk Cleanup (search from Start menu)

2. Choose “Files from all users on this computer”

3. When it’s done scanning (which can take forever), select the More Options tab

4. Select Cleanup under System Restore and Shadow Copies

This freed over 40 GB for me! I think that what happened is that the Zune software touched all of my media, which created shadow copies of each file, using a bunch of space. Shadow copy space must not show up for utilities like WinDirStat.

There’s a useful article on My Digital Life on how to limit how much space will be used. My was set to unbounded space.

Windows Live SkyDrive Team Blog: Hot new updates to SkyDrive!

Apple - Support - Bootcamp