Ideally, just exactly like the Undo Close in PowerCommands (http://visualstudiogallery.msdn.microsoft.com/e5f41ad9-4edc-4912-bca3-91147db95b99).

How it works:
- You work on files, open and close move around the text buffer, jump to definitions and references, etc.
- As you do all that, a toolwinow "Undo Close" is populated automatically with a list of those recentely opened files, with information about the location of the cursor when it was closed
- Upon double-clicking a file there, automatically opens it on the cursor location where it was when closed.
- Some shortcut can automatically UndoClose of the first item in that "stack", poping it. So you can automatically go back to recently opened files by repeatedly pressing the shortcut.

Just like you do on Firefox :). Best of all, this has already been implemented and is MS IP :). ~360k downloads agree it may be a good idea...

It would be nice if there was a service that would roll up the work remaining of all child (and grandchild) PBI's and tasks to the parent PBI. We wrote a custom service to do this but it would be nice if this was included functionality. It helps greatly when ranking the tasks, deciding what to cut from a sprint/project and giving visibility to the true work remaining vs the initial story point estimate.

So if a PBI doesn't have any child PBI's or child tasks then it would just use the story point estimate for the work remaining (or multiple it times some factor ie 8 for an ideal man day, whatever units you decide to use.) If it did have child tasks it would used the work remaining.

When we add an InstallShield Limited Edition setup project in a solution, Visual Studio will often stop responding and become much more slower.

And by the way, if such a project is loaded when we open a solution, Visual Studio will crash thus we have to rename the folder so that next time we start Visual Studio the project won't be load automatically (and then load it manually).

And since Visual Studio stop responding much more often when we have such project in a solution, we have to restart Visual Studio much more often (and have to do the manual step to avoid a crash on opening as it look like InstallShield try to uses other projects before they are loaded)

When such a project is loaded, part of Visual Studio often stop responding. In particular, solution explorer and editors are much affected to the point were it almost unusable.

Before I had such project to my solution, I never have such a degradation of performance.

I have two projects. There is a run-time dependency between the two of them, but not a compile time dependency. (This is commonly done in modular programming.)

To run, it is easiest if the dlls for the projects are in the same folder.

It is easy to just add a reference to make the output of the projects copy to the same folder.

But that adds a compile time dependency. (And makes it all too tempting for other coders to add design time coupling between my two projects.)

So, I need a way to add a reference that is only as a build task.

You can hack around this with Post Build Events and MS Build tasks. But It would be nice if this had first class support in the IDE. (Like "References" does.)

I notice that each release of VS since .NET seems to provide its own suite of UI - all a little different from the Windows built-in widgets which makes it look a little unprofessional. I'm not talking about the bits which obviously need to be made, the fancy tree views and such (particularly since the Windows native tree view is a pain in the *** to work with), but the absolute basics like check boxes and command buttons - we don't /need/ new ones.

Normally I'm not that bothered, although it would be nice to have had the developer time spent on actual features instead of eye-candy - maybe the current version would be faster, more stable and more fully featured... (I doubt a single copy of VS sells on appearance somehow.)

This time around however the UI is a definite step backwards. The all caps are deeply annoying and shoddy looking - if its an option I don't want to even have to find it - the sensible default should be used.

Removing the colour from icons removes a visual cue which helps usability (although that seems to be common in Windows 8 overall - removing visual cues).

I think there is a good idea behind a lot of this - reducing complexity for the user, just that it has been taken too far, and ignoring common sense. Not having visual cues is not a good thing - visual cues like having "Help" written somewhere on the screen are exactly how we can learn to use a new OS quickly without instructions. Windows 8 requires instructions to use it, something I did not even need for Windows 3.1 the first time I ever used a computer. This is a definite regression, and I hope the approach doesn't spread further... particularly to a developer tool like VS which should be catering to power users in particular.

As of now, VS filter item types which can be added to a certain kind of project. For example, right-clicking the winforms exe project brings a menu with "Form", "User Control" and such. For WPF exe there will be "Resource Dictionary" and "Window". And similar filtering applies to "Add new item" dialog. Unfortunately, this mechanism often fails. Sometimes I am not able to add a ResourceDictionary to WPF project, for example.

So my suggestion is: please keep filtering the context menu and remove filtering from dialog. Blame the responsibility for adding certain item on programmer. First of all, he is smart enough not to add, say, ".h" file to WPF project. On the other hand, what if he is creating mixed WinForms-WPF project? He must be able to add both types of "user controls", windows and other stuff.