August 2008 - Posts - Jon Galloway

August 2008 - Posts

MSDN Low Bandwidth Bookmarklet

There’s a semi-hidden feature in the MSDN Library website: Low Bandwidth view. We’ll talk about how to use it, why I like it, and some tips for switching it on and off. We’ll end up with an MSDN Low Band bookmarklet I whipped up to make it even easier.

The Low Bandwidth view has been available for a few months, but you wouldn’t know about it unless someone told you, since the only way to turn it on is to monkey with the URL. Try it - browse to:


Now we’ll add the magic word: “(loband)” right before the “.aspx” at the end:



Why LoBand is High Value

Simpler Layout

The obvious difference is that it replaces the navigation treeview on the left with a simple link. There are other subtle differences – simpler layout, fewer superfluous images. Higher signal to noise in my book.

Smaller Page Weight

The High Bandwidth version of this page weighs in at 100KB of HTML, but 400KB total by the time all the images, javascript, and CSS are loaded. Compare that with 66KB HTML / 70 KB total for the low bandwidth version. In this case (which is pretty representative) the low bandwidth version slimmed the page weight by 82.5%.

Faster Page Load

I’m not just talking about the smaller HTML here. The navigation tree on the left contains tons of nested unordered lists (ul>li>ul>li etc.). It’s actually a big improvement over the former HTML for that treeview, which (if I remember correctly) included a bunch of horrible nested tables with inline styles and javacript attributes. The new treeview uses a Telerik control, and outputs relatively clean HTML. Still, that treeview takes a while to load up – on my relatively quick development machine (with a very fast internet connection), the low band page loads twice as quickly – most of the time is spend in rendering the page. I’m not talking about milliseconds of difference here, I’m talking about 1 second load / draw time for low band vs. 4 second load / draw time for high band.

Who Cares?

Well, if you’re a Microsoft developer, you spend a lot of time on MSDN. There’s the time saver factor, sure, but more important is that fast load times removes the barrier to exploring the site.

Getting To The LoBand

The simplest way is to just add that (loband) bit before the .aspx file extension. If you’re on a page which already has one of those funky filters in the URL (like this: you can just add a comma and put it in afterwards:,loband).aspx

When you switch to low bandwidth view by tweaking the URL, you  get a a “persist low bandwidth view” link at the top, which is nice. Clicking that link sets a cookie, so all MSDN you visit will be in low bandwidth view. That sounds great, but I find there are times where the low bandwidth is too low. Some pages (especially articles) are hard to read, and when learning a new object model the navigation tree is helpful. In that case, there’s a link at the top (where the “persist low bandwidth view” link used to be, before we clicked it) which unsets the cookie and returns us to the normal, high bandwidth view.

That all works, and I’ve used it since I heard about the low bandwidth view a few months ago. Still, it gets old – especially editing the URL the loband bit every time I’ve removed it.

Enter The Bookmarklet

Bookmarklets are great – they’re short Javascript functions that you bookmark, so you can run the Javascript on any page by opening the bookmark. They’re kind of like tiny Firefox addons. You can read more about bookmarklets, of course, on Wikipedia.

Well, after messing with that MSDN URL enough times, I figured it was time for a bookmarklet. So here it is: MSDN Low Band

It’s just a simple toggle – when you’re in the normal view, clicking the bookmarklet will switch you to Low Bandwidth view. Clicking it again will return you back to the normal view again. In Firefox / Opera / Safari, you can just drag that peachy colored button to your Links toolbar. In Internet Explorer, you’ll need to right click the link and select “Add To Favorites”, making sure to save to the Links favorite folder. I’ve tested it in IE, Firefox, and Safari.

The Bookmarklet installation help page has some nice screenshots and more information on installing Bookmarklets. If you’re interested in writing your own bookmarklets, I recommend you use a web based Bookmarklet helper page to simplify the grunt work, like this one.

So How Does It Work?

It’s really simple. At first I messed with the URL, but then I figured out that it was simpler to just modify the cookie and reload the page. Here’s the code, formatted so it’s easier to read:


Subtext 2: OpenID Login Support

