Visual Studio

Welcome to the Visual Studio UserVoice site! Let us know what you would like to see in future versions of the Visual Studio suite of products. This site is for suggestions and ideas. If you need to file a bug, visit the Visual Studio Connect site: https://connect.microsoft.com/visualstudio.

We would also like to invite you to check out the Announcements section we have added to this site, where we will be posting special opportunities for you to participate in.

Patterns should be preserved and unmodified when working with *proj files. If I specify a pattern with something like **/*.cs for my code files. If I add a new .cs file that fits that pattern the .csproj file should not be modified.

MSBuild already respects this, but the IDE will always modify the project file.

Hello everyone and thank you for the feedback. We are actively investigating ways to improve how Visual Studio handles project content. This suggestion falls into that category. Unfortunately, we will not be able to address this feedback for the Visual Studio 2015 release. We will update the community when our plans in this area have gained more clarity.

We think this is a fantastic suggestion and have already begun moving project related files into a “.vs” folder at the root of the solution. You can check it out in the latest CTP of Visual Studio 2015. So far, we have moved the .SUO file and the VB/C# compiler IntelliSense database files to the new location. All new project specific, machine local files will be added to the new location too. We plan on taking this even further in future releases and are investigating how to improve the directory structure of build output and other existing files that can clutter the source tree.

If you are upgrading an existing solution you may need to clean up the old files at the root of the solution. We don’t delete them to ensure your settings are not lost if you round trip the project with earlier versions of Visual Studio. Thank you for the suggestion!

We think this is a fantastic suggestion and have already begun moving project related files into a “.vs” folder at the root of the solution. You can check it out in the latest CTP of Visual Studio 2015. So far, we have moved the .SUO file and the VB/C# compiler IntelliSense database files to the new location. All new project specific, machine local files will be added to the new location too. We plan on taking this even further in future releases and are investigating how to improve the directory structure of build output and other existing files that can clutter the source tree.

If you are upgrading an existing solution you may need to clean up the old files at the root of the solution. We don’t delete them to ensure your settings are not lost if you round trip the project with earlier versions of Visual Studio.…

I would like a way where I can change a folder name and optionally filenames: Project -> right click -> rename folder and files... -> give a new name, select folder, output filename or both ->
* Visual Studio updates name of the the solutiondirectory
* Visual Studio updates the solution to point at the new directory
* Visual Studio updates references of other projects to this project to the new directory
* Visual Studio updates the project to reflect the new output file name
* Visual Studio cleans the old files from the output dir if present

Extra brownie points for optionally integrating this in the rename project functionality (update output file name and directory to NEWNAME? <yes> <no>)

Double extra brownie points for a 'search for references to this directory from other tools': text-based search for all files not in obj or bin dirs in all folders under the solution dir that contain the old filename, and ask if the old directory name should be replaced with the new one, or if you want to open the files and edit them manually.

I would like a way where I can change a folder name and optionally filenames: Project -> right click -> rename folder and files... -> give a new name, select folder, output filename or both ->
* Visual Studio updates name of the the solutiondirectory
* Visual Studio updates the solution to point at the new directory
* Visual Studio updates references of other projects to this project to the new directory
* Visual Studio updates the project to reflect the new output file…

As demonstrated at TechEd, ASP.NET vNext projects support a new Nuget mechanism whereby packages are organized in a by-project project.json file. Also of particular interest is the ability to override the package with local sources in a solution file called global.json, which facilitates a much smoother way to contribute to projects outside the solution. Please do this for all project types.

If the project XML file contents were simply ordered, for instance alphabetically like a default file system view, it would drastically reduce the number of merge conflicts that edits cause.

Currently we see items added at the same spot in the file (so there is SOME order happening) with no relation other than time, causing a merge conflict that's completely avoidable. If an order was applied, it would make most 3-way merges automatic and/or a lot less work.

Shared projects are very useful, not only for universal apps development but also to share code between different apps/platforms, for example : Xamarin projects, code sharing between windows 8.1 and windows 10 projects or between to similar apps (6tag and 6sec for example), etc...

But we can perhaps improve it, with a new way to show all files from a project, including files from shared project. See my illustration

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.

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.

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…

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.

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.

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…

Current format of solutions (.sln) files is very complex and is not XML. Current format prevents to make the merge operations and various automation actions. Visual Studio solutions files must be in recognized XML format (like MSBuild files).

The remarkably useless option to run the old version when a build error occurs is the first VS prompt a user sees when there is a build error for the first time after installation. It is annoying especially because it is totally useless but recently I started teaching programming to beginners and this option is a BIG issue. Most people are used to checking the "don't bother me anymore" checkbox and then clicking "yes" on dialogs. You can imagine the mess this causes for a beginner who doesn't even know why his changes (which do not compile) do not affect his program. Finally I have yet to see or hear about someone who wants to run the old build when the new one does not compile. I believe such a person does not exist.

The remarkably useless option to run the old version when a build error occurs is the first VS prompt a user sees when there is a build error for the first time after installation. It is annoying especially because it is totally useless but recently I started teaching programming to beginners and this option is a BIG issue. Most people are used to checking the "don't bother me anymore" checkbox and then clicking "yes" on dialogs. You can imagine the mess this causes for a beginner who doesn't even know why his changes (which do not compile) do not affect…

Add a Start Without Debugging option for individual projects within a solution. This should be located under the Debug context menu item under the project node within Solution Explorer and optionally all debug/run functionality should also be included under the main application's Project menu for easier keyboard access and for consistency.

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 namespace for new files created are automatically determined by the folder structure.
This often creates a problem if you wish to make a logical group of files (by placing them in a folder) that is not supposed to be a new namespace.
Creating the folder and moving the files is not a problem, but the trouble starts as soon as someone uses 'add class' on the folder.
Now the new file does not sit in the same namespace as the other files in the folder.

One example would be to use a folder to store partials of a big class:
[=>Folder root<=]
MyBigClass
[=>MyBigClassPartials<=]
MyBigClass_SetUp
MyBigClass_Update
MyBigClass_OtherStuff

it would be nice if I could assign [=>MyBigClassPartials<=] to the same namespace as the root,
So that new files end up in the correct namespace.

The namespace for new files created are automatically determined by the folder structure.
This often creates a problem if you wish to make a logical group of files (by placing them in a folder) that is not supposed to be a new namespace.
Creating the folder and moving the files is not a problem, but the trouble starts as soon as someone uses 'add class' on the folder.
Now the new file does not sit in the same namespace as the other files in the folder.

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!

Integrate and extend the Project Linker extension to solve the problem of solution with multiple targeting (WPF - Silverlight - WP7 - WinRT...), for example loading only the solution's projects of the target selected, instead of all (in our case we have a solution with more than 140 project).

In Visual Studio 2010, targets files used in the building of a solution are cached by the IDE and there is no obvious way to flush the cache other than restarting Visual Studio as a whole.

This means that if you are customizing your build process in a modular fashion with targets files, you're forced to restart the whole IDE before any changes take effect. This makes using Visual Studio to customize your build process very inefficient and discourages good practice of packaging reusable portions of a build process into targets files.

Please remedy this by either giving us the means to flush the MSBuild cache, or build into Visual Studio something that detects updates to targets files used by the build process and flushes the appropriate cache entries automatically.

In Visual Studio 2010, targets files used in the building of a solution are cached by the IDE and there is no obvious way to flush the cache other than restarting Visual Studio as a whole.

This means that if you are customizing your build process in a modular fashion with targets files, you're forced to restart the whole IDE before any changes take effect. This makes using Visual Studio to customize your build process very inefficient and discourages good practice of packaging reusable portions of a build process into targets files.