Update (10th Feb 2010) – a more thorough investigation of this issue has been carried out by us (after being asked to help Microsoft fix the problem) and a new fix is detailed here.

We’ve been playing around with the beta 2 of Visual Studio 2010 and really like the Web Install idea - although the actual VS2010 part of the download appears to be throttled at around 4Kb, which is a little frustrating!

At the very end of the installation you get to install the new MSDN Help 3 Collections, choosing online or local help as your primary source.  If you’re running behind a web proxy that requires authentication you will see a “fatal error occurred” message pop up, and that’s it – there’s nothing you can do to get help on to your machine (except to get your SysAdmin to allow you out of the building without going through the proxy).

However, we have found a rather cheeky solution to this problem – the rather marvellous Fiddler Http Web Debugging Proxy.

To get it to work

Scenario 1: All you should have to do is download Fiddler, install it and run it, then hit the ‘Get Content Online’ link again.  Eventually you’ll see all the content offerings, select the ones that you want and then hit the Update button.

You should see web requests in Fiddler going through to packages.mtps.microsoft.com once the transfer starts.  Don’t worry if they appear to take for ages to complete – you’re watching a multi-part download, and nothing really interesting is going to happen until it’s finished!

Scenario 2: If this doesn’t work – then it’s possible you might have to force Fiddler to remember your credentials for your proxy.  The best way to do this is to load a page in IE, and you should see a proxy login box appear.  Enter the correct credentials for your proxy and check that the web page then loads correctly.

Now try to get the help content again – it should work.

Why does Fiddler make it work?

Here’s our theory: Obviously the Help installer client is not proxy-aware.  So it attempts to make a connection to the package download location, but hits the system proxy.  When this happens, the proxy returns a request for credentials, but the code isn’t written to send them over, and so it simply crashes.

The reason why fiddler makes it work is because if it receives a Proxy Authentication request (Http Status Code 407) from the upstream proxy, it responds with the identity of the user running Fiddler (Scenario 1), or a token that has previously been known to work for the current session (Scenario 2). 

If that isn’t good enough, it then pushes the 407 back to the client.  Now we already know that the Help Installer itself can’t cope with this, so in our Scenario 2 we use Internet Explorer to cheat, since it displays a login box when credentials are required.

IE then sends those credentials to Fiddler, which in turn are then sent to your proxy – if the proxy then lets the request out, Fiddler will cache that authentication token to be used with ALL future requests (not just those coming from IE).  So when the Help Installer then makes another request, it signs that request as authenticated even though the Help Installer didn’t know it needed to.