Be a good citizen on Windows (don't dump config into %USERPROFILE%).

[MicahZoltu]

On Windows, applications should not be creating folders/files directly in %USERPROFILE%. The proper location for configuration files is %APPDATA%\<vendor>\<product> and the proper location for cache files is %LOCALAPPDATA%\<vendor>\<product>. Things should only be added to %USERPROFILE% if the user explicitly requests it via a save dialog box.

Please move %USERPROFILE%\.omnisharp to %APPDATA%\omnisharp as the default location. Also please provide an environment variable override as a temporary mitigation to this problem until a full migration can be completed (I recognize that changing storage locations can be a long process).

In the discussion that lead to this change this comment was made: #809 (comment)

No idea. On my machine, I see the following under USERPROFILE:
.dnx
.node-gyp
.nuget
.templateengine
.vscode
.vscode-insiders
.vscode-oss-dev
I think we're in good company in picking USERPROFILE.

Unfortunately, this was just a pointer to how other people were peeing in the pool so omnisharp should join the party. Also, I believe all of the above have since been fixed or are in the process of being fixed (working towards a long-term migration strategy) to follow Windows best practices. The fact that configuration files should go in %APPDATA% is well documented in Microsoft's OS documentation in a number of places as well as MSDN. Unfortunately, a lot of people are coming from Linux where $HOME is a dumping ground for whatever data any application wants to add, since prior to XDG, linux didn't really have a story for where files should go (this has since been resolved though most apps haven't caught up yet).

Also, in Windows folders should not be named with a . prefix as Windows explorer doesn't allow creation of folders with that name which leads to problems.

[DustinCampbell]

Related: microsoft/vscode#17691

[MicahZoltu]

Also related: microsoft/vscode#3884

[david-driscoll]

I don't have any strong feelings keeping it in user profile, we just did because it was all there already. @DustinCampbell @filipw ?

[filipw]

I have no problem moving this to %APPDATA%. While many other tools still don't allow overriding the path (i.e. yarn) I think we can definitely add something like OMNISHARP_HOME env variable where you can provide your own custom path.

All that said, please note that OmniSharp is only saving a single JSON file there, so the overall impact on things like domain server sync and so on is pretty much non-existent (especially compared to other tools mentioned here i.e. Nuget storing GBs worth of packages there).

[founderio]

It should be worth noting that omnisharp should not only be a good citizen on Windows. Linux and Mac also have rules for where to put things. As already mentioned in microsoft/vscode#3884 above.

[rchande]

@akshita31 This might be interesting for you

[DustinCampbell]

FWIW, I'm not sure it's very high priority. Also, if we outright move the location, it's a breaking change. We'd probably just want to add another default location.

[Erithax]

"10.4 Your app s data that is exclusive to a specific user and that is not to be shared with other users of the computer, must be stored in Users\\AppData" Certification requirements for Windows Desktop Apps: docs.microsoft.com

I'll just leave that here, I hate %USERPROFILE% dumping.

[lhindir]

Unfortunately, a lot of people are coming from Linux where $HOME is a dumping ground for whatever data any application wants to add, since prior to XDG, linux didn't really have a story for where files should go (this has since been resolved though most apps haven't caught up yet).

In case it wasn't clear, when this is fixed, please fix it on Linux as well! I would say most apps have caught up; even in 2017 many apps were already behaving. It's usually the cross-platform ones like Omnisharp, VS Code, and dotnet that have issues. XDG_CONFIG_HOME for config and XDG_DATA_HOME for cache are pretty well respected these days.

Thanks :)

[stkb]

I just want to say if this ever gets fixed, including support for XDG_* vars, please don't restrict their support to Linux & Mac either. They can be used just as well on Windows.