[browser] Add publish-time telemetry for WebAssembly configuration properties

[Copilot]

Description

Adds telemetry to capture effective values of key WASM/Blazor publish configuration properties (globalization mode, boot config shape, fingerprinting, preload behavior, bundler friendliness, runtime selection) to inform defaults and compatibility decisions.

Changes

• Added _GatherWasmPublishTelemetry target in Microsoft.NET.Sdk.WebAssembly.Browser.targets

  • Hooks into the workload telemetry pipeline via WorkloadTelemetryDependsOn extensibility point
  • Skips nested publish via Condition="'$(WasmBuildingForNestedPublish)' != 'true'"
  • Emits properties to the existing WorkloadPublishProperties telemetry event
  • Includes documentation comment linking to SDK telemetry docs for synchronization

• Captures 10 properties using normalized internal values where applicable:

  • InvariantTimezone (derived from BlazorEnableTimeZoneSupport)
  • InvariantGlobalization (_WasmInvariantGlobalization)
  • BlazorWebAssemblyLoadAllGlobalizationData (_BlazorWebAssemblyLoadAllGlobalizationData)
  • WasmEnableWebcil (_WasmEnableWebcil)
  • WasmInlineBootConfig (_WasmInlineBootConfig)
  • OverrideHtmlAssetPlaceholders (raw value)
  • WasmFingerprintBootConfig (_WasmFingerprintBootConfig)
  • WasmPreloadAssets (_WasmPreloadAssets)
  • WasmBundlerFriendlyBootConfig (_WasmBundlerFriendlyBootConfig)
  • UseMonoRuntime (raw value)

Notes

Integrates with the existing WorkloadPublishProperties telemetry event. Properties collected here need to be synchronized with SDK telemetry documentation at https://github.com/dotnet/sdk/blob/main/documentation/project-docs/telemetry.md.

No PII—only boolean configuration flags.

Original prompt

Issue: Add publish-time telemetry for key WebAssembly/Blazor config properties (dotnet/runtime Wasm SDK targets)

Repo/area: dotnet/runtime — src/mono/nuget/Microsoft.NET.Sdk.WebAssembly.Pack/build/Microsoft.NET.Sdk.WebAssembly.Browser.targets
Motivation: We want visibility into which major WASM publish configuration knobs are actually being used in the wild (globalization mode, boot config shape, fingerprinting and preload behavior, bundler friendliness), to guide defaults, compatibility decisions, and performance work.

Properties to capture (publish scenarios)

Please add publish-time telemetry that captures the effective values (after defaults/normalization where applicable) for:

• InvariantTimezone
• InvariantGlobalization
• BlazorWebAssemblyLoadAllGlobalizationData
• WasmEnableWebcil
• WasmInlineBootConfig
• OverrideHtmlAssetPlaceholders
• WasmFingerprintBootConfig
• WasmPreloadAssets
• WasmBundlerFriendlyBootConfig

Notes on where they appear / are derived in the targets:

• InvariantTimezone is set based on BlazorEnableTimeZoneSupport (when tz support is disabled, timezone becomes invariant).
• InvariantGlobalization + BlazorWebAssemblyLoadAllGlobalizationData drive ICU/globalization behavior (and warnings/validation).
• WasmEnableWebcil controls DLL → WebCIL conversion and affects publish asset composition.
• WasmInlineBootConfig, WasmFingerprintBootConfig, OverrideHtmlAssetPlaceholders, WasmPreloadAssets, and WasmBundlerFriendlyBootConfig control boot config format and static web asset fingerprinting/preload behavior.
• Several of these are normalized to internal _Wasm* properties in _ResolveWasmConfiguration (e.g., _WasmEnableWebcil, _WasmInlineBootConfig, _WasmFingerprintBootConfig, _WasmPreloadAssets, _WasmBundlerFriendlyBootConfig). Telemetry should prefer the normalized/effective values.

