Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

[browser] Use WebAssembly SDK for runtime tests#120330

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
maraf wants to merge109 commits intodotnet:main
base:main
Choose a base branch
Loading
frommaraf:WasmSdkInTree2

Conversation

@maraf
Copy link
Member

@marafmaraf commentedOct 2, 2025•
edited
Loading

  • One of the goals of this PR is to use WasmSDK in most standard way and avoid too much deviation just for runtime repo
  • Hook WasmSDK pack into InTree build
  • RemoveWasmAppBuilder and targets around it
  • Move AOT & EAT smoke tests from Helix to AzDo. We don't support "AOT on Helix" in WasmSDK because of the way how build is composed. The whole set of tests won't finish there, but we don't run it on runtime pipeline. It would require a significant amount of work. We have options if we need it later
  • Removeminimal-config sample as we have a proper way to generate bundler-friendly boot config
  • MSBuild tests changes have brief explanations why they are neded
  • Library tests don't follow the convention that StaticWebAssetsSDK expects. We haveLinkContentToWwwroot task to manipulate incoming@(Content) and$(PublishDir) files to the shape that can be consumed by SWA and accessible at some URL (in the wwwroot)
  • Remove unusedWasmInvariantGlobalization
  • Fix paths forWasmRunWasmOpt

Fixes to#103025

