Making .NET Framework Source Available to Developers
For any of you that have been following my blog, you may remember that I made a splash with a post about possible ways to release Windows Forms source code. This generated a lot of discussion and was picked up by many of the major tech websites out there. That was in February of 2005.
Between now and then, I've taken a new role in the company and had other things (like shipping VS 2005 and getting the AJAX Control Toolkit off the ground) keeping me busy, but earlier this year I started to get much more focused on this idea and pulling together a plan to make it happen.
Today is an exciting day for us here Microsoft and our developers, see ScottGu's Blog for the big announcement: We will be releasing .NET Framework Source Code as part of the VS 2008 (Orcas) release.
Also check out the Podcast on Scott Hanselman's "Hanselminutes" that I did as well - lots more detail in there.
That's right. Getting code ready for release is a big job, and most teams are still focused on getting Orcas itself released, but the current launch lineup is (in no particular order):
- Base Class Libraries (mscorlib.dll)
- ASP.NET (System.Web.dll)
- Windows Forms (System.Drawing.DLL & System. Windows.Forms.dll)
- ADO.NET (System.Data.DLL)
- XML (System.Xml.DLL)
- WPF (System.Windows.DLL)
There may be others as well, but that's what we've currently got a lock on for the initial rollout. The system is setup so that it's easy for us to publish code, so more will get added as time goes on (working on getting LINQ, WCF, and Workflow in there as well).
Scott's Blog has details and screen-shots, but here's some more detail on how it works.
My main goal had been to enable a scenario that we're all familiar with...
You're up late one night writing code. Maybe it's a technology you're just learning or something you haven't tried before. You're getting an exception from deep in the code. You can't figure out why...the blogs aren't helping, the newsgroups aren't helping, the docs aren't helping. The next day you call product support. Since they don't have your code in front of them, it's also hard for them to triangulate what's going on.
Now, imagine you've got source and symbols available. With that, you can enable "Break on Exception" in your debugger, run your scenario, and have the debugger stop exactly where the exception was thrown. The code gets loaded up and you sniff around a bit and realize - duh! - you forgot to set some other piece of state in an earlier call or a parameter. You fix your code and you're off and running.
Even with one of the decompilers (e.g. Reflector) that you can easily get out there, this can be tricky to solve. With the source it's much, much easier.
One of the big challenges here was building as system that didn't require each team to build their own process, installer, etc. And we also had to account for updated releases (Service Packs, etc) so that this didn't become a big tax over time. On the customer side, we also didn't want developers to have to wade through a bunch of choices to find the "right" source & symbols for their install, then have to manually install it and set it up, etc.
It had to just work.
Fortunately, the technology needed to make that happen already existed within the company. We already have a unified place where all the symbols get pushed, and a unified way to get the source that matches those symbols. What's more is that on the server-side, it's just a plain HTTP file server based on IIS.
So a few months ago I started pulling together resources from across the company to help get this to happen. People really rallied around this and I got great support from teams across the company - on the VS side willing to do the work to make the VS Debugger understand how to get these files, on the Windows Debugger SDK side the technology to actually retrieve the symbols and source from an HTTP location, on the MSDN/Code Center side helping build out the server-side that will make all of this available when we launch later this year, and on the management side getting behind this effort and supporting it. It's been great and those teams really are the ones that made this possible.
The experience really is fantastic. There's a screenshot on Scott's blog for setting the options in the Tools/Options/Debugger dialog in Visual Studio 2008. That's pretty much all you need to do. Please note the URL in there is still TBD - that's an example.
All VS needs to know his where the symbols are and the rest happens automatically. When you launch your process, VS can go look at a variety of locations for the symbols to match your binaries - it knows how to tell. So one of the places it can look will be on the MSDN server for this stuff (note this is separate from the current symbol server that's out there - these symbols will have the full information in them like line numbers and variable names). Once it finds the symbol file, it downloads it to the local cache. Now, the symbol file has the pointers to the source files in it. So when you hit a call frame - the debugger checks the symbols file and gets the path to the exact right source file and retrieves that. Moreover, as we release source and symbols for new parts of the product (or new products - this system works for anything) or product updates, they'll just be automatically available for use in a debugging session. No configuration or extra steps needed. Very nice.
It's just that easy - you can step through, set breakpoints, inspect variables, etc. It's goodness, looking forward to making this available later this year!
Comments
Anonymous
October 03, 2007
PingBack from http://www.artofbam.com/wordpress/?p=4913Anonymous
October 03, 2007
This is huge. Thanks so much, Shawn, for pushing this idea and making it happen. It makes the millions of developer lives around the world just a little bit easier. :-) Thanks man.Anonymous
October 03, 2007
Hey Now Shawn, I heard you on Hansel Minutes, it was a good show & it's good to see the Framework source is going to be available. Thx, CattoAnonymous
October 03, 2007
Viva transparency, openness! Today we are announcing that release of source code for the .NET 3.5 FrameworkAnonymous
October 03, 2007
That's fantastic Shawn - I've been looking forward to this ever since you first started talking about it, it's going to make debugging much easier...Anonymous
October 03, 2007
Scott Guthrie just made an exciting post , starting with .NET 3.5 and VS 2008 the .NET libraries willAnonymous
October 03, 2007
Matt Winkler and David Tesar catch up with Shawn Burke to talk about the announcement today that theAnonymous
October 03, 2007
ScottGu just posted info on something our team has been working on in conjunction with Shawn Burke (NDP)Anonymous
October 04, 2007
Shawn - congratulations on this release! I remember you were pushing for this a couple of years ago and it seemed like a great win-win goal. Glad to see you were able to pull it off! RaghavendraAnonymous
October 08, 2007
Yes, you read that correctly. Microsoft is releasing the source code to a bunch of .NET Framework LibrariesAnonymous
October 14, 2007
Scott Guthrie announced that the source code for the .NET framework is being released! Shawn Burke...Anonymous
October 17, 2007
On Friday, the OSI approved two of the Shared Source licenses that Microsoft uses, saying that theseAnonymous
October 26, 2007
It's a boy! No, no, no not that. If you're a SubSonic fan, you may have seen Rob Conery's blog todayAnonymous
January 07, 2008
Wednesday, October 03, 2007 10:58 PM undefined undefined announced on ScottGu's Blog at: ht undefinedAnonymous
January 07, 2008
Wednesday, October 03, 2007 10:58 PM The .Net Framework 3.5 Source Code will be released later this yearAnonymous
January 31, 2008
Scott has announced that the source code for the .NET Framework 3.5 will be released around the sameAnonymous
April 05, 2008
I completely agree with all that here is toldAnonymous
October 26, 2008
[2008. október 27.] Az október 14-i RTW (Ready To Wire) bejelentés kapcsán megvizsgáltuk a Silverlight