-
Notifications
You must be signed in to change notification settings - Fork 29.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When in Windows, do as Windows does aka store settings/extensions in %APPDATA% or %LOCALAPPDATA% #7035
Comments
Related to #5570; we are consolidating the multiple config directories soon. We might want to reconsider the space in the migration too. |
Totally agree. We need an owner for this story that just implements it right for all platforms. Not only implements the change but migration as well.
|
Note that %APPDATA% on Windows seems to be the "Roaming" folder, so you potentially end up roaming extensions and settings around. |
Extensions should go with |
@rebornix why would we separate them? Is it bad to roam things potentially as big as extensions or something? |
@Tyriar yes it's not a good idea to roam big data, per TechNet's documentation about app data roaming https://technet.microsoft.com/en-us/library/cc766489(v=ws.10).aspx , data (or data change) larger than 20 megabytes or more might cause delays in user logons. Windows Application guideline also suggests not to roam large set of data, https://msdn.microsoft.com/en-us/library/windows/apps/hh465094.aspx . Of course, our app is not a Windows Application, but I think they share the same design principal. So the last question is, are our extensions data too large? IMHO, they are sometimes too large and our extension development toolchain leads to this situation. When we package our extension into vsix, we don't have a good way to separate source code files and other dependencies (like test files, dev dependencies, node_modules), we always put a bunch of unused files in the extension vsix package. Take Go extension for example The test folder is not necessary, most files from node_module packages are not necessary either. But our current toolchain can't help people easily avoid this kind of file duplication, which finally makes extension packages too large. |
So something like |
@Tyriar yup it's the expected behavior the system will do. The extension json file is synced by the system automatically so I suggest we detect its change and the real extension list and notify users about the change, let them decide whether to sync the extensions on the new machine. |
@Zoltu Wow, finally someone who also embraces Windows' program storage conventions. One question though, what is the exact difference between |
@felixfbecker |
Steps to Reproduce:
.vscode
folder in your user directory.In Windows, the root of the user directory is NOT the right place to store application settings. This is a very common convention in Linux but Windows != Linux and not all Windows users want to pretend they are running Linux. In windows the correct location for application settings is
%APPDATA%
and the correct location for extensions is%LOCALAPPDATA%
or%PROGRAMDATA%
(depending on level of security consciousness).To avoid a flame war, I want to be clear that this issue isn't debating why
C:/Users/<username>/.<appname>
is the wrong place for these files, it is only asserting that Microsoft has very clearly documented the right place for settings files and VSCode does not follow it. If the authors of VSCode have consciously decided to go against the long-running convention established by the OS authors then I won't press on the issue (though I think that would be a silly decision for VSCode). I am submitting this issue under the assumption that the authors didn't realize there was an established convention (very common in open source projects) and did what was familiar to them.The text was updated successfully, but these errors were encountered: