Full IntelliTrace support for WF

This would make a huge step forward in the experience of dump analysis in VS.
Moreover, I don't understand the technical need in the first place.

When Double-clicking an existing Stored Procedure in SQL Server Object Explorer, the Stored procedure appears in the Editor as a CREATE procedure. This means if you change the Stored Procedure, you cannot click Save on the Toolbar. It would be good if Visual Studio 11 was changed so Double-clicking a Stored Procedure produced an ALTER procedure.

Make Visual Studio add ",", ")", "}" and ">" if missing. And make VS automaticly give comments on how to solve easy mistakes.

If I could see all the values that the variable has changed to, then connect that back to the stack, that would be superb.

These are available via x86 debug registers. I suspect these were never exposed out of wanting to conform to Alpha, or other legacy architectures.
It would be *very* useful during debugging to be able to say where is a value used, and not just set.

It would be really nice if we had some way to hide specified functions in Visual Studio's call stack pane.

For example, when I'm debugging multi-threaded C++ code using std::function and a work pool, I often have to sort through 15+ library functions that I don't care about in order to find my code.

It would be really helpful if I could hide them. As an extension to this, it would be even better if I could collapse a series of functions into some label describing what they're doing, like 'Asynchronous Call.'

There is an unsupported mechanism to list functions that we wish to avoid stepping into while debugging. It was first revealed in Andy Pennell's blog: http://blogs.msdn.com/b/andypennell/archive/2004/02/06/69004.aspx.
*This can be a major, MAJOR, productivity enhancer.*

I suggest:
(a) Fix it, (it's broken at least for the very common scenario of several IDEs: http://thetweaker.wordpress.com/2011/11/26/stepover-revisited/)
(b) Expose it via some UI.
(c) Support (i.e. test & document) it.

When working with large project it will be helpful if a breakpoint can be placed in a 'file' instead of a 'function' to check if any of the functions in that file is hit.

While on debugging in Add watch, or Quick watch. if we drag ang drop a big class object, it is difficult to find a particular attribute.
it will be really good if we can search on that object.
Say class object is having big hierarchy. If we can search on that object, it will be really nice.
or
And there should be option to export this currently selected class object(Full hierarchy with values) to a txt file.

The VS 2010 debugger's Auto window is only looking "forward" when it is anticipating what to display.

It only displays the most recent assignment when this assignment is used within the next two or three statements to execute.

It would be quite useful to ALWAYS have the most recent assigned value displayed in the Auto window. Because THAT's most often the values you want to audit.

Often during debugging you come across a symbol and you like to see what's located there. Its opposite of finding an address of a symbol in Memory window.

It would great to be able step into and watch/lookup variables in a complex C/C++ macro. Maybe display the variables used in the Locals window? Or somehow allow users to figure out what the expression actually is/does.

In http://msdn.microsoft.com/en-us/library/a329t4ed%28v=vs.100%29.aspx#CommunityContent you have a description about attaching automaticaly to an .exe application. Is the same also possible for a DLL?

This would be a nice to have!

When stepping through code in the Disassembly window, the "Auto" variable tab shows "interesting" processor registers. It would be good if that list included the status flags in order to be able to predict conditional instructions more easily.

While debugging an application, I would like to have several set of debug parameters (Command Arguments, Working Directories, etc). Currently, these parameters are on a per configuration basis. I think this should be decoupled from project configurations. Most of the time, I set parameters in the Debug configuration. When I start the application after a Release build, it launches without command arguments and I have to go back and copy my Debug parameters...

Currently you can configure which project(s) need to be started on F5 (start debugging).

It would be nice to be able to configure how many instances of a project need to be started. E.g. 2 producers and 3 consumers.

Symbol files are reloaded each time a dubugging session is started, even if most assemblies have ont changed.
Use a cache (like the intellisense cache) to sppeed this up and reduce Debug starting time.
Or load asynchronously/on demand as in WinDbg

When vshost.exe is generated by the Visual Studio, it could maybe apply some of the application settings, like the main app's icon. This way annoying things like this (http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/8aa4f8b5-b053-4bdf-a5cf-0c4cdddb65b6) would be solved, and no workaround (http://msdn.microsoft.com/en-us/library/bb514517%28v=VS.90%29.aspx) would be needed. Maybe this is not hard to fix stuff, and maybe it'd help with other issues besides the icon.
I wasn't which is the best fit category for this suggestion.