Based on the comments at http://blogs.msdn.com/b/visualstudio/archive/2012/02/23/introducing-the-new-developer-experience.aspx?#comments

Here's my UI makeover for VS 2012:

VIEW THE SCREENSHOT MAKEOVER: Attached, or see http://i.imgur.com/Dh0zV.png

Problems I addressed:

1. No more :::::::::::::, and the Toolbar Separators are flatter and lighter.

2. Highly influenced by Zune App UI. Take note of the Min/Max/Close, and the Size Grip, as well as the simple border.

3. Brighter background, minimalist scrollbar, no more reminders of Windows 3.1

4. The ALL CAPS thing is still there, but formatted exactly like in Zune's Metro UI Typographic Style.

5. VS 2012 Icon, Title Bar, and Menu made more consistent with Metro UI's header font, Segoe UI Light.

The debugger in VS is farily decent. However it appears to be lacking one essential feature for debugging Windows applications that are event based. That would be the ability to easily debug the source of messages being posted to a window.

I typically have to resort to Spyxx.exe to view events while I am also debugging in Visual Studio. That is fraught with issues as Spyxx has problems when the debugger is running. Spy can detect an issue with "hooks" that can cause the system to lock up so spy tells me it is refusing to log messages. Sometimes I just have to either exit Visual Studio and start all over as the recommedation from spyxx to restart spy does not always help.

Even with spy, debugging messages posted to a window is almost impossible. Spy can show me the message, but it doesn't show me from where the message is posted. That is frequently the key to debugging an issue in a message based system. And the VS debugger appears to have nothing (that I know of) to help with this difficult issue.

What I would like to see is another breakpoint command. It could be added to the "Breakpoints" window's "New" dropdown. I would love to be able to set a breakpoint whenever, for example, WM_PAINT or WM_SETFOCUS is posted to a particular hWnd. This would give me the ability to quickly and easily determine from where a message is posted.

If anywone knows where this feature is in the debugger, please let me know. If it is not available, this seems like a fundamental feature for debugging a message based application so why hasn't Visual Studio added this ability and more importantly, can it be added in a future version of Visual Studio?

As another suggestion, I think integrating the Spyxx.exe message logging directly into the debugger would really be useful and could avoid the lockup (now potential) issues due to two separate hook based tools trying to hook into a process. Being able to open a debug/messages window for an hWnd would be very useful. And when I right-click on a message I see, having the shortcut menu have "stop logging message", "start logging message", "logging options", ... etc as well as two commands Spyxx's shortcut menu doesn't have, "Break when posted" and "Break when sent" commands would be a great addition to the debugging ability of Visual Studio.

Like many developers we maintain and develop an extremely large enterprise MFC application. All in all about 1.5 million lines. Asides from the addition of ribbons and a few extra controls we have had very little improvements in how we can work with MFC or native Win32 apps (in fact, the speed has gone down and classwizard seems to have gone from bad to worse to gone). Can you consider:

1. Improving the Dialog editor so that we can lay out dialogs with guides and the extra alignment options that are standard with C# - automatically spacing items correctly and so on.
2. Introduce a standardised feature for resizable dialogs, somewhat akin to C#'s docking or attaching.
3. Please, please, please allow us to work on the tabs of a tab control directly. Tab controls are a real pain to work with.
4. Change the class wizard so that a dialog header file doesn't contain its resource ID in the header. Having '#include "resource.h"' in the header of every class is a pain and causes numerous conflicts in applications that have many dialogs.

Essentially I'm asking to have the MFC functionality brought up to line with what we have in Windows Forms. Developers who are still using MFC are almost certainly like us in that they are using it because they have a large enterprise solution to maintain. Such developers are professionals using Visual Studio to build big, serious, expensive applications. Whilst improvements in C#, WinForms, WPF, SL and so on are great, MFC has been woefully neglected for years.

I want my Team Foundation Server instance to be the Symbol Server for the Enterprise. Visual Studio and other debugging clients could then inherently understand when it sees a TFS URL how to locate the symbols or alternately, TFS could provide a URL that exposes symbols correctly (i.e. https://tfs.mycompany.com/tfs/DefaultCollection/Symbols). For those using the Azure-based hosted Team Foundation Service solution, it provides them a publicly-accessible (with authentication) location for Symbol Server as well.

We don't need a file share any longer if you have a TFS server! Symbols could be stored and maintained using the version control system (or some other non-versioned file system exposed & managed by TFS). Automated builds in TFS would understand where to publish the symbols as well. I would almost even say that it's turned on by default and no configuration is required to have that occur.

Visual Studio clients could also be "auto-configured" to add the TFS Server URL automatically to the Options --> Debug --> Symbols --> Symbol Server locations whenever Visual Studio connects to TFS for the first time. Developers shouldn't have to even have an understanding to make this happen and Visual Studio can really just handle this automatically in the background. (However, let the UX handle the security concerns appropriately).

I see this as being the proper foundation in place for truly innovative features in Visual Studio in the future. We have to make it easy though for all development teams to solve this right out of the box though without any thinking or additional configuration.

More details about this scenario and feature request can be found by visiting: http://bit.ly/SymbolServerTFSFeatureRequest

This would be an extension of the Symbol Server and Source Server features that were introduced in TFS 2010. It just takes it that much further! http://bit.ly/SymbolServerTFS

Although, it seems clear that some of the decisions with the "Metro" apps are built so that apps will be able to go between devices, I would like to see the System.Data namespace supported in them. An example, you want to connect to a "local" SQL Express database without having to run a middle tier web-site or application that can talk to the database. Why shouldn't a Metro app run on a desktop be able to connect in the same way that a WinForms app can? The framework was supposed to abstract us from hardware and other changes yet as time goes there become more and more one off's (e.g. Silverlight->WPF->WP7 Silverlight/Metro->W8 Metro).

When a project file is edited on the file system (e.g. source control pull), you'll currently get a prompt: "The project '<name>' has been modified outside the environment"

My options are to not reload, often not being able to compile, or reload the project closing everything I have open...even if it's completely unrelated to the project change (added image files for example). This causes a huge productivity loss on a rapidly iterating project (Stack Overflow in this case), I have to reload the project then spend time opening/searching for whatever I was working on before it happened. In most cases it's more efficient to just close and re-open Visual Studio so what I'm working on (open editors) is preserved.

Can we not get a delta performed here, and just mirror adding/removing the file in our local in-memory project tree when that's what happened? In our use case at least, that's what happens 99% of the time: a file was added, removed, or nested...no other project changes. I understand reloading when the project changes in other ways, but for simple inclusion deltas a reload and the resulting file closure is very aggravating, and a big time sink.