Debug‑only package `Microsoft.DotNet.HotReload.WebAssembly.Browser` causes non‑deterministic builds

[donnie-msft]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

We (NuGet Client team) recently investigated a customer‑reported issue (NuGet/Home#14710) where Blazor WebAssembly projects generate a non‑repeatable build because an additional package (Microsoft.DotNet.HotReload.WebAssembly.Browser:[10.0.101, )) is present during Debug restore but removed during Release builds.

This behavior violates the guarantees of lock files and deterministic/ reproducible builds.

Problem Summary

A customer ran:

dotnet restore --force --force-evaluate

The generated lock file included the following package, which appears to be injected only for debugging scenarios:

Microsoft.DotNet.HotReload.WebAssembly.Browser:[10.0.101, )

Later, when they built for Release on CI:

dotnet publish TestBlazorWasm.csproj --output publish

the build failed because this package is not provided by the Blazor WASM toolchain in Release mode. CI does not have the package, so the lock file correctly reports a mismatch.

Why This Is a Problem

Including a package during Debug that is not present or resolved during Release means:

• The lock file produced during restore is not valid for all configurations.
• The build is not repeatable across environments (local vs. CI).
• This breaks the core principle of deterministic builds enforced by lock files.
• It requires developers to re‑restore under specific conditions to avoid failures, which defeats the purpose of lock files.

Expected Behavior

Blazor WASM should not inject or remove packages based on the configuration in a way that changes the resolved dependency graph after the lock file is created.

Steps To Reproduce

Minimal steps are already included in NuGet/Home#14710. .
The core repro is:

1. Restore → lock file includes the hot‑reload package.
2. Publish for Release → build fails due to lock file mismatch.

Exceptions (if any)

No response

.NET Version

No response

Anything else?

No response

[javiercn]

@tmat can you take a look?

/cc: @maraf in case you have thoughts

[baronfel]

Agree that packages should not be conditioned on Configuration - the only valid, supported Conditions are those based off of TargetFramework. We document this somewhere on the NuGet PackageReference docs.

[dosolkowski-work]

For reference, this was originally reported in #52331.

[tmat]

The package shouldn't exist as a app dependency. The content of the package should be included in the SDK itself. @maraf

[maraf]

Fixed for 11 in #52816.
Backport to 10.0.3xx in #52881.