I suggest you ...

Stop polluting My Documents with Visual Studio folders

This suggestion is migrated to Developer Community. Please use below link to view the current status.
Visual Studio creates a new folder in My Documents with every version. Over time, if the user requires many different versions of Visual Studio installed, this pollutes the folder. My Documents is supposed to be where I keep, well, my documents.

This even goes again Microsoft's own software design guidelines, if I remember them right.

Most of the subfolders should be moved to the existing AppData Visual Studio folder. The Projects subfolder has no reason to exist, since you might as well default the My Documents folder when creating new projects (the user can obviouly change this at the time, it's just a default location, as with any other app.)

550 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Andrew McDonald shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


We’ve begun work on this and are considering changing the default location for new projects to C:\\USERPROFILE\Source\repos. Would this be a reasonable change to address the problem of “clutter” in the Documents folder? This is currently the default for cloned repositories, so all projects would be in a singular default location.

As well, you still retain the option to change the default if you’d like.

Allison Buchholtz-Au
Program Manager – VS IDE


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Brian Drennan commented  ·   ·  Flag as inappropriate

    I vote for the default for new projects to be under %USERPROFILE%\Source or %USERPROFILE%\Source\Repos by default (but obviously to the user's default folder when set). For settings docs (non-projects, snippets), I like the idea of using the AppData folder. My Documents is the absolute worst when your organization decides to employ folder redirection with OneDrive... Sync errors for days! I wish IISExpress was easier to configure to change this as well (I just gave up).

  • Jan Kučera commented  ·   ·  Flag as inappropriate

    Well in my documents, there are Visual Studio 10/11/14/15/2005/2008/2010/2012/2013/2015/2017 folders and I am happy with that.

    I do keep my "serious" projects in a separate folder and source control backed-up projects on different drive, but the random and ad-hoc projects I keep in the document folders.(And my separate project folder has symlinks to the document folders too.)

    If this is customizable at install time, the documents folder should probably be still default 1) as it is actually the recommended location for user's stuff AFAIK - definitely not AppData as has also been explained below 2) for backwards compatibility reasons.

    But I agree with Patrick and TheLievense that the plurality of mostly empty folders in those VS directories is unnecessary.

  • Del Woodcock commented  ·   ·  Flag as inappropriate

    C:\\USERPROFILE\Source\repos is still not good.
    I put all my stuff in C:\SourceCode on my system. And besides TFS, I back it up to a network share every night.
    What needs to happen is make it an option to locate the folders where ever you want before installation.

  • Anonymous commented  ·   ·  Flag as inappropriate

    %USERPROFILE%\Source is still not the correct location, it's just more clutter!

    Program base installation goes to Program Files
    Per-program data goes to ProgramData
    Per-user data goes to %USERPROFILE%/AppData

    It's not hard, seriously. I uninstall any software that bloats the wrong directory. The worst part is that you guys can't even provide a simple option to move the start page folder, so it's still stuck in our documents.

  • Anonymous commented  ·   ·  Flag as inappropriate

    This is critical - our documents folder is mapped to the network and results in Visual Studio running *horribly* slow.

  • Brian commented  ·   ·  Flag as inappropriate

    Yes, C:\UserProfile\Source\Repos would be an improvement, but even better would be something off the root, i.e. C:\Code. This is what I always do. Inevitably, I am at the command line and don't want to deal with typing spaces. Rationale (1) We're talking about developers who understand the concept of folders and files, not people who need the security of "My Documents" library that masks the real folder. (2) Development tools are installed on the PC and source is in Git/TFS so less concern about backing up stuff out of the documents folder.

  • Fadi R commented  ·   ·  Flag as inappropriate

    That's what VirtualBox is for my friend, keeps Visual Studio from turning your Work Station upside down because polluting your Documents is the least of it's offenses. It's also useful when you want to completely separate environments different editions so that they don't step on each other's toes or even just isolate different projects from each other. I've experienced no performance hits doing this.

  • TJ Horton commented  ·   ·  Flag as inappropriate

    Allow a user to change the parent filler, don't fix it to any location. Also never assume c: drive.

  • Erik Ušaj commented  ·   ·  Flag as inappropriate

    Hi Allison, hi Mark,

    Make sure that setup has an option to define the global folder for VS projects.
    Developer customers should be able to select appropriate global folder for their needs:
    - default (as recomanded by Microsoft, best practices, GPOs, available space, etc.)
    - custom (anything that makes sense to developer; for example external drive on systems with limited primary drive space / limited space on User folders)

    On top of that setup should include steps to define personal and company version control system (git, svn, mercurial, ...) and project locations should be separated for company vs. personal projects. For example my current company requires all personal files are stored in a "\personal" folder on any drive. Company does not have rights to access that folder.

    Setting up a meeting with Windows / Windows Server PMs responsable for Folder Recirection features and associated GPO settings might be also a good idea.
    ( see & read: https://technet.microsoft.com/en-us/library/cc732275(v=ws.11).aspx )
    Discuss possible issued customer can face with poorly congigured GPOs, space limitations on a typical Office knowledge worker space allocation size, etc.

    Best Regards,

  • Michael Richardson commented  ·   ·  Flag as inappropriate

    Allison, I have little opinion about the default because it will only matter to those who don't have their own system (mine is "c:\prj\[client]\[project]" and those people won't have much reason for an opinion. What I do care about is easily being able to select my own choice and it be anywhere I want (allow for junctions for example).

  • Patrick Westerhoff commented  ·   ·  Flag as inappropriate

    I don’t think that the issue is generally with *project* files. I personally like to have my projects inside ~\Documents (although I put them into ~\Documents\Projects).

    I think the issue is more with the other folders that are created, e.g. ArchitectureExplorer, Code Snippets, Settings, Templates, etc. Most of those folders are completely empty! Ignoring the Projects folders, I currently have 2 files and 44 folders spread inside the Visual Studio 2017 folder. That’s ridiculous and mostly unneeded: Those folders should only be created when there’s actually content placed within them.

    And it’s even worse if you have multiple versions of Visual Studio installed. I used to have folders for three versions, all without much in them apart from the projects—which are additionally too spread for things that are not really version dependent after all.

    So generally, project sources might be placed into ~\Documents\, ~\Source (if you insist, although I really dislike that place since the Windows HOME isn’t like a Unix HOME, so stuff there feels a bit wrong to me), or even ~\Documents\Visual Studio projects (to make up something completely new here, which would be version independent too).

    And all those settings and configurations and presets should be stored in %APPDATA%, like sane Windows applications do. Ideally, you should provide a way to back up those settings from within Visual Studio, so you can carry them over to a different machine easily. But those don’t belong into a prominent document location.

  • TheLievense commented  ·   ·  Flag as inappropriate


    That's not enough unless that location is also the location for the following folders which VS clutters My Documents with:

    Architecture Explorer
    Backup Files
    Code Snippets
    Start Pages

    And the bigger issue is that none of those folders should be created (regardless of the default location) until the developer does something that needs to be saved to those folders. For a significant portion of developers those folders just sit empty.

  • Enric commented  ·   ·  Flag as inappropriate

    All the developers I know store their development projects in they own "Projects" folder, each project in a subfolder withing that fodler, but never under My Documents. Therefore, my suggestion is that you ask the user where that "Projects" folder is, and store whatever you need in there, and NEVER EVER under My Documents. At the end, a development project is not a document. Your proposal of asking the user where to locate a folder the first time it is going to be used is fine too, but do not default to My Documents, because that will pollute the folder if the developer is lazy.

  • Lacy Moore commented  ·   ·  Flag as inappropriate

    Almost 6 years later and still a problem. Even moreso since OneDrive for Business can't deal with C#. We'll all be dead and gone before either problem gets resolved.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Apart from chosing the location at first use, there *must* be a possibility to Change it later on. How would I expect some Folder Settings of VS to be a problem without having experienced it before? In our place, MyDocuments is located on the Domain Controller - in a building on the other side of the road, i.e. not in a "real" but only virtual private Network. Now, we want to sync it to OneDrive, but according to other comments below, that may cause other Problems, too...
    (By the way, why does this strange Editor capitalize so many words?)

  • David L commented  ·   ·  Flag as inappropriate


    The proposed solution would be fine if VS ONLY creates the folders as each project type is needed. Currently it creates 8 subfolders, most of which are empty stubs. Some of those folder locations should also not be in the My Documents at all (Settings & Templates should be under AppData/VS/).

    Ideally Visual Studio should just have the ability on first launch to specify the "default project folder" and let the user put it where they want.

  • Blair Wall commented  ·   ·  Flag as inappropriate

    Why not put the VS settings folders under appdata by default.

    The reason why I want this is because I usually rig up my local documents folder to be "sync'd" to OneDrive.

  • James commented  ·   ·  Flag as inappropriate

    Is this never going to be fixed? I do not want my 'My Documents' folder to be cluttered with rubbish as it is backed up, and I do not want rubbish programs to fill it with rubbish.

    As you can probably tell I am not particularly happy about this practice.

    I have been through and deleted\edited everything, in VS and in the registry. Still I get a folder full of rubbish I do not want. To some extent OK, by default it is not right but at least I can change it, bbut if editing the registry is no good then why? It is obviously hardcoded in the source to use %USERPROFILE%.

    And on another note, this text box just adds a scrollbar to the side, but I cannot expand it so I am stuck with 5 lines of text to view at a time. Is this done to intentionally infuriate users who are already here because they are here to complain anyway? If so, it works, I am at pretty much 90 something % anger level.

Feedback and Knowledge Base