Cool Things from Mix ‘10!

Even before I do my HIMSS post I felt compelled to talk about the shiny things from Mix 2010.

  • Windows Phone 7 Series Developer Studio – I love the free tools provided to develop for Windows Phone. Love the fact that Silverlight and XNA studio are very thoughtfully and seamlessly working with-in Visual Studio Express. The developer studio is lean and performant, its great to see the tool tips for Pixel widths right in the design surface. I was able to write a simple Health app in about 10 mins, the Phones are not out yet but the


  • Open Data Protocol : Very interesting competition to GData :). OData – is a combination of AtomPub with data-typing and querying conventions. OData is supported out of the box by Windows Azure services, and Netflix launch an API powered by OData – It will be great to learn more about batching and syncing aspects of this protocol (Interestingly Microsoft Sync Platform also launched an asymmetric syncing capability).
  • Data Relay : MySpace which is the largest .NET site open sourced their middle-tier GU – DataRelay has a framework for message passing, transaction management on top of a performant caching system. Apparently it uses The CCR (Concurrency and Coordination Runtime) from Microsoft Robotic Studio :).
  • A very interesting presentation of building your own MVVM framework – I love the use of Continuations and a programming model where the framework takes care of concurrency and events! The presenter is author of Caliburn –
  • Font-ing it out – For a font newbie like me, all i know about Fonts I learnt from Kevin Larsons presentation : 

Twitter hashtag for mix is #mix10 and session recordings are available at

Running HealthVault Apps On Windows Azure

HealthVault SDK 1.0 introduces an interesting capability by which an HealthVault application can read their application certificate from a file. Eric has some details about this on his blog.

I’m going to describe how this capability of reading an application’s certificates from the file store could be used to run HealthVault application on Windows Azure. Here are the steps to get a simple HealthVault application (which I call HelloHV) running on Windows Azure:

  1. Install the Azure SDK and HealthVault SDK. Create your HealthVault application as a Web Role.
  2. Configure and create an HealthVault application using the application manager utility in HealthVault SDK. Make sure you set the Action-Url to http://<yourapp&gt;  using the Application Configuration Center.
  3. Copy the Redirect.aspx & Redirect.cs from HealthVault samples (HelloWorld in HealthVault SDK) in to your application and add reference to HealthVault assemblies (you can find them in C:Program FilesMicrosoft HealthVaultSDKDotNetAssemblies)
  4. Add the HealthVault related config settings to your WebRole’s Web.Config, the easiest way to do this would be copy the relevant key(s) from a sample in HealthVault SDK. Here is an illustration :
      <add key="ApplicationId" value="01e21bd1-cb13-40d6-8f01-596286827d6d"/>
      <add key="ShellUrl" value=""/>
      <add key="HealthServiceUrl" value=""/>
      <!-- when we call the SignOut() method on HealthServicePage, 
           it redirects us to the page below -->
      <!--<add key="NonProductionActionUrlRedirectOverride" value="Redirect.aspx" />-->
      <!-- The redirect page (specified above) uses these keys below to redirect to different
           pages based on the response from the shell -->
      <add key="WCPage_ActionHome" value="default.aspx"/>
      <add key="WCPage_ActionAppAuthSuccess" value="HelloHV.aspx"/>
      <add key="ApplicationCertificateFileName" 

  5. While testing on your local machine uncomment the following line in the Web.Config, this will allow HealthVault to communicate with your local machine. However make sure that this is commented when you publish the application.  Alternatively the following key can also be stored in UserApplicationConfigs.xml, if you maintain one for your development.
    <!--<add key="NonProductionActionUrlRedirectOverride" value="Redirect.aspx" />—->

    Gotacha1: Windows Azure changes the port numbers for your application so its hard to make it work without using the action-url configured for your application in Application Configuration Center.

  6. In your Default HealthVault Page Make sure you read the certificate for your application from a local file (you can also use Azure Storage).

    Gotacha2: HealthVault SDK expects the ApplicationCertificateFileName to be absolute filename, this is impossible to determine for a cloud system like Azure. However we can get the absolute path by changing the value of the key at run-time.

    public partial class HelloHV : HealthServicePage { protected void Page_PreInit(object sender, EventArgs e) { ConfigurationSettings.AppSettings["ApplicationCertificateFileName"] = MapPath(@"~certWildcatApp-01e21bd1-cb13-40d6-8f01-596286827d6d.pfx"); } protected void Page_Load(object sender, EventArgs e) {


  7. Hit Run and see your Hello HealthVault  application in action!!

Now the show time:

Check out a simple (HelloHV application) running on Windows Azure here.


The associated code for this application is shared here.

Remember to switch to SSL and secure your application certificate (using password or Azure Storage) before you consider taking an application running on Windows Azure live as a production HealthVault application.

Security Resources for .NET Web Applications

Web applications have a class of security vulnerabilities, at times much widespread and trivial than the infamous buffer overflow.

.NET Web Application Security
.NET Web Application Security

Here are some interesting Security resources on .NET Web Application:

Please leave a comment if you know of any valuable security resources.

Customizing HealthVault Redirection

The HealthServiceActionPage gives you a very nice mechanism by which you can declaratively define pages handling various HealthVault shell targets. However, folks frequently run in to situation where they need more dynamic way of redirecting and handling shell targets. A simple scenario is if you want to users to come back to the same URL they clicked after being authorized by healthvault shell, e.g. User clicks and returns to instead of going to the default home

Here is a code snippet which illustrates how to extend the HealthServiceActionPage:

using System;
public partial class Redirect : Microsoft.Health.Web.HealthServiceActionPage
    //We don't want this page to require log on because when we sign out,
    //we still want this page to read the WCPage_ActionSignOut key in the
    protected override bool LogOnRequired
            return false;

    public const String ActionQueryStringValue = "actionqs";
    public const String DefaultURL = "";

    protected override void OnActionApplicationAuthorizationSuccessful(string action, 
     string actionQueryString)
        string targetLocation;
        String fullTargetLocation;
        string url = Request.QueryString[ActionQueryStringValue];
        // TODO: Validate that the URL is from home domain
        if (url != null)
            targetLocation = url;
            targetLocation = DefaultURL;
        // we assume that the query string startswith '?'
        fullTargetLocation = targetLocation + actionQueryString;

The magic is in the OnActionApplicationAuthorizationSuccessful method, which allows us to override the authorization successful target. The HealthVault SDK HealthServiceActionPage now provides us several OnAction methods which could be use to override the particular APPAUTH targets.

You can also download this code from MSDN Code here.

Testing your application on older versions of IE – Web app compat that is!

Recently I ran in a bug in our AHA application on IE 6. Coming to the terms with testing across multiple browsers is a painful realization of the evils of web development. I tried several ways by which i can install IE 6 on my Vista machine, including tricky thing like DLL redirection. But this is way too painful – however I stumbled on a sweet way of doing application compatibility tests – virtual pc!!

Here is the cook-book way to get different version of IE for compatibility tests –
1. Deploy your application on a staging server
2. Install Virtual PC 2007 (it works on Vista)
3. Get the IE testing images from here.

One downside of this approach is that you cannot step into and debug you application because virtual pc is a painful to configure for running on your corporate LAN :(.