Store project related information in .vs folder to avoid polluting the root of the project
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!
You can find the latest Visual Studio 2015 CTP here: http://www.visualstudio.com/en-us/news/vs2015-vs.aspx
Visual Studio – VS IDE Project and Build Team
Is there any way to get rid of this folder?
I noticed the Additional Include Directories (/I ) is stored in the suo file in vs folder, so I need to commit that to version control to be able to share it. It seems .vs is not recommended to be checkedd in. Is this by design?
Good to have, thank you. A couple of thoughts, though...
It would help if the new location for the .suo file were officially documented. The reference https://msdn.microsoft.com/en-us/library/hx0cxhaw.aspx still places it in the "<ProjName>" directory, while it now actually goes to "<ProjName>\.vs\<ProjName>\v14".
It would also help if there were an official opt-out. As of Update 2, setting
appears to revert to the previous behavior of saving the .suo in the solution directory, yet it would be more reassuring to know that it's a published, supported setting.
is there anyway to completely disable use of the .vs folder? I just had a nightmere trying to rename a folder one of my projects was in. I finally resolved the issue by deleting this folder. I never want that to happen again. Why can't it just read the freaking solution file.. it's a short text file FFS!
I really like the .vs folder for the .suo files, so it doesn't pollute my directories, but can you also make this folder settable, so I can change it's location?
This is probably understood, but this suggestion should be implemented for all *Visual Studio* related files, not all project files. The project files are a build system concern, and shouldn't be in a Visual Studio specific folder, since they're used for many other things besides just development using Visual Studio.
Also this would be the place to allow Local Snippets and Itemtemplates.
@Magnus Mårtensson : There is already a standard for that shared across IDE and text editors: "editor config" based on the file '.editorconfig'. See http://editorconfig.org/
And already a Visual Studio extension
It's a good idea to ask for support out of the box (because it's difficult to ask to developpers to install an extension, especially on opensource projects) but I hope that Microsoft will adopt this standard!
ADMIN: Thank you for listening us.
Moving "bin" and "obj" folders into a separate folder (.build) too would be nice.
Also, I would rename "packages" to ".packages".
So the unified rule will be like that: Only own user source files are placed in directories named with Pascal case. That will make a strict distinction which helps to find needed file quickly (permanent requirement).
Magnus Mårtensson commented
There is one more detail that I'd like to add to this story! It's the fact that there is one setting I can think of, maybe more, which I would love to be able to share as a project policy. The setting I am thinking about is the "use tabs/insert spaces" and "tab indent size". Having different settings within a projects members can cause serious annoyances regarding how code is formatted in the code files. One file with project policy settings should be able to be checked in along with the .sln file to contain, manage and share these settings! Whenever such a file is present those policies would override VisualStudio settings on the individual developers installation. Thanks!
Brian Jimdar commented
Whoa, I just created a project with VS2015 CTP5, and I got a .vs folder next to my solution file. Looks like this is happening!
Good suggestion and good job Microsoft for listening to users. Please, please let's this stick around for RTM.
Also out of votes, but this is a really interesting idea.
This is definitely an excellent idea!
It could enhance the code portability and you could distribute only the source code so much easier!
Florian S. commented
Great idea! Naming it ".vs" is appropriate as per convention, directories starting by a dot are intended for configuration and metadata stuff like that (except for the Windows world, but it's never too late to adopt). Just look at how a Git repository works. Using the dot helps a lot to avoid confusion or name collision with user-made folders, and will keep it at the very top in directory listings.
Dts m commented
This would be super useful.
It would make all the bookkeeping operations on the folder structure much much easier, e.g. backup, ensure clean builds etc.
This should include tfs binding information. Actually, anything that is not "pure code" related should go in there.
Folder with the name starting with a dot is something from a *nix world. Need a better name.
Edward Cooper commented
I'm out of votes but this is probably one of the best, sensible ideas I've seen.
Although I disagree with the idea of storing it in the %APPDATA% folder (See Chad Levy's comment), there could be an option to turn on the feature for those who want it.
The only thing I dislike is having to go through all the "One way Upgrades" that Visual Studio forces upon you again.
Alessio T commented
Great idea! Even if I'm out of votes, this is a virtually ***.
PS: %appdata% is an horrible suggestion.
Dan K commented
Totally great idea. I'd vote for it if I had any left.
Note: I also disagree with putting it under %APPDATA%, for the same reasons @Chad Levy gave.
I like this idea but I'm all out of votes.