The recent Subtext 2 release includes a feature I worked on: OpenID login support. Let’s take a quick look at how you use it, then we’ll talk about the how the code works and why it’s a useful feature.

What’s OpenID?

I’m a big fan of digital identity, and could ramble on about OpenID for a while. But if I did that, this blog post would be published sometime after Windows 7 ships. Fortunately I pushed OpenID on some people who are a bit more prolific than I’ve been of late, so I’ll refer you to this post by Jeff Atwood (CodingHorror) and this webcast by Rob Conery. Scott Hanselman wrote a great overview of OpenID, as well.

The elevator pitch: Rather than being issued an account at every single website you login to, you issue them one. You establish an OpenID URL, which only you can login to, and then you give it as your account information to sites which support OpenID authentication. You’re in control of your account, you’ve got a central place to manage your password, etc.

OpenID is a generic account that you can reuse on other websites.

Too Hard! Couldn’t I Just Fax Someone My Birth Certificate?

If you haven’t used OpenID, this is going to look complex. That’s because I’m showing you the hard case – it’s like learning to play Stairway To Heaven when you don’t have a guitar or amp. The first time through, we’re going to have to run down to the pawn shop to get you a Fender knockoff and a thrasher amp, but the next time you’re ready to rock you’ll be all set. So hang with me while we get setup, and at the end I’ll show you how it will work when you log in to your site tomorrow.

Step 1: Get an OpenID

There’s a good chance you’ve already got an OpenID, since many popular services like Flickr, Yahoo, and Blogger are OpenID providers, meaning that you can user your account with those services as an OpenID identity:

If you don’t have an account with any of those services (or these on the OpenID public providers list), I recommend signing up with – they’ve got great support, and rich security features if you want to use them, such as InfoCard integration and phone verification.

Step 2: Tell Subtext What OpenID URL You’ll Be Using

The Security / Options tab has a new location where you can enter an OpenID URL. It’s important that you get this right – we’ll try to clean this up for you, but I recommend you type this as exactly as possible. In my case, my OpenID URL is, not Even the trailing slash is important.

Note that to in order to make this setting, I’ve logged in to Subtext using my standard Subtext username and password. That login doesn’t go away when I setup OpenID authentication, I’ve just enabled an additional security feature – I’ve got two ways to login to my blog now.

Subtext - Security Options (OpenID)

Step 3: Login Using OpenID

Now that Subtext knows my OpenID URL, I can use it to login to the site. The login dialog includes an OpenID sign-in prompt at the bottom, so I enter my OpenID URL in the prompt and click Login.

Subtext - OpenID Login

Now here’s the part you may not be expecting if you haven’t used OpenID – I need to login at my OpenID provider. That’s not such a big deal, though, because myOpenID (and many other providers) have a “Stay Signed In” option option, which is appropriate if you’re logging in from a computer which is in a secure location (your home, a work computer you keep locked, etc.). The Versisign Seatbelt Firefox Extension is a pretty handy way to sign in to your OpenID identity once for a browser session, too.

Subtext - myOpenID Login

Now, the first time I log in to myOpenID from my Subtext blog, myOpenID is going to ask me if that’s cool. Again, a little unexpected if you haven’t used OpenID before, but this is a one time thing. We’re telling myOpenID that my Subtext blog is going

Subtext - myOpenID Verification

So, I type in my password and click the Sign Button, and my OpenID provider redirects me back to my Subtext instance (with an “authenticated” message), and Subtext logs me in:

Subtext - Admin

Fine. Now Show Me Easy.

Thanks for hanging in there. Here’s how it looks tomorrow, providing you’ve checked that “Stay Signed In” checkbox. First, we browse to the login screen, enter our OpenID URL, and click Login:

Subtext - OpenID Login

Now, we’re automatically logged in and brought to our admin screen:

Subtext - Admin

If you hadn’t checked that Stay Signed On checkbox, you’d get one screen in the middle – the login page for your OpenID provider’s page.

How’s It Work?

That’s the subject of another post, but let me show you one quick screenshot which shows the HTTP traffic during that last login.