When to emit

• Emit telemetry on publish, not build.
• Ideal hook point is after publish inputs are finalized (e.g., after ProcessPublishFilesForWasm / GeneratePublishWasmBootJson, or simply AfterTargets="Publish" if values are already stable).
• Ensure it does not run during nested publish scenarios if those are not representative (consider Condition="'$(WasmBuildingForNestedPublish)' != 'true'").

Event shape / requirements

• Use the SDK’s MSBuild telemetry mechanism (the CLI side typically forwards only allow-listed events), so either:
  • reuse an existing allow-listed event name if appropriate, or
  • coordinate adding a new allow-listed event name so it is not dropped.
• Payload should be key/value pairs for the properties above, using the effective values (e.g., _WasmPreloadAssets rather than raw WasmPreloadAssets when defaults apply).

Acceptance criteria

• Telemetry is emitted once per publish (non-nested publish) for WASM projects using this targets file.
• Captures the nine properties listed above as strings (true/false/null as applicable).
• Verified via a test or local reproduction that the event is produced and includes these keys.
• No PII is collected (these are feature/config flags only).

If you want, I can also suggest a concrete event name and the exact MSBuild target placement in this file that minimizes duplicate events (nested publish) and ensures values are fully resolved.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[maraf]

@copilot Include UseMonoRuntime property in the telemetry

[Copilot]

@copilot Include UseMonoRuntime property in the telemetry

Added UseMonoRuntime property to telemetry in commit 8b200cd.

[dotnet-policy-service]

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

[maraf]

@copilot Add a comment that this needs to be synchronized with docs at https://github.com/dotnet/sdk/blob/main/documentation/project-docs/telemetry.md

[Copilot]

Added comment linking to SDK telemetry documentation in commit e8dd483.

[github-actions]

Code Review: Add publish-time telemetry for WebAssembly/Blazor config properties

Verdict: LGTM 👍

Summary

This PR adds WASM-specific publish telemetry by:

1. Making WorkloadTelemetryDependsOn extensible in WorkloadTelemetry.targets
2. Adding a _GatherWasmPublishTelemetry target in Microsoft.NET.Sdk.WebAssembly.Browser.targets that populates WorkloadPublishProperties items with WASM configuration values

Analysis

Architecture & Design ✅
The extensibility approach via WorkloadTelemetryDependsOn is a standard MSBuild pattern. The new target hooks in cleanly without modifying the existing _WorkloadTelemetry target's item declarations.

Correctness ✅

• _MonoWorkloadTargetsMobile is set for browser-wasm (line 90 of WorkloadManifest.targets.in), so WorkloadTelemetry.targets is imported and _WorkloadTelemetry fires for WASM scenarios.
• The internal properties (_WasmInvariantGlobalization, _WasmEnableWebcil, etc.) are all set inside _ResolveWasmConfiguration, which runs as part of the publish pipeline via ProcessPublishFilesForWasm (AfterTargets="ILLink"). Since _WorkloadTelemetry runs AfterTargets="Publish", these properties are guaranteed to be resolved before _GatherWasmPublishTelemetry reads them.
• The WasmBuildingForNestedPublish guard correctly prevents duplicate telemetry during nested publish invocations, consistent with other guards in the file (e.g., ProcessPublishFilesForWasm).
• No duplicate Include values between the new items and the existing ones in _WorkloadTelemetry.

Property evaluation ordering ✅
The WorkloadTelemetryDependsOn property is composed during evaluation:

• WorkloadTelemetry.targets prepends _WorkloadGatherTelemetryData
• Browser.targets appends _GatherWasmPublishTelemetry
• DependsOnTargets="$(WorkloadTelemetryDependsOn)" is resolved at execution time, so it picks up the full chain regardless of import order.

No issues found. The change is minimal, well-targeted, and follows established patterns in the telemetry infrastructure.

Generated by Code Review for issue #123534 · ◷