Shawn Burke : Discussing the Release of .NET Source Code

The Discussion

• 

  This is slightly cool. But why do you have to load symbols for each assembly manually. Cant you just load the whole thing for us who have enough ram?

• 

  I think its because of the load it would put on the server, hosting the code. And for most debugging you would not need to look into the .net source code so I understand their choice.
  
  I would however hope you can enable it always loading with the download version that is going to come out.
  

• 

  NeZz_DK wrote:

  
  I would however hope you can enable it always loading with the download version that is going to come out.
  

  
  
  I think he meant that (last part of the interview questions). The download of the source code (whichever way they package it) will allow offline use of this as well (the "airplane" example).
  
  Can't wait to use it (more than that, just looking at the .NET code and learning from that)

• 

  Nice It would be cool if with the offline version the symbols would all be loaded automatically. I'm so going to install the offline version if the debuggin scenarios and integration is the same.

• 

  As I said before, I think this is a great move.
  
  I have two questions:
  1. Will this work with the Compact Framework too? I really hope it will.
  2. Will we get the source to InternalCall functions? I'm guessing no, but it would be cool if we did.

• 

  A question came to my mind.
  
  Will we see the C#/VB.net compiler opensourced at some point?

• 

  I liked the comment in the code that was shown..."accessibility stuff".  Nice! 

• 

  NeZz_DK wrote:

  I think its because of the load it would put on the server, hosting the code. And for most debugging you would not need to look into the .net source code so I understand their choice.
  
  I would however hope you can enable it always loading with the download version that is going to come out.
  

  
  
  Can you have a symbol proxy?

• 

  If I see another post on this. I will go postal... Just tell people to read ScottGu blog as a general rule and stop spamming my Google Reader!
  
  Want to make the killer RSS ag app? Add a Delete all post with ___ URL option .

• 

  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.
  
  Hope that helps,
  
  Shawn

• 

  Shawn, any chance of answering my questions? I'm particularly interested in whether this will be available for the Compact Framework.

• 

  We're looking at a variety of packages that we may ship.  We haven't made any decisions yet on most of them, but .NET CF is something that's on the investigation list.

• 

  Shawn,
  
  I saw your video, even i feel good now that source is available to us & becomes easy to debug & find out the internals working & loopholes
  
  My question is whether we can get symbols for the existing visual studio 2005 once orcas is released.

• 

  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.

• 

  What is the symbols URL?