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 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!
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.
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.
Chad Levy commented
@David Karlaš: "Or even better store inside %APPDATA%..." I disagree. Doing so ruins the portability of a solution outside of src control. I'm sure I'm not alone in using multiple machines with dropbox/box/bittorrent sync for dev. Having to dig around appdata and trying to sync between machines sounds unnecessarily painful.
Basarat Ali commented
This would be consistent with what IntelliJ IDEA (and family : webstorm, pycharm, rubymine etc) does. It stores its settings in `.idea` folder. Makes it easy to .gitignore
Shawn Mehaffie commented
This is a great idea and the cleaner we can make the project folder the better off we will be.
Nice... and it would "blend in" with .git... Also, the upgrade file / folders should be placed there as well (anything IDE related). If this catches on then maybe Resharper would put its files under .vs/Resharper or maybe .resharper...