TODO
  • Copy to library test output
    • test-main.js
    • index.html
    • WasmTestRunner.dll as mainAssembly
    • WasmSymbolicator.dll
    • wasm-symbol-patterns.txt
  • Pack.Tasks for TrimmingTests
  • Exclude XHarness plugins (WasmSymbolicator.dll) from AOT compilation
    • The reason why it's failing here is that<Content Link="..." copy the assembly to the publish output early enough, so that it gets picked up toWasmAssembliesToBundle and so the AOT compiler gets it
  • NetCoreServer andRemoteLoopServerGetCurrentProjectBuildStaticWebAssetItems
  • SupportWasmFilesToIncludeInFileSystem - We needed coreVfs for runtimeConfig, but we have that solved now by embedding it into the boot manifest. I think we can drop coreVfs. The challenge is that VFS items hastargetPath as well, so SWA standard properties aren't enough
  • SupportIncludeSatelliteAssembliesInVFS (it's not used anywhere anymore)
    • Implement it only in tests.targets
  • browser-wasm linux Release LibraryTests_EAT (aka AOTonHelix)
    • Use Wasm.Build.Tests infrastructure
    • tests.proj
      • RunSmokeTestsOnly=true
      • RunHighAOTResourceRequiringTestsOnly=true
    • ProxyProjectForAOTOnHelix.proj is usingWasmApp.LocalBuild.props/targets
    • Update default target. For AOT it does AOT compilation, but it doesn't invoke "Build". The .NET build runs on AzDO, WasmBuild runs on Helix
      • RunPrepareForRun (DependsOn) for SWA
      • RunComputeAndCopyFilesToPublishDirectory for SWA
    • WasmAppDir
    • Support AOT in build
  • <OutputType Condition="'$(OutputType)' == ''">exe</OutputType> inMicrosoft.NET.Sdk.WebAssembly.Browser.props is too relaxed as at the point the default value oflibrary is already supplied by general SDK props
  • Library tests are doing native relink
  • FunctionalTests
    • StartupHookForFunctionalTest.csproj
  • Wasm.Advanced.Sample.csproj hasWasmAssembliesToBundle item is empty
  • StartupHookForFunctionalTest conflicting SWAMicrosoft.CSharp.wasm
  • If we unhook all WasmSDK targets from in nested publish, IncrementalClean will delete the files in bin folder
  • Library tests are not loading ICU correctly
    • InvariantGlobalization is empty, results in_WasmInvariantGlobalization=true
    • FollowWasmIncludeFullIcuData
  • RemoveWasmAppBuilder and related targets
    • RemoveWasmExtraFilesToDeploy from tests
    • <WasmEnvironmentVariable Include="DOTNET_DiagnosticPorts" Value="$(DiagnosticPorts)" Condition="'$(DiagnosticPorts)' != ''"/>
  • TrimmingTests
    • InvariantGlobalization
  • RuntimeTests
    • dotnet.js is just boot config, it doesn't contain the loader script

@marafmaraf added this to the11.0.0 milestoneOct 2, 2025
@marafmaraf self-assigned thisOct 2, 2025
@marafmaraf added arch-wasmWebAssembly architecture area-Build-mono os-browserBrowser variant of arch-wasm labelsOct 2, 2025
@maraf

This comment was marked as resolved.

Copy link
Contributor

CopilotAI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Pull request overview

This PR migrates WebAssembly runtime tests from using the legacyWasmAppBuilder task to the WebAssembly SDK. This is a significant infrastructure change that modernizes the build pipeline and removes technical debt.

Key changes:

  • RemovesWasmAppBuilder task and related targets (522 lines deleted from WasmAppBuilder.cs)
  • IntroducesLinkContentToWwwroot task to transform content items for StaticWebAssets SDK compatibility
  • Changes output directory fromAppBundle towwwroot for browser targets
  • Updates SDK integration with proper props/targets imports from Microsoft.NET.Sdk.WebAssembly
  • Migrates AOT & EAT smoke tests from Helix to Azure DevOps
  • Removesminimal-config sample (replaced by proper SDK support)

Reviewed changes

Copilot reviewed 59 out of 82 changed files in this pull request and generated 4 comments.

Show a summary per file
FileDescription
src/tests/build.projParameterizes mobile app bundle directory name to supportwwwroot for browser
src/tests/Common/helixpublishwitharcade.projUpdates all references from hardcodedAppBundle to useMobileAppBundleDirName
src/tests/FunctionalTests/WebAssembly/Directory.Build.propsConvertsWasmExtraFilesToDeploy toContent items withLink metadata
src/tasks/WasmBuildTasks/LinkContentToWwwroot.csNew task that handles content transformation for StaticWebAssets SDK
src/tasks/WasmAppBuilder/WasmAppBuilder.csDeleted - replaced by WebAssembly SDK
src/tasks/Microsoft.NET.Sdk.WebAssembly.Pack.Tasks/GenerateWasmBootJson.csAdds path normalization for VFS resources
src/tasks/Microsoft.NET.Sdk.WebAssembly.Pack.Tasks/ComputeWasmBuildAssets.csAdds duplicate file name detection
src/mono/wasm/build/WasmApp.LocalBuild.propsConfigures WebAssembly SDK paths for in-tree builds
src/mono/wasm/build/WasmApp.Common.targetsFixesWasmRunWasmOpt path handling
src/mono/sample/wasm/*Multiple samples updated to removeWasmExtraFilesToDeploy and use wwwroot
src/mono/sample/wasm/browser-minimal-config/*Entire sample removed (SDK now supports this scenario)
src/mono/nuget/Microsoft.NET.Sdk.WebAssembly.Pack/build/Microsoft.NET.Sdk.WebAssembly.Browser.targetsMajor refactoring of VFS and asset handling
src/libraries/*/tests/*.csprojLibrary tests updated to useContent withLink instead ofWasmExtraFilesToDeploy
eng/testing/tests.wasm.targetsUpdates for wwwroot and removes unusedWasmGenerateAppBundle property
eng/testing/tests.browser.targetsSignificant refactoring for SDK integration and content linking
eng/testing/linker/trimmingTests.targetsUpdates paths fromAppBundle topublish/wwwroot
eng/pipelines/runtime.ymlDisablesbuildAOTOnHelix for EAT and Smoke tests

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Copy link
Member

@ilonatommyilonatommy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Initial pass: I'm 50% done 😉

maraf reacted with heart emoji
Copy link
Member

@ilonatommyilonatommy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Approved for me but I think more people should read it.

pavelsavara reacted with eyes emoji
continue;
}

Log.LogMessage(MessageImportance.Low,$"Skipping item with Identity '{identity}' (TargetPath '{targetPath}', Link '{link}') because CopyToOutputDirectory is not 'PreserveNewest' or 'Always' ('{copyPreserveOrAlways}').");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Nit: could we change the order? First checkif(!copyPreserveOrAlways) -> log skip message +continue.

Could you also confirm that the current behavior is expected:
If we have item with target path with link that iswwwroot, then we will log "Skipping item with Identity .. because CopyToOutputDirectory is not 'PreserveNewest' or 'Always' ".

This does not look intentional. Maybe using if-else-else would help.

<_MonoAotCrossCompilerPath>$([MSBuild]::NormalizePath($(MonoArtifactsPath), 'cross', '$(TargetOS)-$(TargetArchitecture.ToLowerInvariant())', 'mono-aot-cross'))</_MonoAotCrossCompilerPath>
<_MonoAotCrossCompilerPathCondition="$([MSBuild]::IsOSPlatform('WINDOWS'))">$(_MonoAotCrossCompilerPath).exe</_MonoAotCrossCompilerPath>

<_WebAssemblyPropsFileCondition="'$(_WebAssemblyPropsFile)' == ''">$(RuntimeSrcDir)\mono\nuget\Microsoft.NET.Sdk.WebAssembly.Pack\build\Microsoft.NET.Sdk.WebAssembly.Browser.props</_WebAssemblyPropsFile>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Maybe it should be blamed on git diff view but I don't see this property used, only definitions.

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

We can revert all changes in LocalBuild targets, it's the feature for AOT on Helix, which doesn't work

ilonatommy reacted with thumbs up emoji
@pavelsavara
Copy link
Member

/azp run runtime-wasm

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

<WasmXHarnessArgs>$(WasmXHarnessArgs) --web-server-middleware=$(_RemoteLoopMiddleware)/RemoteLoopServer.dll,RemoteLoopServer.GenericHandler</WasmXHarnessArgs>
<WasmXHarnessArgs>$(WasmXHarnessArgs) --web-server-middleware=$(_TestEchoMiddleware)/NetCoreServer.dll,NetCoreServer.GenericHandler</WasmXHarnessArgs>

<!-- Pass '_TargetFrameworkForXHarness' when StaticWebAssetsSDK is processing NetCoreServer and RemoteLoopServer reference-->
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

NetCoreServer.dll needs to be on the server side only. Why does it impact StaticWebAssets ?

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

StaticWebAssetsSDK is looking if any referenced project contains StaticWebAssets. StaticWebAssets is a server-side feature.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I mean, NetCoreServer doesn't expose any static assets, it's a HTTP server plugin. So it should not influence content of wwwroot at all, nor end up in VFS.

Copy link
MemberAuthor

@marafmarafNov 28, 2025•
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Yes, but StaticWebAssetsSDK doesn't know it. It just probes all ProjectReferences. If we don't pass the TFM property, the nested msbuild invocation by StaticWebAssetsSDK won't work correctly.

Yes, it doesn't do anything in this case. Anyway StaticWebAssetsSDK needs to check

<linkrel="preload"href="./dotnet.boot.js"as="fetch"crossorigin="use-credentials">
<linkrel="prefetch"href="./dotnet.native.js"as="fetch"crossorigin="anonymous">
<linkrel="prefetch"href="./dotnet.runtime.js"as="fetch"crossorigin="anonymous">
<scripttype='module'src="./_framework/dotnet.js"></script>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

@radekdoulik does this PR break any of the benchmark infra you have ?

Copy link
Member

@pavelsavarapavelsavara left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

LGTM, few nits. Thank you for doing this!

maraf reacted with heart emoji
@maraf
Copy link
MemberAuthor

/azp run runtime-wasm

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@maraf
Copy link
MemberAuthor

/azp run runtime-wasm

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@pavelsavarapavelsavarapavelsavara approved these changes

@ilonatommyilonatommyilonatommy left review comments

Copilot code reviewCopilotCopilot left review comments

@akoeplingerakoeplingerAwaiting requested review from akoeplingerakoeplinger is a code owner

@lewinglewingAwaiting requested review from lewinglewing is a code owner

@steveisoksteveisokAwaiting requested review from steveisoksteveisok is a code owner

@vitek-karasvitek-karasAwaiting requested review from vitek-karasvitek-karas is a code owner

Assignees

@marafmaraf

Labels

arch-wasmWebAssembly architecturearea-Build-monoos-browserBrowser variant of arch-wasm

Projects

None yet

Milestone

11.0.0

Development

Successfully merging this pull request may close these issues.

3 participants

@maraf@pavelsavara@ilonatommy
[8]ページ先頭
©2009-2025 Movatter.jp