dotnetup update gives Note: Unknown folder 'runfile' found in dotnet root, skipping.

[Frulfump]

Using Ubuntu 24.04 in WSL

Terminal output when running dotnetup update

Updating .NET SDK preview to 11.0.100-preview.6.26359.118...

  Downloaded  .NET SDK                 11.0.100-preview.6.26359.118 (185.0 MB / 185.0 MB) ━━━ 100
                                                                                                %
  Installed   .NET SDK                 11.0.100-preview.6.26359.118                       ━━━ 100
                                                                                                %

Updated .NET SDK preview to 11.0.100-preview.6.26359.118.
Updating .NET SDK 10.0.1xx to 10.0.110...

  Downloaded  .NET SDK                 10.0.110 (228.6 MB / 228.6 MB) ━━━━━━━━━━━━━━━━━━━━━━ 100%
  Installed   .NET SDK                 10.0.110                       ━━━━━━━━━━━━━━━━━━━━━━ 100%

Updated .NET SDK 10.0.1xx to 10.0.110.
Removing unused installations...
Note: Unknown folder 'runfile' found in dotnet root, skipping.
...

The command seems to succeed and was a really nice way to acquire the SDK updates to my two channels as winget as an example hasn't gotten the PRs merged yet.

No clue what the runfile folder is, to install dotnetup I just did curl -fsSL https://aka.ms/dotnetup/get-dotnetup.sh | bash and followed the default installation options and path instructions etc to get 10.0.1xx and Preview and I haven't done any other modifications.

dotnetup --version
0.1.4-preview.6.26356.3+c6236f5f46e901afb53acaeb9080562f5cbe3889

Could a command be created that updates dotnetup itself? Or maybe it self-updated on update not sure.

A bit surprised that dotnetup install just installed 10.0.302 without asking as I though it would be an interactive experience but it was the result I was looking for anyways.

[baronfel]

dotnetup has a concept of an 'install root' - the place where it stores the downloaded dotnet installations, and this location is something like (on Windows) {USERLOCAL}\.dotnet. It expects this root to just have the SDKs it manages, but it's quite likely that given such a generic name that another tooling feature (like file-based apps cc @DamianEdwards) has chosen this same scheme, and so dotnetup is seeing directories that other tools have assumed as a default.

@nagilson / @dsplaisted this is more evidence to me that we should keep the dotnetup-managed root underneath the dotnetup state directory instead of this more generic name.

[Frulfump]

Ah ok for me in WSL Ubuntu ~/.dotnet I have a bunch of things

10.0.100-preview.6.25358.103.aspNetCertificateSentinel
10.0.100-preview.6.25358.103.dotnetFirstUseSentinel
10.0.100-preview.6.25358.103.toolpath.sentinel
10.0.100-preview.6.25358.103_IsDockerContainer.dotnetUserLevelCache
10.0.100-preview.6.25358.103_MachineId.dotnetUserLevelCache
10.0.100-preview.7.25380.108.aspNetCertificateSentinel
10.0.100-preview.7.25380.108.dotnetFirstUseSentinel
10.0.100-preview.7.25380.108.toolpath.sentinel
10.0.109.aspNetCertificateSentinel
10.0.109.dotnetFirstUseSentinel
10.0.109.toolpath.sentinel
11.0.100-preview.5.26302.115.aspNetCertificateSentinel
11.0.100-preview.5.26302.115.dotnetFirstUseSentinel
11.0.100-preview.5.26302.115.toolpath.sentinel
11.0.100-preview.6.26359.118.aspNetCertificateSentinel
11.0.100-preview.6.26359.118.dotnetFirstUseSentinel
11.0.100-preview.6.26359.118.toolpath.sentinel
8.0.119.aspNetCertificateSentinel
8.0.119.dotnetFirstUseSentinel
8.0.119.toolpath.sentinel
8.0.119_IsDockerContainer.dotnetUserLevelCache
8.0.119_MachineId.dotnetUserLevelCache
LICENSE.txt
MachineId.v1.dotnetUserLevelCache
TelemetryStorageService
ThirdPartyNotices.txt
corefx
dnx
dotnet
host
metadata
packs
sdk
sdk-advertising
sdk-manifests
sdk-vulnerability-cache
shared
templates

~/.local/share/dotnet
contains a runfile folder
and one file
dotnet-run-file-artifacts-metadata.json
Containing just
{"LastAutomaticCleanupUtc":"2026-07-07T15:40:21.1462235Z"}

I was actually doing some simple filebased-app (FBA) and NAOT publishing testing for FBAs earlier.