Home / Archive by category "ASP.NET"

Notes on Migrating a ASP.NET MVC + SQLExpress web site to Windows Azure

I recently completed a migration of a typical MVC/SQLExpress web site to Windows Azure. It was mostly painless, but there were a few hiccups along the way:

When migrating the database from SQL Express to SQL Azure, some data types had to be changed. All VARCHAR fields must be switched to NVARCAHR, and all TEXT fields must be changed to NVARCHAR(MAX). SQL Azure is unicode through and through, and I believe TEXT fields are deprecated, so this is understandable.

It also appears that spatial/geometry fields can’t be migrated at all through SSIS. Fortunately the open source migration wizard does support migrating these fields, so ultimately I resorting to using that.

Finally, once the web site was converted to an azure project, and the web site was published, I noticed about half my images and my fonts weren’t loading. It turns out that IIS in Azure has different static file mappings than are set on Windows 2008, so it was refusing to serve some file types. Fortunately this can be overriden in web.config:

 <mimeMap fileExtension=".svg" mimeType="image/svg+xml" />
 <mimeMap fileExtension=".woff" mimeType="application/font-woff" />

Once that was updated and re-published to Azure, all content was served successfully.

Facebook, iPads, and the dangers of ASP.NET browser detection

ASP.NET webforms automatically tries to detect the capabilities of the user’s web browser to render appropriate HTML and javascript to the client. It does so by parsing the user-agent string and doing a series of regular expression matches to try and identify the browser in its local database of browser capabilities.

Yes, user-agents and regular expressions, just like it’s 1999.

Obviously, this can go horribly wrong.

Recently we had an issue in production where users on iPads were being presented with a truly wretched user experience. Javascript was completely disabled, layout was skewed, design elements were misplaced…. We finally tracked the issue down to an issue with the browser definition files on an older web server, and the unique user-agent string that gets sent when a user browses from within the Facebook iPad application. If you’re on an iPad using Safari, your user agent string will typically look something like this:

Mozilla/5.0 (iPad; U; CPU iPhone OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B314 Safari/531.21.10

In an older (ASP.NET version 4.0) version of the browser definition files, this won’t be recognized as an iPad, because iPads didn’t exist yet. But the “Safari” and “Version/###” in the user agent string will be picked up by the safari.browser file, and you’ll at least get javascript enabled.

However, if you’re browsing from within the Facebook app your user agent string will be:

Mozilla/5.0 (iPad; CPU OS 6_0_1 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Mobile/10A523 [FBAN/FBIOS;FBAV/5.3;FBBV/89182;FBDV/iPad2,5;FBMD/iPad;FBSN/iPhone OS;FBSV/6.0.1;FBSS/1; FBCR/;FBID/tablet;FBLC/en_US]

Notice no “Safari” within the user agent string. In our case ASP.NET couldn’t recognize the browser at all, so it downgraded the experience to no javascript and downgraded table layout.

This issue can be fixed with custom definitions in your App_Browsers folder, or by installing .NET 4.5 with the updated browser definition files on your server.

Or better yet, ditch webforms entirely and use simple layout with progressive enhancement. Even patching the servers, this ancient method of parsing user agent strings is not a good long term strategy.