Arch Linux dotnet Update Fix

Quick fix: a stale workload set is left over from an earlier dotnet workload update. Delete the two directories named after it, then rebuild.

The error

After a CachyOS (Arch) system update, an AUR package that builds with .NET (in my case naps2) fails with:

An issue was encountered verifying workloads. For more information, run "dotnet workload update".
.../Microsoft.NET.Sdk.ImportWorkloads.props(14,38): error MSB4242:
  SDK Resolver Failure: "The SDK resolver "Microsoft.DotNet.MSBuildWorkloadSdkResolver" failed ...
  System.InvalidOperationException: Workload set version 10.0.112.1 has missing manifests
  likely removed by package management. Run "dotnet workload repair" to fix this.
==> ERROR: A failure occurred in build().
 -> error making: naps2-exit status 4

Why it happens

At some point I ran dotnet workload update (or repair) against the pacman-managed SDK in /usr/share/dotnet. That created a workload set directory (here 10.0.112.1) which pacman does not track. When pacman later updated the SDK (10.0.112 to 10.0.113), it replaced the loose manifests but left the workload set behind.

With nothing pinned, the SDK automatically picks the newest workload set it finds. It picked the stale one, found its manifests missing, and every build that touches MSBuild workload resolution failed.

What did not work

sudo dotnet workload repair reports “No workloads are installed, nothing to repair”.
grep -r "10.0.112" /usr/share/dotnet/metadata only finds harmless history logs, because the problem is a directory name, not file contents.
InstallState/default.json was just {}, so nothing was pinned there. Leave it alone.

The fix

1. Find the stale workload set by name

sudo find /usr/share/dotnet ~/.dotnet -name "*10.0.112.1*" 2>/dev/null

Replace 10.0.112.1 with the version number from your own error message. Expect two hits:

/usr/share/dotnet/sdk-manifests/10.0.100/workloadsets/10.0.112.1
/usr/share/dotnet/metadata/workloads/InstalledWorkloadSets/v1/10.0.112.1

2. Delete both

sudo rm -rf /usr/share/dotnet/sdk-manifests/10.0.100/workloadsets/10.0.112.1
sudo rm -rf /usr/share/dotnet/metadata/workloads/InstalledWorkloadSets/v1/10.0.112.1

Once the set is gone, the SDK falls back to the loose manifests pacman installed in sdk-manifests/10.0.100/, which are current.

3. Verify and rebuild

dotnet workload --info
paru -S naps2

--info should no longer mention a workload set or the old version number.

Quick one-liner for next time

Swap in the version from the error message:

V=10.0.112.1
sudo rm -rf /usr/share/dotnet/sdk-manifests/10.0.100/workloadsets/$V \
            /usr/share/dotnet/metadata/workloads/InstalledWorkloadSets/v1/$V

If the feature band differs from 10.0.100 after a major SDK change, run the find from step 1 to locate the right paths.

Preventing it

Avoid running dotnet workload update or repair against the pacman-managed SDK. Pacman does not track the files they create, so they go stale at the next SDK upgrade. If you actually need workloads, install a separate SDK into your home directory with dotnet-install.sh so they stay out of /usr/share/dotnet.

Tested on CachyOS with .NET SDK 10.0.113, October 2026.