Informal poll on debugger feature requests?
What new feature requests do you want in the managed debugging services? In other words, if you could spend $100 on the following debugger-related items, how would it break down:
1) Support for debugging a managed dump file (without needing SOS)
2) Data breakpoints on managed objects.
3) Better managed (C#) wrappers for everything.
4) Making MDbg the worlds' best sample. Fixing all the warts, making perfectly clean, documented, ideal code, fxcop clean, etc.
5) Ability to write a profiler in managed code. (This is basically impossible; but I'm curious how much people would like it)
6) More Edit-and-Continue support. If you've used EnC, you've probably noticed there are a set of "rude edits" where you need to restart. This items is reducing the set of rude edits. For example, letting you add a new class with EnC.
7) Better documentation on ICorDebug and related APIs.
8) More scriptable debugger. For example, being able to put IronPython statements behind breakpoints
9) Better visualizers
10) Being able to debug light-weight codegen.
11) Improving warts on the ICorDebug API itself.
12) debugging optimized managed code.
13) other debugging features?
I'd also be interested in what your technical scenarios are so I can look for patterns between feature requests and users.
I realize that this is focused on a very small subset of the overall Visual Studio feature set. For example, I intentionally avoided listed IDE features.
I need to emphasize this is an informal poll for my own curiosity only. I'm not making any promises on behalf of Microsoft.
Comments
- Anonymous
October 11, 2005
#1 : $50
#3 : $3
#4 : $20
#7 : $10
#11: $7
#12: $10
I wish I had more to spend, Basically #1 & #12 are very important for me, as it'll allow us to debug dumps from production environments.
#3 - Better C# wrapper will encourage people to write tools around Mdbg API
#4 - I love Mdbg, more liberal licensing would help!!!
#5 - it'll be fun. - Anonymous
October 11, 2005
Being able to debug as fast as VB6 would be good. VB6 had the advantage of running the debugger in-process, so no overhead of starting up a new process and then attaching to it.
Couldn't that be done with a good class unloader, and some appdomain magic? - Anonymous
October 11, 2005
#12: $55
#10: $30
#4: $15 - this is nearly the same but better than #7.
#2: $10
Other things:
Less interference with WinForms when debugging: i.e. don't install a new window procedure etc.
For example, if an unhandled exception in an event occurs but is handled in Application.ThreadException, the behaviour is different whether or not you're running in the debugger: the debugger causes the application to terminate, while outside the debugger the application can continue (feedback item FDBK27500).
Another thing: LWCG has almost no verification. But that's not debug related. - Anonymous
October 11, 2005
$40
3) Better managed (C#) wrappers for everything
$30
4) Making MDbg the worlds' best sample
$20
6) More Edit-and-Continue support
$10
7) Better documentation on ICorDebug - Anonymous
October 11, 2005
- $50
13. $50
The killer feature for me would be integration with a decompiler tool like .NET Reflector. It would be awesome if you could step through code without having source code. There should be a window that tracks the decompiled source for the method you are in. The local variables window should track state for the decompiled method. Along these lines, debugging at the IL level may also be viable, depending on how hard it is to do the full decompiled source implementation.
- Anonymous
October 12, 2005
barrkel - you spent $110. :)
All - make your friends come back and fill this out too. I want more data to look at.
I'll go over the specific comments in a little bit. - Anonymous
October 12, 2005
1 - $30
8 - $10
12 - $60
What I really want is better live and postmortem debugging of managed code using the windows debuggers (ie, a better SOS). It would be great to get some source-level debugging of release code, though. - Anonymous
October 12, 2005
All $100 on #6 (E&C) - especially for ASP.NET!!!! - Anonymous
October 12, 2005
- $20
3) $10
5) $50 (C# has made me lazy hehe)
7) $20
I agree with Brien about an in-built reflector - or alternatively just put the source for the .NET Framework up on your symbol server :) I'd spend all $100 on that if I could (and it would still be a bargain).
- Anonymous
October 12, 2005
FWIW, As a pet project, I've wanted to merge reflector (a decompiler) into the MDBg gui for a while. The problem was that 1) reflector didn't have enough information in it, and 2) I haven't had time. I think it would be a very cool thing to do.
The point is there's nothing stopping any of you from doing this as your own pet project :)
Maybe if I add IL-debugging support to the MDbg gui, somebody will pick up the torch and add a decompiler. - Anonymous
October 13, 2005
That one not in the list, but... local variable names, and msil-source mapping in metadata. But may be you already asked concerned peoples. :)
I am willing to pay 200$ for that. - Anonymous
October 13, 2005
- $30
9) $10
$50 - a completely xcopy deployable, no-install debugger. And a related item, a no-install remote debug server - something we can have our customers or QA department to run and we attach to remotely to debug code with no install impact on the remote system.
$10 - better support for debugging generated code, like XmlSerializer assemblies.
- Anonymous
October 14, 2005
I would like to be able to programmatically create a dump file from within a managed application i.e. from an unhandled exception handler. - Anonymous
October 14, 2005
The comment has been removed - Anonymous
October 17, 2005
Er..OK, completely xcopy deployable no-install GUI debugger, to be more specific ;) Something akin to dbgclr, but requiring no install. I can't stress enough how valuable this would be.
The scenario for "generated code" I was thinking of specifically was XmlSerializer assemblies. Numerous times I've had problems with XML serialization (including finding bugs in the framework), and I've had to resort to the config file "leave the temp files after compile" trick to debug the code. In all fairness this isn't really a debugger thing - it's more about how the framework generates it's code. It's just not a very seamless debugging experience. Honestly, I haven't given much thought to how I would prefer it to work - it's just a general "less painful" request.
BTW, +1 on the integrated decompiler idea. That would be fantastic. - Anonymous
October 18, 2005
- $20
4) $40
7) $10
12) $30
- Anonymous
October 18, 2005
My #1 request is better support for mixed (managed/unmanaged) debugging. When both debuggers are used, things slow to a crawl, especially if the app is writing alot of output to the Debug Output window.
Yeah, it's better in VS2005, but it's still too slow. - Anonymous
October 18, 2005
The comment has been removed - Anonymous
October 21, 2005
The comment has been removed - Anonymous
October 25, 2005
Kevin,
You can do this with the VS 2005 remote debugger (msvsmon.exe).
Gregg Miskelly - Anonymous
October 27, 2005
- $45
3) $35
6) $15
- Anonymous
October 29, 2005
- $35
2. $30
3. $25
7. $10
- Anonymous
November 01, 2005
- Support for debugging a managed dump file (without needing SOS)
$10
2) Data breakpoints on managed objects.
$30
3) Better managed (C#) wrappers for everything.
$20
4) Making MDbg the worlds' best sample. Fixing all the warts, making perfectly clean, documented, ideal code, fxcop clean, etc.
0$
5) Ability to write a profiler in managed code. (This is basically impossible; but I'm curious how much people would like it)
5$
6) More Edit-and-Continue support.
0$ -> I must write a test before the code thereforee Edit-and-Continue has no value
7) Better documentation on ICorDebug and related APIs.
0$
8) More scriptable debugger. For example, being able to put IronPython statements behind breakpoints
10$
9) Better visualizers
10$
10) Being able to debug light-weight codegen.
10$
11) Improving warts on the ICorDebug API itself.
0$
12) debugging optimized managed code.
5$
13) other debugging features?