Description

In this video we find out about how this is all going to work and see it in action as Shawn steps into the Windows Forms code from Visual Studio. Shawn also talks about how this has been something he has been working on for a long time in order to bring a really
deep debugging experience for .NET developers.

I'll blog about this, it's a good question, so here's the answer to the "manual load" issue...

Visual Studio can load symbols in two modes:

1) Load them for every binary in the process, or
2) Load them manually.

You can put it into (1) mode above by not checking the "Load symbols manually" option in Tools > Options > Debugging > Symbols.

I don't think you'll want to do this when using the Reference Source stuff, and it's purely for reasons relating to the performance of your F5-experience.

Problem number 1: There may be lots of symbols out there and they tend to be large. If you're on a slower connection, it could take a fair amount of time to launch your first debugging session. You could easily be looking at 50 megs of symbols. Fortunately,
these do get cached locally.

Problem number 2: And this is the big one. VS doesn't really have any way of remembering which symbols it found and which ones it didn't between debugging sessions. Since you've added an external server for lookup, it's going to go out and ping for every
symbol that it doesn't find locally/cached. It doesn't know that the symbols for user32 or ntdll aren't on that server, so it's going to ask EVERY time.

Again, depending on how fast your internet connection is, this may or may not be an issue. But ASP.NET loads something like 18 DLLs into it's process space, and in my quick testing it made the F5 time go from ~2 seconds to 5-or-6, which just isn't acceptable.
By doing the manual load, you avoid this problem altogether.

I have been talking with the VS debugger guys about ways to make this smarter/more effiecient but we haven't found a robust solution quite yet, but we'll keep working on it.

I know you're kidding - but a word about "loopholes". It's important to remember that backwards-compat is always going to be targeted at the public API. If your application takes too much advantage of internal workings of the code, that could be trouble
down the road.

You'll need Orcas to view the code. In order to install Orcas, you'll need to install the .NET Framework 3.5 which includes updates to the .NET Framework 2.0 binaries (referred to as Redbits), for which symbols will be available. So we won't be releasing
source/symbols for binaries that shipped with VS 2005 because you could never actually debug them - once you've got Orcas on the machine to do the debugging, you can no longer have the VS 2005 binaries.