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.

Every single time I add a project to a solution, Visual Studio "helpfully" adds to the solution every configuration it finds in the project.

Every single time the project has a platform that the solution doesn't, Visual Studio "helpfully" creates the missing solution platform and also, most annoyingly, "Mixed Platforms".

PLEASE leave them alone. I set them up how I like and I'd like them to stay that way.

Example use case #2:

I create a new project (defaults to x86) and add a Util library (AnyCPU). Wham, I'm only 5 seconds into a new project and I already have to clean up "AnyCPU" and "Mixed Platforms" from my solution platforms.

Example use case #1:

A library project has four configurations: Debug, Release, DebugWithFeatureX, ReleaseWithFeatureX. I add this to a project that has existed for years. The configurations "*WithFeatureX" only make sense for the library; the project is supposed to choose one of them and stick with it.

Instead, the users of the library are forced to clean up these never-watned configurations.

Some errors in the error list could be automatically fixed. For instance, you build your code and the error "The type 'bla' is not referenced. You must add a reference to assembly 'System.Data.Entity'" appears in the error pane. This error is easily fixed by adding the correct reference to the project, but since Studio already knows what it's looking for, it knows where it's located (GAC), why isn't there an option to fix it?

It would be nice if the error pane would have a column "Autoresolve" with for each error which migh be fixable a link "Try resolving". Studio would then try to autoresolve the problem, for instance by adding the correct reference to the project and all would be well. If there was a problem resolving the problem, Studio could display an error message telling the user the autofix didn't work and he should correct the problem himself.

In the same category, auto fixes could be applied for things like missing/extra parentheses, ; characters, etc. etc. I think the list of autoresolvable things is actually pretty long.

But please note: VS should NEVER do this on it's own. It should always be the developers action to perform an autoresolve.

please fix this dialog. it hasn't changed for years, it desparately needs some attention.

consider this use case:
- i'm editing some code and part of it is red. i want to change it to blue.
- i open the fonts & colors dialog
- i scroll through the HUGE, completely disorganized 'display items' list
- i have to guess which of those items applies to the red text I want to change. sometimes it's obvious, most of the time it's not...
- usually, i have to select each item in that list, one-by-one, looking for one that's the right color
- in order to see if it's the correct item, i have to change the color of the item, dismiss the dialog (there's no 'Apply' button)
- if that wasn't the correct item, then I have to re-open the dialog, return to the incorrect item, change it's color back to what it was before, then continue on looking for the next red item.

how about this:
- organize the 'display items' list somehow
- make the dialog expandable (2011, anyone?), or at least make the display items listbox taller (do you really need all that space for the font & size controls?)
- allow the user to filter the display items by:
- items usable by the file in the active editor
- items in use in the active editor
- items in use in the active editor's selection
- add right-click menu to open dialog with filter applied based on current selection

then I could just select the red text, right-click -> 'edit colors' and be right there...