The 260 character limit on file paths really gets in the way of having a deeply-nested project hierarchy. It's only there as backwards compatibility with the old school APIs, and has no place in any sort of modern development environment.

We should be able to work with file paths of whatever size we want.

Accidentally moving files to random directory really annoys.

When creating a work item query, you are given the option to select the iteration path for which the query is to return results for. It will be fantastic if a token was provided such as [Active Iteration] and you can specify the active iteration manually, or TFS calculating it via the Start/End dates

If you work with DVCS like Git or Mercurial you always switch back and forth between branches. This always cause Visual Studio to reload projects even if they were not changed. Even if project is changed, it should not be that long. And of course it should not ask to reload each project.

I've only spent 5mins in VS11 so far, but it seems like Website Application projects addon from (2005/2008/2010 has been integrated). However Website Deployment projects don't seem to be. It would be nice for these to finally get some official attention.

For any non-trivial solution, I will have multiple projects. Typically, since I try to write loosely coupled, testable, code, I have projects like:
Core
Infrastructure
UnitTests
UI

For a given platform, say ASPNET MVC, I would like to define a standard solution template that includes the projects. Ideally it would also be easy to customize the template so that the individual projects have certain nuget projects in them (e.g. nunit/xunit), but that can probably already be done separately from this feature.

I would like to use C# or VB.NET along side F# within the same project without being forced to place that code in it's own project. The language of each code file would be determined by it's file extension as it is now. They all compile to IL, so it shouldn't be a problem to link them all together into one DLL.

For backwards compatibility with existing .csproj, .vbproj and .fsproj files, there would probably need to be a new project format -- something like .netproj that would support multiple language code files.

The solution (.sln) properties allows bulk update of Configuration and Platform properties. It should also allow updating the TargetFramework property.

This works already for project references but not file references. Reference debug locations in debug build, release locations in release build.

enable developers to create Subfolder-Structures within BIDS SSRS Projects. Currently with VS2008 BIDS it is not possible to organize reports with folders in Visual studio. If you have SSRS projects with many reports, and you want to deploy reports to different subfolders on ssrs server this would be really helpful!

.NET claims support for .netmodule, but it's support is abysmal. VS doesn't let you switch to them, and when you do it manually project references fail to resolve. MSBuild doesn't support project references to them either. Even after all that is worked around, Csc.exe itself fails to find extension methods in .netmodules.

When removing a project which is referenced as a project reference by other projects in the solution, these project references are deleted. This is unfortunate since the same projects may appear in other solutions, and their compilation would break in those solutions. I suggest these references are kept, and have a warning associated with them (the black/yellow exclamation mark)

Nowadays developers of .net have to release 2 versions of software that imports some calls of dlls
- x86 (where all projects targets x86 CPU, otherwise it will not work on x64)
- x64

Could you make possible to use x64 and x86 libraries with Any CPU and let the platform to choose which to load ?

When working on large software projects with loads of c# projects in one solution we ended up creating multiple solution sets (one full version, one focusing on tests, one for installers...) in order to keep edit & load performance acceptable.
These solutions with redundant projects configurations become incompatible over time (when projects and references change) and it gets hard and unhandy to keep them in sync.
It would be nice to be able to build up meta solutions linking partial solutions (or project collections) to improve the projects management experience.

Since many of us using Office 365, it is good idea to integrate with O 365 users to TFS.

When I try to assign the user to the project I found that only live id user can be assigned.

This cannot happen in the corporate level, since they should use only corporate email ids.

Please validate this request and make it available to use TFS asap.

When multiple projects change on disk (because of a source control fetch, usually), you generally want to reload the solution rather than responding to multiple "reload project" dialogs.