Subtext - OpenID trace (Fiddler)

That shows the general sequence of events:

  1. I requested the Login page (it’s running on my local machine –
  2. The DotNetOpenID login control makes a request to the URL I provided, saying “Yo. My URL is, can you authenticate the user and verify that I’m on their list of sites?”
  3. There’s a little negotiation between the two sites, after which myOpenID returns an “Okay” message via SSL.

Show Us Your Code

Sure. For this release, I just used the DotNetOpenID.OpenIdLogin control, which is as simple as dropping the control on the page and handling the LoggedIn event. Scott Hanselman wrote about this before when he set up OpenID on DasBlog. In the case of Subtext, here’s the code I added for that LoggedIn event:

protected void btnOpenIdLogin_LoggedIn(object sender, OpenIdEventArgs e)
   e.Cancel = true; //required to prevent logging everyone in
   if (e.Response.Status == AuthenticationStatus.Authenticated &&
       SecurityHelper.Authenticate(e.ClaimedIdentifier, chkRememberMe.Checked))

You can see it in context in the Subtext SVN browser. Now that I’ve worked with it, I’d like to ditch the OpenIdLogin control for a future release. It works just fine, but it generates HTML that I’m not very happy with (table based markup, not CSS friendly). In the future, I’d probably write my own control and just use the libraries which are included in DotNetOpenID – they’ve been great.

OpenID Passthrough

There’s another new OpenID feature in Subtext 2.0 – OpenID Passthrough. The idea there is that you can use your blog URL as your OpenID URL, and it just redirects over to your “real” OpenID provider. Let’s assume that my blog was deployed to; in that case I could make the following OpenID Passthrough settings on the Subtext / Configure screen, after which I could use as my OpenID URL.

Subtext - OpenID Passthrough

Upgrading to Visual Studio 2008 / .NET 3.5 SP1

Have your Visual Studio Installation Media Handy

I was prompted for the original installation media both when uninstalling the SP1 Beta and when installing the SP1 RTM. The file it’s looking for is vs_setup.msi in most cases, but they’re not all created equal. If you installed from a Visual Studio 2008 Professional DVD or image, you can’t just insert a Visual Studio 2008 Standard DVD. In my case, I installed of in ISO image, so I mounted the iso file (en_visual_studio_team_system_2008_team_suite_x86_x64wow_dvd_X14-26461.iso) as my F:\ drive and browsed to vs_setup.msi.

Visual Studio - Installation Media Prompt - 2

You don’t need it yet, but you don’t want to get half way through the upgrade and realize your install media is back at home, or that you deleted the ISO file and you have to wait for the 4GB download. Got the install media? Great, onward!

Use the Visual Studio 2008 Service Pack Preparation Tool

I think the biggest tip here is to use the Visual Studio 2008 Service Pack Preparation Tool. The original help information SP1 Beta (since updated) had a long, involved un-installation process, so people who’d had to uninstall that before figured we’d have to go through that process again. I had to a month ago, and it didn’t go very smoothly for me – probably due to some internal, pre-release builds of Silverlight 2 I’d installed at the beginning of the year. I ended up having to uninstall everything developer related to fix a Silverlight Package Load Failure error.

So – that’s all been simplified now, and in most cases it sounds like it’s working great. I ran it on two of my computers (which have been littered with alpha and beta stuff) and the Visual Studio 2008 SP1 install ran flawlessly. I’ve been listening on Twitter, and it’s been a smooth upgrade for most people (notable exceptions: Rick Strahl, Sam Gentile).

Heath Stewart's post on the Service Pack Preparation tool indicates that the SP1 install will block says the SP1 install if you've installed the SP1 beta at any point, so the main reason I'm calling the Service Pack Preparation Tool out here is to save you from going through an unnecessary manual install only to get the prompt indicating that you still need to run the Service Pack Preparation Tool.

According to Heath:

The tool will verify Visual Studio integrity and remove previous Visual Studio 2008 updates or pre-release software

  • Microsoft Visual Studio 2008 - KB945140 (Beta)
  • Microsoft Visual Studio 2008 - KB944899
  • Microsoft Silverlight Tools Beta 1
  • Microsoft Visual Studio 2008 - KB949325

So if you've never installed any of those betas you don't need to run the prep tool, however based on my experience installing Visual Studio over the years, I like the sound of "verifying Visual Studio integrity" before installing. I'd expect that the tool would run really quickly if you haven't installed the beta.

So, I'd recommend that you grab the Service Pack Prep Tool and let ‘er rip!

Visual Studio Service Pack Preparation Tool

Allow some time for the Service Pack Prep Tool - it took 45 minutes on one machine, and others have reported that it ran for 8 hours or more. For those reasons, you might want to take some precautions to make sure you don't have a prompt holding up your install if you're going to be away from your computer while it's running. Here are a few tips there:

  1. As I mentioned before, you should expect to see a prompt for the installation media during the uninstall. If you can insert the media into the same drive you installed from in the first place (easy if you installed off a DVD drive, not so easy if you just attached an ISO file), you won't have to watch your computer for the media installation prompt.
  2. There's a check for process which will require a reboot when you're done. If you're going to be away from the computer while, I'd make sure to shut down your browsers and the Vista Sidebar (not sure why, maybe uses managed code).

Running the Visual Studio 2008 SP1 Installer

There are four installs listed on the Visual Studio 2008 Service Pack 1 (SP1) and .NET Framework 3.5 SP1 Downloads page:

The Visual Studio 2008 SP1 install includes .NET 3.5 SP1, so that'll do it. Again, be ready for that installation media prompt and the incompatible processes check.

Reinstalling The Silverlight Tools

The Service Pack Prep Tool removes the Silverlight Tools (as it should) so you need to reinstall those when the SP install completes. They've just updated the Silverlight Tools installer (silverlight_chainer.exe) in-place, so you can grab it from the same location it's always been at: Tim Heuer's got more information on Visual Studio 2008 SP1 and Silverlight Tools.

Great - So What Did I Just Install?

I think some of the most interesting features are ASP.NET Dynamic Data, Entity Framework, ADO.NET Data Services (REST based), XBAP and ClickOnce support for Firefox, the Client Profile (24MB lightweight .NET framework which is makes it easier to distribute .NET applications to users who don't have the .NET framework installed).

There's a lot more, though. Rather than writing up "yet another SP1 feature list" I'll point you to a few which I've found helpful:

First off, you didn't install ASP.NET MVC, although you got a building block (System.Web.Routing - similar to URL Rewriting, but it's bi-directional). Phil Haack explains it all in a post titled (oddly enough) ASP.NET MVC Is Not Part of ASP.NET 3.5 SP1.

ScottGu's out of the office right now; fortunately Scott Hanselman stepped up with good overview of what's in SP1.

Here's what changed from a performance point of view.

Dr. Tim Sneath wrote a great post on the WPF enhancements in SP1 from when the Beta was released.

Here's the overview at MSDN: Visual Studio 2008 Service Pack 1 and .NET Framework 3.5 Service Pack 1

If you want the point by point list, take a look at the following KB articles:

  • 950263 List of changes and fixed issues in Visual Studio 2008 Service Pack 1
  • 951845 List of changes and fixed issues in Visual Studio 2008 Service Pack 1 for Team Editions
  • 950264 List of changes and fixed issues in Visual Studio 2008 Service Pack 1 for Express Editions
  • 951847 List of changes and fixed issues in Visual Studio 2008 Service Pack 1 for the .NET Framework 3.5

And if you really want the low level details, Patrick Smacchia used NDepend to show exactly which classes changed in SP1.

ASP.NET Themes Don’t Like IE8’s X-UA-Compatible header; Neither Do I


I ran into an interesting issue a few months ago with IE8 support on sites which use ASP.NET Themes. I’ll talk about the issue and how to fix it. More important, though, I’ll talk about how this small example fits into the whole IE8 / X-UA-Compatible thing, and why I think the way that turned out was bad for everyone.

The Problem: That First Meta Tag

If you’ve got a page that doesn’t render correctly in IE8’s new standards mode, you can add a meta tag to the page which requests that IE8 render it in IE7 mode. The problem I ran into would have been comical if the timing had been better:

  • IE8 only recognizes the X-UA-Compatible header if it’s the first META tag, appearing immediately after the <HEAD> tag
  • The ASP.NET Theme system writes out the theme CSS reference immediately after the <HEAD> tag

Of course, the reason I know that is that I needed to emulate IE7 on a page which was using ASP.NET themes. Video.Show was released in November 2007 and was tested on Firefox 2, Safari 3, and Internet Explorer 7. We built a demo for the MIX 08 conference which ran on the a Pre-Beta 1 release of IE8. Back then, you had to opt-in to super-standards mode, so our IE7 capable markup did just fine. Here’s how that page looked:

IE8 After Header

A little while after that, IE8 Beta 1 came out. One of the significant changes in Beta 1 was that IE8 would render your page in standards mode unless you specifically opted out. That was important to us because our client on that project wanted to be able to use the Video.Show demo we’d built for him, and it didn’t work well in IE8 Beta 1. Here’s how it looked:

IE8 Before Header

The most obvious problem here is that the page background was messed up. The page structure is a bit complex due to the expanding banner at the top, and IE8 calculated that the page header extended to the bottom of the expanding  banner area. Also, the navigation links below the header were showing in a vertical line rather than floating left in a horizontal row. We had a very short turn around time for this project, and the IE8 display quirks weren’t well documented at that time, so tried just adding that fancy new X-UA-Compatible header:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
<html xmlns="">
  <head  id="Head1" runat="server">
    <meta http-equiv="X-UA-Compatible" content="IE=7" />
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <link rel="shortcut icon" href="favicon.ico" />
    <script type="text/javascript" src="Javascript/silverlight.js"></script>

However, here's what was actually rendered:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
  <html xmlns="">
  <head id="Head1">
    <link href="App_Themes/Default/DefaultStyle.css" type="text/css" rel="stylesheet" />
    <meta http-equiv="X-UA-Compatible" content="IE=7" />

 content="IE=7" />
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <link rel="shortcut icon" href="favicon.ico" /><link rel="stylesheet" href="css/lookDefault4.css" type="text/css" />
    <script type="text/javascript" src="Javascript/silverlight.js"></script>

IE8 didn’t recognize the X-UA-Compatible header because the ASP.NET Themes engine always writes out the CSS link as the element in the head section.

How I Fixed It: A Custom Response Header in IIS7

Since I was setting this up in a virtual machine for demo purposes, I could easily make server changes. Here’s how I added that header in IIS7:

IE8 Adding Header

The IE blog has links to instructions on setting those headers various servers:  IIS7.0, IIS6.0, Apache 2.2, Apache 2.0, Apache 1.3. So, yeah, it works, but it’s not perfect. For one, it sets that header for all pages in the site. But, more concerning – what would I have done if I wasn’t able to make changes to the server configuration? If you’re running under IIS7, you can tweak headers with a change to your web.config file:

<?xml version="1.0" encoding="utf-8"?>
        <clear />
        <add name="X-UA-Compatible" value="IE=EmulateIE7">

Otherwise, you can code your way around it with an HTTP Module or something, but the point is that the solution’s so simple anymore. All that brought me back to the X-UA-Compatible conversation from several months ago.

X-UA-Compatible: One Developer’s History

One of the big changes in IE8 is a major shift in the method of selecting the rendering mode for a particular file. The DOCTYPE switch was born a decade ago, and made sense at the time – it used an opt-in model which assumed that a page with a valid DOCTYPE knew what it was doing, so browsers would render the page according to the latest browser standards. It seemed to make sense, but there was trouble in DOCTYPE paradise:

Unfortunately, two key factors, working in concert, have made the DOCTYPE unsustainable as a switch for standards mode:

  1. Egged on by A List Apart and The Web Standards Project, well-intentioned developers of authoring tools began inserting valid, complete DOCTYPEs into the markup their tools generated; and
  2. IE6’s rendering behavior was not updated for five years, leading many developers to assume its rendering was both accurate and unlikely to change.

And so, the IE8 team came up with what most folks would agree is a good idea: opting-in to “standards mode” itself is meaningless unless you specify which standards you’re opting-in to. Targeting “web standards” is great as a platonic ideal, but in reality our pages are rendered by specific browser versions. It’s a lot more practical to opt in to a specific browser version’s rendering mode than a mythical and fluid “standards” mode.

But, then, there was question: since IE8 will be entering a world already populated by billions of web pages written over the past dozen or more years, how should it handle them? Thus began a comedy of errors.

Proving That All Of Us Is Dumber Than Any Of Us

How it’s remembered:

The IE team first announced that it would require pages to opt-in to IE8’s “super-duper standards mode”. The web development community loudly protested, and the IE team changed the default behavior so that pages would be rendered in “super-duper standards mode” by default. We all won!

Here’s what actually happened:

  1. The IE team had it right the first time. There are billions of webpages out there which won’t work well in IE8 without changes.
  2. The IE team forgot that the web development community, by and large, hates them so much that… I don’t even know how to describe it.
  3. The web development community reacted to IE team’s announcement the way they react to just about (except improved CSS support) that the IE team announces. They protested loudly.
  4. The IE team decided to switch it up a bit and did what the web development community was telling them they wanted, and quickly to boot.
  5. We all lost, but almost no one’s admitting to it.

I know this is all old news – Joel Spolsky wrote about this in March. His post was way too long, but the basic idea was that an idealistic solution isn’t all that useful because people don’t install browsers that can’t display their favorite sites. A lot of people disagreed, using two different arguments:

  • It’s not easy, but we have to try to do the right thing” – I agree with the intentions, but I’m cynical here. Users (and IT shops) are still stalling on the upgrade from IE6 to IE7, even though IE7 was a relatively minor upgrade.
  • IE is irrelevant” – These responses were popular in the web standards community, but were themselves irrelevant. Okay, all your friends are running Firefox 3 on their Macbook Air’s, but the browser stats show that IE is still the dominant browser by a large margin. Unfortunate facts are still facts. If you’re hoping that real people will actually use your sites, you have to care about how IE8 works.

Fix Your Pages! Also, Let Them Eat Cake!

I’ve heard a lot of people say that this is a good time for us all to just get this over with and move on. After all, you’ve got several options:

  1. Fix your pages. While I’ve been working with IE8 Beta 1, this is a little easier said than done – there are several IE8 regression bugs which work fine in IE7 and below but fail in IE8. Sure, it’s beta 1, but my point is that this isn’t simply a case of “good HTML / CSS = perfect display in IE8” just yet. I’ve spent several days chasing down several of these bugs, for instance. But, sure, providing that IE8 is really good on CSS 2.1 support, this is the ideal solution. The underlying assumption is annoying, though – the idea is that IE8 is now the authoritative CSS reference. As of now, that’s not at all the case. In some cases my HTML and CSS are correct, work in FF2/3 and IE7 – so why should I have to “fix” them to render in IE8? Arguing that this pain is worthwhile because we’re “doing the right thing for the web” is only valid if we really are improving the HTML/CSS quality of the web, and I’m not convinced this does the trick.
  2. Use the X-UA-Compatible header in your pages. This is listed as the standard response when people list cases where it’s not so easy to fix your HTML. The example above shows a case where a pretty new website built on a pretty modern web framework didn’t support that easily. Forget the case where the HTML is bundled in old CDROM’s or help files written out by installers – a web application built on ASP.NET 3.5 less than a year ago had problems with that approach.
  3. Write the headers some other way. Sure, it was possible in my case, but depending on the site, the skill level of the developers working on the site and their access to the server configuration, this could add up to an unacceptable amount of time. Unacceptable as in “Sorry, we don’t support or recommend IE8 – please use IE7. Thanks!”

Granted, I’m testing with IE8 Beta 1 and IE8 Beta 2 is due out soon, so this situation could improve the situation for actively developed websites. But the operation of the X-UA-Compatible header seems to be pretty much set, and I don’t think it works well with the majority of the billions of HTML documents we’ve already created.

More Posts