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

[Abrynos]

Any progress on this one?

[SaphireLattice]

There's also .templateengine from https://github.com/dotnet/templating/blob/47e96dd1af9b63888da37b632f299b7c9e86879a/src/Microsoft.TemplateEngine.Edge/DefaultPathInfo.cs - not sure if slapping an actual directory existence check (so that it can work with legacy $HOME/.templateengine when present) would be good though? Kinda introduces a bit of a side effect, but dunno, it already checks up the env variable

And of course tests for that, too.

Now for .dotnet itself... well, there's a lot.

Various scripts, of course a ton of tests, and there's a .target file referencing $([System.IO.Path]::Combine($(_DefaultUserProfileRuntimeStorePath), '.dotnet', 'store')) so that would need to be handled too, if we want to avoid any breaking changes and have no intervention required when upgrading...

...and that's before we touch on any user tools, on interaction between SDK versions and their tooling. So yeah, this thing is very hardcoded basically, across different tools and non-C# files (definitions, scripts).