Updates to my Azure Ferry App

  • Article

I’ve been working on getting my ferry times app running and have recently been motivated to step it up.  I’m submitting the app to a contest that Microsoft is running for partners to encourage developing Windows Azure apps.  Here a few random things I’ve learned while I’ve been tuning up the app.

  • The AspProviders sample pretty much works now with the November 2009 PDC release of the platform.  I just downloaded the additional samples, pulled the AspProviders files from the sample directory into a new project in my solution, built it and then incorporated the required goo in web.config to get it hooked up.  I now have login and profiles working against Azure table storage with my app.   The only “tricks” here were:

    • Adding an <appSettings> section within the web.config <configuration> section to give the configuration for AspProviders to use:

      blog appsettings

    • Note that I had to make the storage endpoints use https: or I got an exception when I tried to write to these (there is an alternative to set allowInsecureRemoteEndpoints but that’s a bad idea).  Just change ‘em to use https: and all is good.

    • The I added a section for the membership etc. providers.  This goes in your web.config in the <system.web> section.  It looks like this; you can pretty much take the text out of the AspProvidersDemo web.config in the Azure additional samples.  The only thing you have to change is the name of the application in a couple of places (look for an applicationName property), the cookie name (in roleManager) and the properties you want stored in the profile.

    blog membership

    • Finally, change your authentication mode to “Forms” (mine was “Windows”).
    • I had a problem where even though I had logged in, when returning I sometimes wasn’t authenticated and had to login again.  I tracked this down to the cookieTimeout attribute in the roleManager being 30 minutes – for my application, I want to log people out only rarely, so I increased it to 43200 – which is 30 days.
  • I suspect a lot of people writing apps for Azure will have the problems I’ve run into with time zones.  I think these were masked for me in the CTP releases of the platform because they were running in a data center here in the Pacific Northwest and I live in the Seattle area, so the time zones were all the same.  I first noticed a problem in December when suddenly the times I was getting from an RSS feed here were getting translated into weird times when I persisted them to the Azure table storage.  I poked around a bit and realized that Azure has moved to have all the data centers have GMT (also known as UTC, or universal time) as the time zone.  This makes sense because your application can migrate from data center to data center – this is part of the advantage of Azure – so you can’t count on running in any particular time zone.  I’ve read a good MSDN article on how to deal with time zones which I recommend.  A few observations which I’ve learned only really by playing around.
    • This is one of the ways in which Development fabric differs from Azure cloud fabric – your development fabric will run on your local time zone, making these bugs harder to find, and in fact you need the code to not work correctly in development fabric to work correctly in the cloud fabric, which is confusing.
    • Even web roles have their default local timezone set to GMT,  so dates you receive as input from a web form will be considered to be in GMT unless set otherwise.  This turns out not to be an uncommon problem – here’s a blog post that summarizes it for vanilla ASP.Net apps and here’s one that proposes a custom control to capture the browser time zone and make it available to the server through the custom control properties.  It turns out that for my application, I don’t exactly want the browser time zone – because I want to show the ferry departure in the time zone where the ferry leaves, not where the browser user is (if you are in Chicago, the Bainbridge ferry still leaves at 7:05 AM PST, not at 9:05 AM CST).  So I needed to be able to get the time zone appropriate for this ferry provider and use that to convert the time retrieved from the database from GMT to local time where the ferry operates.  Note that this has to take daylight savings time into account.  The approach I settled on is to include an attribute in the XML file which I use to provide information on the various ferry services I know about.  This attribute gives the standard time zone name for the sailings of that ferry service (note this wouldn’t work if some of the sailings were in different time zones, but I’m willing to live with that restriction for now).  Then when I create a user profile, I have the user select the ferry service they want to get information about and I pull the time zone from the XML for the selected ferry service and store it in the profile.  Then at run time, I can pull that from the user profile and convert from UTC to that time zone using TimeZoneInfo.