SDK 11.0.100 no longer sets SelfContained=true for browser-wasm projects, so net10.0 WASM apps that built on SDK 10 fail

Aperta
  • Qualcosa non va?
#137,310 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
csharp, wasm
Ambito
build-system

Direzione di ricerca

Compare the SDK 10 and SDK 11 Mono toolchain manifest targets named in the report, including the net10 manifest, and trace how SelfContained is set for browser-wasm projects. Start by reproducing the provided net10.0 project with SDK 11.0.100 and wasm-tools-net10; confirm the property and build behavior. Done means the runtime pack is resolved and the reproduction builds as it does with SelfContained=true.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area-Build-mono untriaged
Description

A net10.0 project with RuntimeIdentifier=browser-wasm (plain Microsoft.NET.Sdk) builds on SDK 10 but fails on SDK 11.0.100 with the wasm-tools-net10 workload installed.

On SDK 10, the Mono toolchain workload manifest sets SelfContained=true for every browser-wasm project
(sdk-manifests/10.0.100/microsoft.net.workload.mono.toolchain.current/<version>/WorkloadManifest.targets):

<PropertyGroup Condition="'$(RuntimeIdentifier)' == 'browser-wasm'">
  <SelfContained>true</SelfContained>

On SDK 11.0.100, neither microsoft.net.workload.mono.toolchain.current nor microsoft.net.workload.mono.toolchain.net10 sets it. The SDK's own default (SelfContained=false for net8.0+ when only a RID is set) applies, so no runtime pack is resolved and the WASM build fails. A browser-wasm app cannot run without its runtime, so this looks unintended. I could not find it listed as a breaking change.

Reproduction Steps

Repro.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <RuntimeIdentifier>browser-wasm</RuntimeIdentifier>
    <OutputType>Exe</OutputType>
  </PropertyGroup>
</Project>

Program.cs:

System.Console.WriteLine("hello");

Then:

dotnet workload install wasm-tools-net10
dotnet build
dotnet msbuild -getProperty:SelfContained
Expected behavior

Builds, as on SDK 10.0.404 with wasm-tools; SelfContained evaluates to true.

Actual behavior

On SDK 11.0.100, SelfContained evaluates to false and the build fails:

Microsoft.NET.Runtime.WebAssembly.Sdk\10.0.15\Sdk\WasmApp.Common.targets(368,5): error : WasmAssembliesToBundle item is empty. No assemblies to process

In a larger project of the same kind (also WasmBuildNative=true, WasmAppDir set, a SQLite native package reference), the build instead fails earlier with:

Microsoft.NET.Runtime.WebAssembly.Sdk\10.0.15\Sdk\WasmApp.Common.targets(283,5): error : $(MicrosoftNetCoreAppRuntimePackDir)='', and cannot find %(ResolvedRuntimePack.PackageDirectory)=. One of these need to be set to a valid path

Setting SelfContained=true fixes both.

SDK Workload SelfContained Build
10.0.404 (Linux, mcr.microsoft.com/dotnet/sdk:10.0-noble) wasm-tools true succeeds
11.0.100 (Windows) wasm-tools-net10 false fails
11.0.100 with -p:SelfContained=true wasm-tools-net10 true succeeds

The same repro targeting net11.0 with wasm-tools on SDK 11.0.100 fails with the MicrosoftNetCoreAppRuntimePackDir error above.

Regression?

Yes. Works on SDK 10.0.404; fails on SDK 11.0.100.

Known Workarounds

Set <SelfContained>true</SelfContained> in the project.

Configuration
  • SDK 11.0.100, Windows 11 x64; also reproduced on a Windows build agent with SDK 11.0.100
  • Workload wasm-tools-net10, manifest 11.0.100 (WebAssembly SDK pack 10.0.15)
  • Comparison: SDK 10.0.404 on Linux x64 (Docker), workload wasm-tools 10.0.115 manifests
Other information

Projects using the Blazor/WebAssembly SDKs may not be affected; not verified.

Lingua principale
C#
Stelle
18.4k
Fork
5.8k
Merge medio
2g 19h
PR unite (30g)
590

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dotnet/runtime

Tutte le issue di dotnet/runtime

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.