[josteink]

> VS has the best debugger

Not to nitpick or disregard the rest of your comment (VS has a really good debugger), but "best" always required qualifying.

Best in what cases? Best in what way?

There are times when the "best" debugger available without a doubt is WinDbg, with it being archaic, oldfashioned, command-line based, completely un-automated and all that fully accounted for.

Why? Because I can copy the 500KB exe-file into a production environment, run it there and debug issues found nowhere else.

And obviously you're not going to install VS on your production-server, and if you did, those builds are release-builds anyway, without debug-assistance or PDBs, so the VS-debugger would be handicapped anyway.

So yeah. Just a slight nit-pick that "best" always has to be qualified.

[plorkyeran]

VS can debug processes on remote machines with only a small helper process running on that machine, and while you shouldn't deploy PDBs onto your production servers, there's no reason not to generate them for your release builds.

[deng]

http://en.wikipedia.org/wiki/Gdbserver

Visual Studio misses features like Python scripting, which for instance in gdb allows you to define pretty printers for your objects, which is immensely useful for complex data structures. The VS debugger also does not have a proper MI, at least I never heard of one. The only thing I miss from gdb is "edit and continue", which I admit is pretty cool.

[plorkyeran]

You've been able to define custom debug visualizers in VC++ for a very long time, although until 2012 it was basically undocumented. I do prefer gdb's choice of python over VS's custom xml-based stuff for defining them, though -- VS's is slightly easier for the trivial cases, but it's usually the complex cases where custom visualizers are more than just a minor convenience.

[josteink]

> VS can debug processes on remote machines with only a small helper process running on that machine

You first please :)

I've tried doing that several times and always ended up giving up. If it's not firewalling, its UAC or cross domain trust issues, or DCOM configuration, or process permissions and probably 200 other things which has failed on me in the past.

It only works in the most trivial of configurations. Back in the real world I've only been able to use it once or twice, non-repeatably.

[plorkyeran]

I've never had it be particularly difficult. It does generally require a VPN since forwarding DCOM over ssh is challenging.

[MichaelGG]

>while you shouldn't deploy PDBs onto your production servers

Why? I do it all the time and getting line numbers in the exception logging seems like a nice bonus.