Channel 9 Video, more details on Reference Source
Yesterday afternoon I did a Channel 9 video talking about the Reference Source program we announced yesterday, plus doing a live demo of how it works. That's the first time I've done one of the Channel 9 videos. It's a little disconcerting at first - there's no script or practice or even editing. Some guys pretty much just show up in your office with a handheld camera and a tripod and start filming. Fortunately, it seems like it turned out pretty well. But I'm definitely not expecting any Oscar nods.
In the video, you'll see me actually run the debugger on a simple Windows Forms project, and then load the symbols for System.Windows.Forms.dll and mscorlib.dll. In the video, VS was already configured, but here's some more detail on exactly how that's going to work.
Setup Steps
As noted in Scott's blog, you need to do some setup in Tools/Options/Debug. Here's the full list of steps, just to show how easy this is to set up. Also note, this functionality isn't present in the VS 2008 Beta 2 release - it's been added for RTM.
First, you need to enable Source Server support, and then turn off "Just My Code" (because its, uh, not your code that you want to debug!). If you leave this on two things happen. First, you won't see the .NET frames in the call-stack. Second, even if you enable "Show External Code" on the call stack, you won't be able to set breakpoints. "Just My Code" disables setting breakpoints in optimized code.
Next, you enter the symbol server path. One thing Scott didn't call out is that the URL for this is still TBD - the one we put in there is temporary. Once the servers are ready to come online, we'll have a final URL for this. I put that URL in there just because the server I'm currently using for testing is, well, under my desk. No, you can't have that URL. ;)
Note you're also required to add a caching path as well.
Performance Considerations
I've seen some questions about why I used the Right-Click -> Load Symbols method on the call-stack, so let me dig into this a bit.
The two settings that are relevant here are the "Manual Load" setting (red), and the "Load 'Em Now" setting (green).
"Load 'Em Now" means that it will attempt to load all the symbols when you close the dialog.
When using the Reference Source stuff, I think most people will want to use Manual Load, strictly for performance reasons. We all know how critical it is for F5 to be snappy, and that's at issue here.
Two things impact this.
Problem number 1: There may be lots of symbols out there and they tend to be large (10+ MB). 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. (Hint: I do recommend doing this on your first debugging session, and then going to lunch or something just as a way to get all of the symbols downloaded and cached at once).
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 that server 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 you launch the debugger.
Again, depending on how fast your Internet connection is, and how fast the servers are, 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 (over a purposely slower connection) 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. Also note you can multi-select in the Call Stack to do multiple DLLs at once. I have been talking with the VS debugger guys about ways to make this smarter/more efficient but we haven't found a robust solution quite yet, and in any case the behavior we have today is the behavior you'll get for RTM.
So it will work either way, and you can decide which is better for your scenarios when you actually start using it.
Downloadable Source
We also announced that we'll be making the source available as a download as well. Note that this won't be online immediately. The debugging experience really is the major piece of the value here for most people, so I've been focused on delivering that first, and that will be ready close to the VS 2008 ship day (the plan is for the servers to go live on the same day, I think it's going to happen, but it's aggressive, so there may be a small lag there).
Anyway, that's V1 of the server-side piece. We're looking to get the downloadable source functionality into the V2 server-side, which will likely be rolled out after the New Year. You might be saying to yourself "geez, just zip up the darn source, what's so hard about that?" Good question.
One of my top goals here was to make sure that the cost for any individual team releasing source was very close to zero. If this process is expensive, or error prone, or cumbersome, then it won't happen as often, which is bad for everyone. So on this front, I'd like to see if we can't make the server-side build the download distro's dynamically so that it happens for "free" and maybe, just maybe, users can then download source that exactly matches their version in the way the debuggable source does with no extra packaging work. Hey, a kid can dream, right?
Hope that helps...