Freigeben über

Channel 9 Video, more details on Reference Source

  • Artikel

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.

 

dbgsetup

 

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...

Comments

  • Anonymous
    October 04, 2007
    PingBack from http://msdnrss.thecoderblogs.com/2007/10/04/channel-9-video-more-details-on-reference-source/

  • Anonymous
    October 04, 2007
    Scott just announced it: http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code

  • Anonymous
    October 05, 2007
    This was asked in Scott's annoucement blog, but maybe you can answer it as well (I don't think it got answered - probably got burried under the 600odd comments on his blog :) ) Can we use this functionality (of loading symbols manually / automatically) for our own code? That is, if we as a product publish our own set of APIs for the customers, and now want them to debug into our code (similar to what you are presenting here for .NET). Would your framework allow for that? If I didn't know much, I'd say that we just load another server onto that list, and try to load the symbols (right-click as in your example). Ofcourse, we need to what the "symbols server" implements.

  • Anonymous
    October 05, 2007
    Symbol Server actually doesn't implement anything - it's actually just a method of laying out the symbol files in a way that a debugger can figure out which one is the right version.  Other than that, it's a plain web server, and it's already available, see: http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx But most of this is already available there.  The piece that Orcas provides - being able to get a file via HTTP out of a PDB reference - will allow you to do the Source Server part (also documented in the Debugging Tools for Windows).   After this gets shipped I'll sit down and see what it would take for someone to implement this and then do a blog post about it.  Feel free to remind me post-VS2008 ship. :) Hope that helps!

  • Anonymous
    October 12, 2007
    摘要本期共有9篇文章：.NETFramework源代发发布Tip/Trick：在.NET3.5中编写ToJSON扩展方法在GoogleAnalytics中统计访客浏览器的Silve...

  • Anonymous
    October 14, 2007
    Great video! If possible, I want to say, could you speak more slowly next time for the people who are not good at English?

  • Anonymous
    November 05, 2007
    To have the debugging not try to load symbols for modules that won't have symbols (and therefore not incur the performance cost of searching in vain), there is a solution. The debugger can maintain a list of modules for which to not load symbols. This would be the full path name from the pdb. The user could add an item to this list from a new context menu item on the Call Stack and Modules windows: "Exclude from Symbol Search" (or some better name). The Symbols dialog can provide this list, and a means to add and remove from this list. There could also be import and export, and there could be a default list of the managed symbols that wouldn't be found, or the list could be imported by the user. You could make this happen automatically. The debugger can add a module to this list when the debugger can't find symbols for it. After the symbol path is modified, the debugger can scan for these modules again that first time, so you take the perf hit only once. These changes would work for both native and managed debugging, and could really help start debugging performance. Just some suggestions...

  • Anonymous
    November 05, 2007
    Hi Adam - Yes there are several possible solutions to this problem that we've discussed, including those you've outlined above.   Unfortunately none of those will be available in the Visual Studio 2008 upcoming release. You make a good point - however - that this would be generally useful as a way to prevent loading of symbols for binaries you'll never care about debugging. Thanks, SB

  • Anonymous
    November 20, 2007
    By now I'm sure you've heard that Visual Studio 2008 & the .NET Framework 3.5 shipped on Monday .  

  • Anonymous
    November 20, 2007
    By now I'm sure you've heard that Visual Studio 2008 & the .NET Framework 3.5 shipped on