I would like to be able to 'decode' the meaning of the icons which appear all over Solution Explorer and Object Browser and the Intellisense lists. I think I have once found this somewhere on the net but not in the help, and printed it out. Ideally, I would like to have it accessible as a floating window. This is a 'novice' feature I know. I have been using Studio for 3 years full-time now, and have learnt (in effect) that I will never work out what they mean. This is probably a bad lesson. I think I can recognise the symbols for class and event, and that's about it. From time to time, not knowing the difference really contributes to confusion, especially in class libraries I am unfamiliar with.

Almost daily I try to check in some pending changes. I enter a comment, because it is required by our TFS server. I might spend 2 or 3 minutes writing a very detailed comment describing all of the changes and why I am making them. When I press "Check In" I get a dialog stating that there are conflicts. I resolve the conflicts and now what... Nothing. I have to press "check in pending changes" again. My comment is lost. I have to write it over again. Another 3 minutes re-writing the comment and some frustration go by, then I click "Check In" again. Shew! No problems.

Many IDEs for Subversion and CVS save our comments to a local cache so that they can be reused, especially in cases like this. In other cases I need to use the same comment for multiple check-ins. There is usually a select box listing the previous comments. I select a previous comment and the text area is populated with the previous text. From there I can modify the text area and then press "Check In".

This would be a great feature I think.

When a solution has some C++ and some C# projects, it cause all sort of trouble with references or designer.

As an example if a C# DLL is used by a C++/CLI which is in turn used by another C# project (that has a reference to both of them since it uses item defined in C# DLL), then there would be a lot of problem caused by references.

A common problem is that the WinForms designer will often complain that the C++ DLL from which it uses some class cannot be loaded (even though it is compiled and up-to-date). This is very annoying as it won't always get fixed by recompiling the solution.

When compiling and linking we can sometimes see errors or warning caused by wrong reference. Why the IDE is not able to properly setup reference, intermediate paths and all that stuff so that it properly works 100% of the time?

By the way when such errors occurs we don't have much information to understand why it does happens. It look like a problem that version does not match but why.

In my case, there are also another C++/CLI project under the above C# project and then the application executable which is a C# project.

And speaking of projects, it should also be easy to create a project that would have some part compiled native in both 32 and 64 bits and some to IL and have a setup that would allows to select if we want to install the 32 or 64 bits application if the OS support both (and by the way if the 32 bit application is installed in such case, it should be marked as such if the application itself is managed).

References to C++ code is also a problem for Intellisence (and maybe for test projects... I haven't done them recently).

By the way, it also seems that in some situation it is impossible to add a reference to a C++/CLI project compiled in VS 11 Beta using Visual Studio 2010 toolset.

References should works properly whatever toolset we chose to use and if some configuration use one toolset (or some specific options for CLR), everything should works properly anyway.

Fix the problem that cause DLL to be sometime locked under VS 11 Beta. It often display that 10 retries were done but why the DLL is locked in the first place.
When this occurs, we might have to close and restart Visual Studio or worst have to close the session or computer.

When this problem occurs, we cannot clean the project neither delete the DLL from Windows Explorer. I'm not sure if the DLL will eventually be unlocked if I wait enough... but if it is the case the delay is far too long anyway.

And you'd like to know, my Antivirus is MSE so I expect that is is not the problem since it is from Microsoft.

By the way, if it does occurs, it might be a good idea to create and use a temporary DLL (and fixes references) so that we won't lost too much time because someone does not properly close the file (maybe the debugger).