`dotnet restore --locked-mode` does not work as expected (the `contentHash` of `Microsoft.NET.Sdk.WebAssembly.Pack` differs on Windows)

[Cryptoc1]

Describe the bug

When using RestorePackagesWithLockFile in a [hosted] Blazor WebAssembly project, dotnet restore --locked-mode fails across platforms (e.g. development on Windows, building on Linux in CI) due to contentHash of the Microsoft.NET.Sdk.WebAssembly.Pack package differing.

In my case, I do most of my development on my Windows machine, and use the ubuntu-latest images for my GitHub Actions- build log of the failure can be found here.

If I clone to a Linux environment (wsl), dotnet restore --locked-mode reproduces the error from GitHub Actions:

    /home/cryptoc1/Developer/wadio/src/App/UI/Wadio.App.UI.csproj : error NU1403:
      Package content hash validation failed for Microsoft.NET.Sdk.WebAssembly.Pack.10.0.0. The package is different tha
      n the last restore.


Restore failed with 1 error(s) in 1.4s

When I run dotnet restore --force-evaluate on my Windows machine, there are no changes to commit. However, running dotnet restore --force-evaluate in the Linux environment changes the contentHash of the wasm pack:

diff --git a/src/App/UI/packages.lock.json b/src/App/UI/packages.lock.json
index 69d12cc..9beaab7 100644
--- a/src/App/UI/packages.lock.json
+++ b/src/App/UI/packages.lock.json
@@ -151,7 +151,7 @@
         "type": "Direct",
         "requested": "[10.0.0, )",
         "resolved": "10.0.0",
-        "contentHash": "jRA47332BBtRFmHdeIcZyssj2vplKl7/0GoaNVVQQXKFvPcpBgR5R1jTGqMyWb89skl6B6/L/uZ4WE2IEwZPJA=="
+        "contentHash": "bewqpnzRlrdGaiT4f8aSbHiKuFhm/HWKcOAgvhFpYL1OhWR0zWakDnCB67XaJ33yQKj0gsIEMl1vry6c9iGpwQ=="
       },
       "Microsoft.SourceLink.GitHub": {
         "type": "Direct",

Further technical details

details of dotnet --info (Windows)

.NET SDK:
 Version:           10.0.100
 Commit:            b0f34d51fc
 Workload version:  10.0.100.1
 MSBuild version:   18.0.2+b0f34d51f
Runtime Environment:

OS Name:     Windows

OS Version:  10.0.26200

OS Platform: Windows

RID:         win-x64

Base Path:   C:\Program Files\dotnet\sdk\10.0.100\
.NET workloads installed:

[wasm-tools]

Installation Source: SDK 10.0.100

Manifest Version:    10.0.100/10.0.100

Manifest Path:       C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.workload.mono.toolchain.current\10.0.100\WorkloadManifest.json

Install Type:              Msi
Configured to use workload sets when installing new manifests.
Host:

Version:      10.0.0

Architecture: x64

Commit:       b0f34d51fc
.NET SDKs installed:

8.0.416 [C:\Program Files\dotnet\sdk]

9.0.307 [C:\Program Files\dotnet\sdk]

10.0.100 [C:\Program Files\dotnet\sdk]
.NET runtimes installed:

Microsoft.AspNetCore.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]

Microsoft.AspNetCore.App 9.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]

Microsoft.AspNetCore.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]

Microsoft.NETCore.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Microsoft.NETCore.App 9.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Microsoft.NETCore.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Microsoft.WindowsDesktop.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Microsoft.WindowsDesktop.App 9.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Microsoft.WindowsDesktop.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Other architectures found:

None
Environment variables:

DOTNET_CLI_TELEMETRY_OPTOUT              [1]

DOTNET_NOLOGO                            [1]
global.json file:

X:\wadio\global.json
Learn more:

https://aka.ms/dotnet/info
Download .NET:

https://aka.ms/dotnet/download

details of dotnet --info (Linux)

.NET SDK:
 Version:           10.0.100
 Commit:            b0f34d51fc
 Workload version:  10.0.100.1
 MSBuild version:   18.0.2+b0f34d51f
Runtime Environment:

OS Name:     ubuntu

OS Version:  24.04

OS Platform: Linux

RID:         linux-x64

Base Path:   /home/cryptoc1/.dotnet/sdk/10.0.100/
.NET workloads installed:

[wasm-tools]

Installation Source: SDK 10.0.100

Manifest Version:    10.0.100/10.0.100

Manifest Path:       /home/cryptoc1/.dotnet/sdk-manifests/10.0.100/microsoft.net.workload.mono.toolchain.current/10.0.100/WorkloadManifest.json

Install Type:        FileBased
[wasm-tools-net9]

Installation Source: SDK 10.0.100

Manifest Version:    10.0.100/10.0.100

Manifest Path:       /home/cryptoc1/.dotnet/sdk-manifests/10.0.100/microsoft.net.workload.mono.toolchain.net9/10.0.100/WorkloadManifest.json

Install Type:        FileBased
Configured to use workload sets when installing new manifests.
Host:

Version:      10.0.0

Architecture: x64

Commit:       b0f34d51fc
.NET SDKs installed:

9.0.307 [/home/cryptoc1/.dotnet/sdk]

10.0.100 [/home/cryptoc1/.dotnet/sdk]
.NET runtimes installed:

Microsoft.AspNetCore.App 9.0.11 [/home/cryptoc1/.dotnet/shared/Microsoft.AspNetCore.App]

Microsoft.AspNetCore.App 10.0.0 [/home/cryptoc1/.dotnet/shared/Microsoft.AspNetCore.App]

Microsoft.NETCore.App 9.0.11 [/home/cryptoc1/.dotnet/shared/Microsoft.NETCore.App]

Microsoft.NETCore.App 10.0.0 [/home/cryptoc1/.dotnet/shared/Microsoft.NETCore.App]
Other architectures found:

None
Environment variables:

DOTNET_ROOT                              [/home/cryptoc1/.dotnet]
global.json file:

/home/cryptoc1/Developer/wadio/global.json
Learn more:

https://aka.ms/dotnet/info
Download .NET:

https://aka.ms/dotnet/download

Installed Software (Windows):

• VS2026
• .NET SDK: 10.0.100, 9.0.307, 8.0.416
• .NET Workloads: maui, wasm-tools, wasm-tools-net9
• NodeJS: v24.11.0

Installed Software (WSL - Ubuntu 24.04)

• .NET SDK: 10.0.100, 9.0.307
• .NET Workloads: wasm-tools, wasm-tools-net9
• NodeJS: v24.11.0

[Cryptoc1]

Update: setting my gh-actions to use windows-latest images did not resolve the issue, as I expected.
(build log)

I suspect VS may be interfering with the workloads? (for reference, I am able to dotnet publish -o ... locally on my Windows machine).

[KalleOlaviNiemitalo]

Setting the DisableImplicitNuGetFallbackFolder property might help.

[Cryptoc1]

I will give that a try- I am able to temporarily workaround the issue by simply doing my development within WSL (which mostly works, having some issues with wasm breakpoints hitting in VSCode over the WSL tunnel).

This leads me to believe that the source of this issue is related to the presence of Visual Studio, and whatever it's doing behind the scenes to manage sdk/workloads differently than the cli.

[ricardomomm]

Same issue here, I can confirm after talking to other team members that didn't update their VS to latest, they are generating a different hash compared to my pc (with latest VS).