Sdk: Request, able to config the location of ~/.dotnet and ~/.templateengine

[ariellourenco]

Hi @livarcocc ,

May you can help me with this simple question. Is there anyway to re-locate the dotnet user profile folder (.dotnet)?

[wli3]

Hi @ariellourenco

The location is fixed relative to user profile

This may not be 100% what you want, you can change the environment variable USERPROFILE on windows, HOME on Linux. Which will create a _.dotnet_ under that folder. Note, changing that variable will also affect other program rely on it

[wli3]

Please feel free to reopen if you need more detail

[ariellourenco]

Hi @wli3 ,

Thanks for your response. However, my understanding is this is an opportunity for improvement. We have a similar issue related to ~/.templateengine folder and people from template engine team are working on make it configurable. Please, see the link below and let me know your considerations.

https://github.com/dotnet/templating/issues/806

[omajid]

As a linux power user, I would love it if both ~/.dotnet and ~/.templateengine moved their data elsewhere. For cache, moving it to an appropriate cache location would be great.

[wli3]

@KathleenDollard

[MicahZoltu]

Migrating this over from dotnet/sdk#1543. Of note, I believe it is important to change the _default_ storage paths, not just make them configurable (though both are valuable in their own right). At the moment, dotnet/cli does not respect OS conventions.

I just installed .NET Core SDK onto a Windows 10 Pro (Fall Creators Update) machine. As a side effect, it appears to have created a folder in %USERPROFILE% named .dotnet. On Windows, applications should not be writing configuration data to %USERPROFILE% and instead should be writing it to %APPDATA%\<vendor>\<product>. In this case that would be %APPDATA%\Microsoft\dotnet.

Not only does the . prefix on folders cause problems in Windows (explorer will not allow you to name a folder starting with a .), but it also pollutes what is supposed to be a user-facing folder with configuration data that is not user facing. In general, the only things that should be put into %USERPROFILE% are things the user has explicitly put there via a save dialog. Any files automatically created by an application should go into %APPDATA%\<vendor>\<product>.

As a side note, is there a way I can override this setting while waiting for this issue to be resolved? The files in this folder appear to not be intended for human consumption, and I really try to keep my %USERPROFILE% directory uncluttered with garbage from various things I have installed on my computer.

[yanoryuichi]

In Windows, configuration files should not be stored in %USERPORFILE%. They should be in %APPDATA%. Please respect Windows standards. Moreover, you should consider XDG user directories in Linux.
https://wiki.archlinux.org/index.php/XDG_user_directories

[KathleenDollard]

@livarcocc Is this still in our backlog?

[livarcocc]

Yes.

[ryanseipp]

Has there been any progress towards this issue, or an expectation of what milestone this will be addressed in?

[rkm]

Has there been any progress towards this, or would you be open to someone submitting a PR?

[wli3]

Also will setting dotnet_cli_home satisfy the requirement?

[rkm]

Just tried setting DOTNET_CLI_HOME, removing my current ~/.dotnet directory, and re-building one of my projects. The result was that the ~/.dotnet directory was partially repopulated:

$ dotnet --help
.NET Core SDK (3.1.103)
$ export DOTNET_CLI_HOME=~/tmp
$ rm -r ~/.dotnet
$ dotnet build ...
$ ls ~/.dotnet
corefx  optimizationdata
$ ls -a ~/tmp
.  ..  .dotnet  .nuget

Edit: Splitting the user config from any cached data would be useful e.g. as specified here

[wli3]

I see. This is not ideal. Different component of .NET core stack have different code paths to decide the persistent storage. It is not an easy fix. I don't think this is something community can easily contribute since it requires coordination between runtime, templates engine, CLI and nuget.

It would also require a large amount of testing to ensure there is no regression.

So far there is no roadmap for this issue.

[dlagg]

I see. This is not ideal. Different component of .NET core stack have different code paths to decide the persistent storage. It is not an easy fix. I don't think this is something community can easily contribute since it requires coordination between runtime, templates engine, CLI and nuget.

It would also require a large amount of testing to ensure there is no regression.

So far there is no roadmap for this issue.

Nuget it's configurable:

export NUGET_PACKAGES="$XDG_CACHE_HOME"/NuGetPackages