Comment Feed for Visual Studio Debugger Tips & Tricks (pdc2008 on Channel 9)

Re: Visual Studio Debugger Tips & Tricks

anisacikal — Sun, 08 Nov 2009 04:02:53 GMT

Wow, i really enjoy the discussion. It gives me so much idea.

Oes Tsetnoc Oes Tsetnoc Oes Tsetnoc Oes Tsetnoc Oes Tsetnoc Oes Tsetnoc Kerja Keras Adalah Energi Kita

Re: Visual Studio Debugger Tips & Tricks

iolanda256gmail — Tue, 20 Oct 2009 06:05:59 GMT

Yet cannot tiffany sale,Be together,The furthest distance in the worldbreitling

replica watch

Re: Re: Visual Studio Debugger Tips & Tricks

Steven Behnke — Wed, 17 Dec 2008 22:22:13 GMT

This certainly won't work for all instances but for a List you could instead use the System.Collection.ObjectModel.Collection<T>. This has events you can subscribe to when you add and remove items to the collection and it would provide you what you were looking for in this particular instance.

Re: Visual Studio Debugger Tips & Tricks

Ralph Trickey — Sun, 07 Dec 2008 22:38:42 GMT

John,
I enjoyed the talk, but I also wished you'd been able to get it in. I'm a native programmer switching to .Net.

I'm not sure why they'd be any more 'weird' in .Net than they are under Native.

As a games programmer, I've had several problems that I've had to troubleshoot in release mode because it takes too long to run things in debug mode. I assume that for .Net, I'd have to attach to the process after it starts to avoid running a debug build. I assume that a release build would inline the accessor, to the only optins available are hardware breakpoints and print statements :(

I've found them fantastically useful in debugging things like buffer overruns in native code. Even though that class of bugs isn't supposed to be there, I suspect that there is a new class of bugs related to multi-threading that are coming at us. Data breakpoints seem like an obvious way (to me) to troubleshoot these types of issues.

Ralph

Re: Visual Studio Debugger Tips & Tricks

JoC — Fri, 07 Nov 2008 23:27:52 GMT

I hear you. I've wanted to build since V1 of the CLR. We actually put a lot of effort into trying to build that feature for VS2010, but alas we couldn't come up with a good way to make it work. Fundamentally, we are constrained by what the hardware will give us here (4 slots in the DR registers) to watch memory writes (and technically reads and executes). Every time we tried to figure out "how would we provide an experience that people wouldn't find just weird", we came up short.

You can use a conditional breakpoint and use an expression with "has changed", but it is not nearly as performant as a databp, and it is not the same thing (the DRs fire no matter if you are writing the same value back).

Anyway - hope you enjoyed the talk,

John

Re: Visual Studio Debugger Tips & Tricks

hillr — Sun, 02 Nov 2008 00:56:19 GMT

Data breakpoints is something I definitely miss. Where you have properties in your own code it is easy enough to set a breakpoint in a setter. But where the code isn't your own (think slot in an array or entry in a List<T>), it sure would be nice to be able to set a breakpoint on write.