Templating: Configurable cache location

Created on 16 May 2017  路  5Comments  路  Source: dotnet/templating

Instead of the ~/.templateengine/{HostName} cache location, it would be great if it were configurable by the host.

On VS for Mac, for example, we have an existing cache directory in the more idiomatic location ~/Library/Caches/VisualStudio/7.0. Similarly in MonoDevelop for Linux, we follow the XDG convention and use ${XDG_CACHE_HOME:-$HOME/.cache}/MonoDevelop/7.0.

It would be great to be able to put the template cache in a subdirectory of our existing cache location.

triaged

Most helpful comment

I do not have rights to reopen this issue, but I think it or #852 should remain open. Dumping stuff into USER_PROFILE is bad and should be considered a bug IMO.

All 5 comments

From @MicahZoltu in #852

Related to #806

On Windows, dotnet templating should be a good citizen and follow Microsoft recommendations for folder locations. Currently it appears a folder called .templateengine in %USERPROFILE%. %USERPROFILE% should NOT contain any files that the user doesn't put there themselves aside from the OS defaults. %USERPROFILE% is where the user puts files, e.g., via a save dialog box or because they explicitly set a path to there. The correct location is either %APPDATA%, %LOCALAPPDATA%, %PROGRAMDATA% or %PROGRAMFILES% depending on what exactly you want to store.

%APPDATA% should contain user-specific configuration files only and nothing large. This folder may be synced over a network or internet on login/logout so should remain small (Kilobytes).
%LOCALAPPDATA% should contain user-specific files that will not follow the user across machines. This is a great place to put any caches that can be rebuilt when the user logs in to a new machine. It is also a good place to put user-specific files too large for %APPDATA%.
%PROGRAMDATA% is machine wide and read/write by everyone. For security reasons, nothing executable should go here as anyone with access to the machine can write to it. This is a good place for machine-wide configuration files that can easily be deleted and re-configured if they become corrupt.
%PROGRAMFILES% is machine wide and wirtable only by administrators. This is usually where executable files go and tend to only be put here on install, since that is usually when elevation occurs.
Note: Always use either the API mechanisms for getting the paths to these folders or the environment variables. All of these paths are configurable by end-users and one should not assume where they live relative to any other folders.

I think this folder is new with the CLI preview, so I strongly recommend resolving it before release so you don't have to deal with backwards compatibility.

I believe Linux has a similar system called XGD or something, and OSX has their own storage system. All OSs should be respected, and I don't believe on any of them other than older versions of Linux is $HOME/%USERPROFILE% the right choice.

When we do this work:

  • New runs should migrate hives under %UserProfile%/$HOME to the new location
  • Additional signatures should be added to the bootstrapper/host interface to not break folks using the defaults
  • An announcement will need to be made to let people know about the move, just in case people are reading the cache locations directly

Yeah, and on Mac and Linux it's a little more complex than I described. There isn't the concept of local versus roaming, but there are different locations for caches / settings / data files etc. FWIW, here's what we do for MonoDevelop: https://github.com/mono/monodevelop/blob/master/main/src/core/MonoDevelop.Core/MonoDevelop.Core/UserProfile.cs

This issue was last touched some years ago. We are working on a new delivery road map. Please reopen if this is something we want & we'll properly assess its' priority compared to other work aimed at improving the overall templating UX.

I do not have rights to reopen this issue, but I think it or #852 should remain open. Dumping stuff into USER_PROFILE is bad and should be considered a bug IMO.

Was this page helpful?
0 / 5 - 0 ratings