[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.