The ballad of ms-help:// links

When I started creating collections of links related to Microsoft exam objectives, I tried to use locally installed help files where possible. Even though I knew most were also available online, the local files seemed to offer several advantages:

• I have a 56k internet connection. The local files are noticeably quicker to load.
• I don't want to be hassled with broken links whenever Microsoft decides to redecorate the MSDN site.
• Anyone studying for the exam really should have the product (and help files) installed, even an evaluation version.
• The VS.Net help remembers my preference for viewing C# and/or VB.Net code. I don't see that supported with the MSDN site.

I've run into obstacles trying to share help file links before with SQL Server Books OnLine, because those included a local file path which can vary from machine to machine. Happily, the VS.Net help file urls used a standard prefix: "ms-help://MS.VSCC/MS.MSDNVS". This looked like it would provide the most stable links available.

Strike One

A buddy installed the July 2002 MSDN update and told me it broke my links. The 'standard' url prefix had changed to "ms-help://MS.VSCC/MS.MSDNQTR.2002JUL.1033". Not only did it have embedded version information, but also localization (1033 for US English). That would be fine, except it effectively disabled access to the original help files installed with VS.Net, even though they were still installed. Uninstalling the MSDN update actually restored access to the original MS.MSDNVS data.

So I dug up some javascript code to iterate through the links in the document and replace one root with another. Despite my limited expertise with javascript, the text replacement hack seemed to work well enough. There were a few reports of runtime errors and having to refresh the page to get things working, but none were showstoppers or even included repro details.

The Other Mixed Metaphor Drops

Soon after IE6 sp1 was released, I started to get reports of 'dead' links. Not broken, just dead. Clicking one of the ms-help links did nothing at all. Some visitors reported fixing the problem by modifying the page source to remove the class attributes for the links. I found that simply removing the style sheet link also worked around the problem, but still saw inconsistent results when testing my workarounds. Eventually I figured out that sp1 seems to have new security settings that automatically disable ms-help links from an untrusted source, like my public web site. The real workaround had simply been saving the file locally and loading it from the trusted location of your own computer. I assume there are many Bad Things that can be done with opening resources via file:// links and sp1 simply views any non-http:// links as risky. One other workaround is to add the web page to an IE zone like 'Local Intranet' or 'Trusted Sites', where ms-help:// links are free to open pages just like in the good old days, a few months ago.

I updated my pages with information about the workarounds, which left anyone with updated software with a bit of a hassle one way or another.

This week, another visitor reported that saving the file locally didn't seem to address the problem with the MSDN October 2002 update. I'd had that ready to install for a little while, and as soon as I tried it, I saw the same lack-of-links-linking. I don't know if my earlier testing somehow misdiagnosed the problem, or if the MSDN update further modified IE behavior. So now the only workaround I know of for this problem is to add the page to a zone with more trust than the Internet zone.

So I've started migrating my links from ms-help to http://msdn.microsoft.com. For the most part, it's been very simple, though it's still a drag just verifying that. The file extensions have changed from .htm to .asp and the prefix is usually a consistent "http://msdn.microsoft.com/library/en-us". But I'm abandoning support for the local ms-help links altogether - the url stability I was hoping for is already far worse than microsoft.com has ever been.

In case you have any difficulty with broken links

First, so we can make it a little easier for the next visitor. In the meantime, my link text is always the title of the page it refers to, so that should make a good search target. Unless noted otherwise, all links refer to pages available at http://msdn.microsoft.com, but most should also be available in your local VS.Net or MSDN help files.