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!
