Do you dream of debugging Yukon CLR code?
SQL Server 2005 (the database formerly known as “Yukon”) hosts the Microsoft.Net CLR runtime in-process, allowing developers and database administrators to author stored objects (such as procedures, functions, and triggers) as well as user-defined data types (“UDTs”) using a .Net language such as C# or VisualBasic.Net. This makes for a great programmability story, since computation-intensive operations can now be written in a fraction of the time using a language such as C#, and can also be offloaded to the CLR to increase performance depending upon the type of operation(s) in question.
But while most of us no longer queue up before mainframes praying that our stack of 3,072 punched cards from a 14-hour coding (punching?) session isn’t “returned to sender” thanks to a missed semi-colon, Microsoft’s next database server has not decreased in complexity either. With the addition of the hosted .Net runtime, debugging all the cool C# code that developers will churn out is an important supportability issue.
What are the current options available for debugging CLR code in Yukon?
Ok, so the above list is not entirely accurate, given that Borland is expected to join the fray. My point though, is that if you’d like to hit the ground running when Yukon ships this year, VS 2005 is the only option (albeit a fantastic one, what with the ability to create and debug SQL Server 2005 database projects, true mixed-mode debugging capabilities, cool stuff like integrated callstacks, stepping from TSQL into managed code and back, setting breakpoints in both SQL and CLR code, and so on).
However, if you are an independent software developer/database administrator or a hobbyist programmer evaluating .Net programmability in Yukon, the cost is prohibitive (unless you bought EBAY at $6).
Who Wants To Debug CLR Code For $0.00?
So how does a price of $0.00 (+ tax) for CLR debugging in Yukon sound to you? Sure, you won’t get an IDE (at least not yet) but you can still at least debug CLR code running inside Yukon. Enter mdbg, with its own work-in-progress GUI. Mdbg ships with the .Net framework SDK v2.0, and is a replacement for the trusty old cordbg command-line CLR debugger currently available for free with the .Net Framework v1.1. But Mdbg can debug the CLR even when its hosted within another process, and is therefore a great candidate for debugging the CLR hosted within Yukon as well. Mdbg is written purely in managed code (using COM-interop for all the hairy debugger API glue), is extensible using a neat extension mechanism, scriptable, and will be available as a free download once the Framework v2.0 ships. Note that dbgClr which is a lightweight GUI debugger based off of the Visual Studio code also ships for free alongside the SDK. More information can be found here: http://weblogs.asp.net/andypennell/archive/2005/02/21/377621.aspx. It's future beyond v2.0 of the Framework appears shaky, and there are hints that mdbg and its GUI will supercede it.
Can I Get A TSQL Debugger For The Same Price?
Ah, glad you asked. In fact, a prototype TSQL debugger written purely in managed code is in the works, and we are working to make it available both as a sample for TSQL debugger writers, as well as for the general (developer/dba) public. While it won’t put Visual Studio out of business, it should be handy for most straightforward TSQL connection debugging tasks. Watch this space!