[wasm] Fix ReferenceNewAssembly rebuild test: driver-gen.c regeneration and stale-native comparison

[pavelsavara]

Fixes#130540

This PR fixes Wasm.Build.NativeRebuild.Tests.ReferenceNewAssemblyRebuildTest.ReferenceNewAssembly, which had two independent problems: the AOT case (driver-gen.c not regenerated) and, once that was fixed, the relink case (dotnet.native.wasm size mismatch against a stale published file).

Fix 1 — driver-gen.c not regenerated (AOT case)

Problem

ReferenceNewAssembly(config: Release, aot: True, ...) fails deterministically with:

CompareStat failed:
[Expected changed file: driver-gen.c]

Root cause

driver-gen.c is the AOT modules table, written by MonoAOTCompiler.GenerateAotModulesTable via Utils.CopyIfDifferent(..., useHash: false). It is only rewritten (its timestamp bumped) when the content differs. The content is the ordered list of mono_aot_module__info symbols — i.e. the set of AOT-compiled assemblies.

The test replaces Common/Program.cs with NativeRebuildNewAssembly.cs, which used System.Security.Cryptography (SHA256), expecting that to add a new assembly to the AOT set so driver-gen.c would be regenerated.

However, WasmBasicTestAppalready pulls System.Security.Cryptography into its closure in both builds, via HttpTest.cs ([JSExport]HttpClient → System.Net.Http → crypto) and ZipArchiveInteropTest.cs (System.IO.Compression → crypto, added by #122093). So the AOT assembly set is identical before and after the change, driver-gen.c content is byte-identical, CopyIfDifferent leaves the old timestamp, and the unchanged: false assertion for driver-gen.c fails.

Fix

NativeRebuildNewAssembly.cs now additionally references System.Text.RegularExpressions (Regex), which is not otherwise part of the app's closure (verified: it is absent from the actual failing build's AOT list, and no other source in WasmBasicTestApp uses it). The rebuild therefore genuinely adds a new AOT module, driver-gen.c is regenerated, and the assertion passes. A framework assembly was chosen (rather than a local ProjectReference) because it is simply never pulled in the first build when unused, making it reliably absent. The original crypto usage is kept as-is.

Fix 2 — stale published dotnet.native.wasm picked in the relink case

Problem

With Fix 1 in place, the AOT case passes, but the relink case (aot: False, invariant: False) then fails:

File sizes don't match for
obj/.../wasm/for-publish/dotnet.native.wasm (3066497)
publish/wwwroot/_framework/dotnet.native.r26owxu9r7.wasm (3066264)

This looked flaky (the Windows leg passed while Linux failed), but it is deterministic — it depends on the alphabetical order of two content-hash fingerprints.

Root cause

The test publishes twice into the samewwwroot/_framework:

1. FirstNativeBuildAndRun publishes the baseline app → dotnet.native.<fpA>.wasm.
2. Rebuild (now genuinely referencing a new assembly) relinks dotnet.native.wasm to a larger, differently-fingerprinted file → dotnet.native.<fpB>.wasm, copied into the same directory.

_PublishCopyStaticWebAssetsPreserveNewest never deletes the first publish's fingerprinted copy, so both files coexist. ProjectProviderBase.FindAndAssertDotnetFiles globbed dotnet.*, consumed both matches, and kept the alphabetically-last one — which could be the stale first-publish file — then compared it against the freshly relinked obj output, producing the size mismatch. This latent test-infra bug was previously masked because the test failed earlier (Fix 1) before the relink assertion ran.

Fix

When multiple fingerprinted variants of the same logical file are present, FindAndAssertDotnetFiles now keeps the newest one by last-write time. The rebuild always writes a newer timestamp (guaranteed by the existing 5s delay in NativeRebuildTestsBase.Rebuild), so the assertion reliably compares against the current build output.

Validation

All five ReferenceNewAssembly cases pass locally against a Mono browser-wasm Release build with workloads:

Wasm.Build.Tests Total: 5, Errors: 0, Failed: 0, Skipped: 0

Note

This PR description and change were generated with the assistance of GitHub Copilot.

[Copilot]

Pull request overview

This PR adjusts a WASM native rebuild test asset so that the “rebuild introduces a new referenced assembly” scenario actually changes the AOT-compiled assembly set, ensuring driver-gen.c is regenerated during the rebuild path.

Changes:

• Add a System.Text.RegularExpressions usage (Regex.IsMatch) to the rebuild entrypoint so the rebuild reliably pulls in an additional framework assembly.
• Add a clarifying comment explaining why the extra reference is needed for the test’s native-artifact change expectations.

[pavelsavara]

Regression attribution

The regression was introduced by #122093 ("Add Zip Archives password support", commit 0174483, merged 2026-07-09), which added a new dependency to System.IO.Compression:

<ProjectReferenceInclude="...System.Security.Cryptography\src\System.Security.Cryptography.csproj" />

WasmBasicTestApp uses ZipArchiveInteropTest.cs (System.IO.Compression, [JSExport]-rooted — it's in the app's AOT closure), so after that change the app now transitively pulls System.Security.Cryptography into its closure in both the first build and the rebuild. The ReferenceNewAssembly test replaced Program.cs to use SHA256 expecting that to add a new AOT module; with crypto already present, the AOT assembly set is identical before/after, driver-gen.c (written via CopyIfDifferent) keeps its timestamp, and the unchanged: false assertion fails.

Timeline confirms it: the Known Build Error first matched on 2026-07-11 (~1.5 days after #122093 merged on 07-09), as a single continuous failure period.

#122093 is a legitimate product change (zip encryption genuinely needs crypto), so the correct fix is on the test side — reference an assembly (System.Text.RegularExpressions) that is genuinely outside the app closure — rather than reverting it.

Note

This comment was generated with the assistance of GitHub Copilot.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[pavelsavara]

Fixes#130540

This PR fixes Wasm.Build.NativeRebuild.Tests.ReferenceNewAssemblyRebuildTest.ReferenceNewAssembly, which had two independent problems: the AOT case (driver-gen.c not regenerated) and, once that was fixed, the relink case (dotnet.native.wasm size mismatch against a stale published file).

Fix 1 — driver-gen.c not regenerated (AOT case)

Problem

ReferenceNewAssembly(config: Release, aot: True, ...) fails deterministically with:

CompareStat failed:
[Expected changed file: driver-gen.c]

Root cause

driver-gen.c is the AOT modules table, written by MonoAOTCompiler.GenerateAotModulesTable via Utils.CopyIfDifferent(..., useHash: false). It is only rewritten (its timestamp bumped) when the content differs. The content is the ordered list of mono_aot_module__info symbols — i.e. the set of AOT-compiled assemblies.

The test replaces Common/Program.cs with NativeRebuildNewAssembly.cs, which used System.Security.Cryptography (SHA256), expecting that to add a new assembly to the AOT set so driver-gen.c would be regenerated.

However, WasmBasicTestAppalready pulls System.Security.Cryptography into its closure in both builds, via HttpTest.cs ([JSExport]HttpClient → System.Net.Http → crypto) and ZipArchiveInteropTest.cs (System.IO.Compression → crypto, added by #122093). So the AOT assembly set is identical before and after the change, driver-gen.c content is byte-identical, CopyIfDifferent leaves the old timestamp, and the unchanged: false assertion for driver-gen.c fails.

Fix

NativeRebuildNewAssembly.cs now additionally references System.Text.RegularExpressions (Regex), which is not otherwise part of the app's closure (verified: it is absent from the actual failing build's AOT list, and no other source in WasmBasicTestApp uses it). The rebuild therefore genuinely adds a new AOT module, driver-gen.c is regenerated, and the assertion passes. A framework assembly was chosen (rather than a local ProjectReference) because it is simply never pulled in the first build when unused, making it reliably absent. The original crypto usage is kept as-is.

Fix 2 — stale published dotnet.native.wasm picked in the relink case

Problem

With Fix 1 in place, the AOT case passes, but the relink case (aot: False, invariant: False) then fails:

File sizes don't match for
obj/.../wasm/for-publish/dotnet.native.wasm (3066497)
publish/wwwroot/_framework/dotnet.native.r26owxu9r7.wasm (3066264)

This looked flaky (the Windows leg passed while Linux failed), but it is deterministic — it depends on the alphabetical order of two content-hash fingerprints.

Root cause

The test publishes twice into the samewwwroot/_framework:

1. FirstNativeBuildAndRun publishes the baseline app → dotnet.native.<fpA>.wasm.
2. Rebuild (now genuinely referencing a new assembly) relinks dotnet.native.wasm to a larger, differently-fingerprinted file → dotnet.native.<fpB>.wasm, copied into the same directory.

_PublishCopyStaticWebAssetsPreserveNewest never deletes the first publish's fingerprinted copy, so both files coexist. ProjectProviderBase.FindAndAssertDotnetFiles globbed dotnet.*, consumed both matches, and kept the alphabetically-last one — which could be the stale first-publish file — then compared it against the freshly relinked obj output, producing the size mismatch. This latent test-infra bug was previously masked because the test failed earlier (Fix 1) before the relink assertion ran.

Fix

When multiple fingerprinted variants of the same logical file are present, FindAndAssertDotnetFiles now keeps the newest one by last-write time. The rebuild always writes a newer timestamp (guaranteed by the existing 5s delay in NativeRebuildTestsBase.Rebuild), so the assertion reliably compares against the current build output.

Validation

All five ReferenceNewAssembly cases pass locally against a Mono browser-wasm Release build with workloads:

Wasm.Build.Tests Total: 5, Errors: 0, Failed: 0, Skipped: 0

Note

This PR description and change were generated with the assistance of GitHub Copilot.

[Copilot]

Pull request overview

This PR adjusts a WASM native rebuild test asset so that the “rebuild introduces a new referenced assembly” scenario actually changes the AOT-compiled assembly set, ensuring driver-gen.c is regenerated during the rebuild path.

Changes:

• Add a System.Text.RegularExpressions usage (Regex.IsMatch) to the rebuild entrypoint so the rebuild reliably pulls in an additional framework assembly.
• Add a clarifying comment explaining why the extra reference is needed for the test’s native-artifact change expectations.

[pavelsavara]

Regression attribution

The regression was introduced by #122093 ("Add Zip Archives password support", commit 0174483, merged 2026-07-09), which added a new dependency to System.IO.Compression:

<ProjectReferenceInclude="...System.Security.Cryptography\src\System.Security.Cryptography.csproj" />

WasmBasicTestApp uses ZipArchiveInteropTest.cs (System.IO.Compression, [JSExport]-rooted — it's in the app's AOT closure), so after that change the app now transitively pulls System.Security.Cryptography into its closure in both the first build and the rebuild. The ReferenceNewAssembly test replaced Program.cs to use SHA256 expecting that to add a new AOT module; with crypto already present, the AOT assembly set is identical before/after, driver-gen.c (written via CopyIfDifferent) keeps its timestamp, and the unchanged: false assertion fails.

Timeline confirms it: the Known Build Error first matched on 2026-07-11 (~1.5 days after #122093 merged on 07-09), as a single continuous failure period.

#122093 is a legitimate product change (zip encryption genuinely needs crypto), so the correct fix is on the test side — reference an assembly (System.Text.RegularExpressions) that is genuinely outside the app closure — rather than reverting it.

Note

This comment was generated with the assistance of GitHub Copilot.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[pavelsavara]

Fixes#130540

This PR fixes Wasm.Build.NativeRebuild.Tests.ReferenceNewAssemblyRebuildTest.ReferenceNewAssembly, which had two independent problems: the AOT case (driver-gen.c not regenerated) and, once that was fixed, the relink case (dotnet.native.wasm size mismatch against a stale published file).

Fix 1 — driver-gen.c not regenerated (AOT case)

Problem

ReferenceNewAssembly(config: Release, aot: True, ...) fails deterministically with:

CompareStat failed:
[Expected changed file: driver-gen.c]

Root cause

driver-gen.c is the AOT modules table, written by MonoAOTCompiler.GenerateAotModulesTable via Utils.CopyIfDifferent(..., useHash: false). It is only rewritten (its timestamp bumped) when the content differs. The content is the ordered list of mono_aot_module__info symbols — i.e. the set of AOT-compiled assemblies.

The test replaces Common/Program.cs with NativeRebuildNewAssembly.cs, which used System.Security.Cryptography (SHA256), expecting that to add a new assembly to the AOT set so driver-gen.c would be regenerated.

However, WasmBasicTestAppalready pulls System.Security.Cryptography into its closure in both builds, via HttpTest.cs ([JSExport]HttpClient → System.Net.Http → crypto) and ZipArchiveInteropTest.cs (System.IO.Compression → crypto, added by #122093). So the AOT assembly set is identical before and after the change, driver-gen.c content is byte-identical, CopyIfDifferent leaves the old timestamp, and the unchanged: false assertion for driver-gen.c fails.

Fix

NativeRebuildNewAssembly.cs now additionally references System.Text.RegularExpressions (Regex), which is not otherwise part of the app's closure (verified: it is absent from the actual failing build's AOT list, and no other source in WasmBasicTestApp uses it). The rebuild therefore genuinely adds a new AOT module, driver-gen.c is regenerated, and the assertion passes. A framework assembly was chosen (rather than a local ProjectReference) because it is simply never pulled in the first build when unused, making it reliably absent. The original crypto usage is kept as-is.

Fix 2 — stale published dotnet.native.wasm picked in the relink case

Problem

With Fix 1 in place, the AOT case passes, but the relink case (aot: False, invariant: False) then fails:

File sizes don't match for
obj/.../wasm/for-publish/dotnet.native.wasm (3066497)
publish/wwwroot/_framework/dotnet.native.r26owxu9r7.wasm (3066264)

This looked flaky (the Windows leg passed while Linux failed), but it is deterministic — it depends on the alphabetical order of two content-hash fingerprints.

Root cause

The test publishes twice into the samewwwroot/_framework:

1. FirstNativeBuildAndRun publishes the baseline app → dotnet.native.<fpA>.wasm.
2. Rebuild (now genuinely referencing a new assembly) relinks dotnet.native.wasm to a larger, differently-fingerprinted file → dotnet.native.<fpB>.wasm, copied into the same directory.

_PublishCopyStaticWebAssetsPreserveNewest never deletes the first publish's fingerprinted copy, so both files coexist. ProjectProviderBase.FindAndAssertDotnetFiles globbed dotnet.*, consumed both matches, and kept the alphabetically-last one — which could be the stale first-publish file — then compared it against the freshly relinked obj output, producing the size mismatch. This latent test-infra bug was previously masked because the test failed earlier (Fix 1) before the relink assertion ran.

Fix

When multiple fingerprinted variants of the same logical file are present, FindAndAssertDotnetFiles now keeps the newest one by last-write time. The rebuild always writes a newer timestamp (guaranteed by the existing 5s delay in NativeRebuildTestsBase.Rebuild), so the assertion reliably compares against the current build output.

Validation

All five ReferenceNewAssembly cases pass locally against a Mono browser-wasm Release build with workloads:

Wasm.Build.Tests Total: 5, Errors: 0, Failed: 0, Skipped: 0

Note

This PR description and change were generated with the assistance of GitHub Copilot.

[Copilot]

Pull request overview

This PR adjusts a WASM native rebuild test asset so that the “rebuild introduces a new referenced assembly” scenario actually changes the AOT-compiled assembly set, ensuring driver-gen.c is regenerated during the rebuild path.

Changes:

• Add a System.Text.RegularExpressions usage (Regex.IsMatch) to the rebuild entrypoint so the rebuild reliably pulls in an additional framework assembly.
• Add a clarifying comment explaining why the extra reference is needed for the test’s native-artifact change expectations.

[pavelsavara]

Regression attribution

The regression was introduced by #122093 ("Add Zip Archives password support", commit 0174483, merged 2026-07-09), which added a new dependency to System.IO.Compression:

<ProjectReferenceInclude="...System.Security.Cryptography\src\System.Security.Cryptography.csproj" />

WasmBasicTestApp uses ZipArchiveInteropTest.cs (System.IO.Compression, [JSExport]-rooted — it's in the app's AOT closure), so after that change the app now transitively pulls System.Security.Cryptography into its closure in both the first build and the rebuild. The ReferenceNewAssembly test replaced Program.cs to use SHA256 expecting that to add a new AOT module; with crypto already present, the AOT assembly set is identical before/after, driver-gen.c (written via CopyIfDifferent) keeps its timestamp, and the unchanged: false assertion fails.

Timeline confirms it: the Known Build Error first matched on 2026-07-11 (~1.5 days after #122093 merged on 07-09), as a single continuous failure period.

#122093 is a legitimate product change (zip encryption genuinely needs crypto), so the correct fix is on the test side — reference an assembly (System.Text.RegularExpressions) that is genuinely outside the app closure — rather than reverting it.

Note

This comment was generated with the assistance of GitHub Copilot.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[pavelsavara]

Fixes#130540

This PR fixes Wasm.Build.NativeRebuild.Tests.ReferenceNewAssemblyRebuildTest.ReferenceNewAssembly, which had two independent problems: the AOT case (driver-gen.c not regenerated) and, once that was fixed, the relink case (dotnet.native.wasm size mismatch against a stale published file).

Fix 1 — driver-gen.c not regenerated (AOT case)

Problem

ReferenceNewAssembly(config: Release, aot: True, ...) fails deterministically with:

CompareStat failed:
[Expected changed file: driver-gen.c]

Root cause

driver-gen.c is the AOT modules table, written by MonoAOTCompiler.GenerateAotModulesTable via Utils.CopyIfDifferent(..., useHash: false). It is only rewritten (its timestamp bumped) when the content differs. The content is the ordered list of mono_aot_module__info symbols — i.e. the set of AOT-compiled assemblies.

The test replaces Common/Program.cs with NativeRebuildNewAssembly.cs, which used System.Security.Cryptography (SHA256), expecting that to add a new assembly to the AOT set so driver-gen.c would be regenerated.

However, WasmBasicTestAppalready pulls System.Security.Cryptography into its closure in both builds, via HttpTest.cs ([JSExport]HttpClient → System.Net.Http → crypto) and ZipArchiveInteropTest.cs (System.IO.Compression → crypto, added by #122093). So the AOT assembly set is identical before and after the change, driver-gen.c content is byte-identical, CopyIfDifferent leaves the old timestamp, and the unchanged: false assertion for driver-gen.c fails.

Fix

NativeRebuildNewAssembly.cs now additionally references System.Text.RegularExpressions (Regex), which is not otherwise part of the app's closure (verified: it is absent from the actual failing build's AOT list, and no other source in WasmBasicTestApp uses it). The rebuild therefore genuinely adds a new AOT module, driver-gen.c is regenerated, and the assertion passes. A framework assembly was chosen (rather than a local ProjectReference) because it is simply never pulled in the first build when unused, making it reliably absent. The original crypto usage is kept as-is.

Fix 2 — stale published dotnet.native.wasm picked in the relink case

Problem

With Fix 1 in place, the AOT case passes, but the relink case (aot: False, invariant: False) then fails:

File sizes don't match for
obj/.../wasm/for-publish/dotnet.native.wasm (3066497)
publish/wwwroot/_framework/dotnet.native.r26owxu9r7.wasm (3066264)

This looked flaky (the Windows leg passed while Linux failed), but it is deterministic — it depends on the alphabetical order of two content-hash fingerprints.

Root cause

The test publishes twice into the samewwwroot/_framework:

1. FirstNativeBuildAndRun publishes the baseline app → dotnet.native.<fpA>.wasm.
2. Rebuild (now genuinely referencing a new assembly) relinks dotnet.native.wasm to a larger, differently-fingerprinted file → dotnet.native.<fpB>.wasm, copied into the same directory.

_PublishCopyStaticWebAssetsPreserveNewest never deletes the first publish's fingerprinted copy, so both files coexist. ProjectProviderBase.FindAndAssertDotnetFiles globbed dotnet.*, consumed both matches, and kept the alphabetically-last one — which could be the stale first-publish file — then compared it against the freshly relinked obj output, producing the size mismatch. This latent test-infra bug was previously masked because the test failed earlier (Fix 1) before the relink assertion ran.

Fix

When multiple fingerprinted variants of the same logical file are present, FindAndAssertDotnetFiles now keeps the newest one by last-write time. The rebuild always writes a newer timestamp (guaranteed by the existing 5s delay in NativeRebuildTestsBase.Rebuild), so the assertion reliably compares against the current build output.

Validation

All five ReferenceNewAssembly cases pass locally against a Mono browser-wasm Release build with workloads:

Wasm.Build.Tests Total: 5, Errors: 0, Failed: 0, Skipped: 0

Note

This PR description and change were generated with the assistance of GitHub Copilot.

[Copilot]

Pull request overview

This PR adjusts a WASM native rebuild test asset so that the “rebuild introduces a new referenced assembly” scenario actually changes the AOT-compiled assembly set, ensuring driver-gen.c is regenerated during the rebuild path.

Changes:

• Add a System.Text.RegularExpressions usage (Regex.IsMatch) to the rebuild entrypoint so the rebuild reliably pulls in an additional framework assembly.
• Add a clarifying comment explaining why the extra reference is needed for the test’s native-artifact change expectations.

[pavelsavara]

Regression attribution

The regression was introduced by #122093 ("Add Zip Archives password support", commit 0174483, merged 2026-07-09), which added a new dependency to System.IO.Compression:

<ProjectReferenceInclude="...System.Security.Cryptography\src\System.Security.Cryptography.csproj" />

WasmBasicTestApp uses ZipArchiveInteropTest.cs (System.IO.Compression, [JSExport]-rooted — it's in the app's AOT closure), so after that change the app now transitively pulls System.Security.Cryptography into its closure in both the first build and the rebuild. The ReferenceNewAssembly test replaced Program.cs to use SHA256 expecting that to add a new AOT module; with crypto already present, the AOT assembly set is identical before/after, driver-gen.c (written via CopyIfDifferent) keeps its timestamp, and the unchanged: false assertion fails.

Timeline confirms it: the Known Build Error first matched on 2026-07-11 (~1.5 days after #122093 merged on 07-09), as a single continuous failure period.

#122093 is a legitimate product change (zip encryption genuinely needs crypto), so the correct fix is on the test side — reference an assembly (System.Text.RegularExpressions) that is genuinely outside the app closure — rather than reverting it.

Note

This comment was generated with the assistance of GitHub Copilot.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[pavelsavara]

Fixes#130540

This PR fixes Wasm.Build.NativeRebuild.Tests.ReferenceNewAssemblyRebuildTest.ReferenceNewAssembly, which had two independent problems: the AOT case (driver-gen.c not regenerated) and, once that was fixed, the relink case (dotnet.native.wasm size mismatch against a stale published file).

Fix 1 — driver-gen.c not regenerated (AOT case)

Problem

ReferenceNewAssembly(config: Release, aot: True, ...) fails deterministically with:

CompareStat failed:
[Expected changed file: driver-gen.c]

Root cause

driver-gen.c is the AOT modules table, written by MonoAOTCompiler.GenerateAotModulesTable via Utils.CopyIfDifferent(..., useHash: false). It is only rewritten (its timestamp bumped) when the content differs. The content is the ordered list of mono_aot_module__info symbols — i.e. the set of AOT-compiled assemblies.

The test replaces Common/Program.cs with NativeRebuildNewAssembly.cs, which used System.Security.Cryptography (SHA256), expecting that to add a new assembly to the AOT set so driver-gen.c would be regenerated.

However, WasmBasicTestAppalready pulls System.Security.Cryptography into its closure in both builds, via HttpTest.cs ([JSExport]HttpClient → System.Net.Http → crypto) and ZipArchiveInteropTest.cs (System.IO.Compression → crypto, added by #122093). So the AOT assembly set is identical before and after the change, driver-gen.c content is byte-identical, CopyIfDifferent leaves the old timestamp, and the unchanged: false assertion for driver-gen.c fails.

Fix

NativeRebuildNewAssembly.cs now additionally references System.Text.RegularExpressions (Regex), which is not otherwise part of the app's closure (verified: it is absent from the actual failing build's AOT list, and no other source in WasmBasicTestApp uses it). The rebuild therefore genuinely adds a new AOT module, driver-gen.c is regenerated, and the assertion passes. A framework assembly was chosen (rather than a local ProjectReference) because it is simply never pulled in the first build when unused, making it reliably absent. The original crypto usage is kept as-is.

Fix 2 — stale published dotnet.native.wasm picked in the relink case

Problem

With Fix 1 in place, the AOT case passes, but the relink case (aot: False, invariant: False) then fails:

File sizes don't match for
obj/.../wasm/for-publish/dotnet.native.wasm (3066497)
publish/wwwroot/_framework/dotnet.native.r26owxu9r7.wasm (3066264)

This looked flaky (the Windows leg passed while Linux failed), but it is deterministic — it depends on the alphabetical order of two content-hash fingerprints.

Root cause

The test publishes twice into the samewwwroot/_framework:

1. FirstNativeBuildAndRun publishes the baseline app → dotnet.native.<fpA>.wasm.
2. Rebuild (now genuinely referencing a new assembly) relinks dotnet.native.wasm to a larger, differently-fingerprinted file → dotnet.native.<fpB>.wasm, copied into the same directory.

_PublishCopyStaticWebAssetsPreserveNewest never deletes the first publish's fingerprinted copy, so both files coexist. ProjectProviderBase.FindAndAssertDotnetFiles globbed dotnet.*, consumed both matches, and kept the alphabetically-last one — which could be the stale first-publish file — then compared it against the freshly relinked obj output, producing the size mismatch. This latent test-infra bug was previously masked because the test failed earlier (Fix 1) before the relink assertion ran.

Fix

When multiple fingerprinted variants of the same logical file are present, FindAndAssertDotnetFiles now keeps the newest one by last-write time. The rebuild always writes a newer timestamp (guaranteed by the existing 5s delay in NativeRebuildTestsBase.Rebuild), so the assertion reliably compares against the current build output.

Validation

All five ReferenceNewAssembly cases pass locally against a Mono browser-wasm Release build with workloads:

Wasm.Build.Tests Total: 5, Errors: 0, Failed: 0, Skipped: 0

Note

This PR description and change were generated with the assistance of GitHub Copilot.

[Copilot]

Pull request overview

This PR adjusts a WASM native rebuild test asset so that the “rebuild introduces a new referenced assembly” scenario actually changes the AOT-compiled assembly set, ensuring driver-gen.c is regenerated during the rebuild path.

Changes:

• Add a System.Text.RegularExpressions usage (Regex.IsMatch) to the rebuild entrypoint so the rebuild reliably pulls in an additional framework assembly.
• Add a clarifying comment explaining why the extra reference is needed for the test’s native-artifact change expectations.

[pavelsavara]

Regression attribution

The regression was introduced by #122093 ("Add Zip Archives password support", commit 0174483, merged 2026-07-09), which added a new dependency to System.IO.Compression:

<ProjectReferenceInclude="...System.Security.Cryptography\src\System.Security.Cryptography.csproj" />

WasmBasicTestApp uses ZipArchiveInteropTest.cs (System.IO.Compression, [JSExport]-rooted — it's in the app's AOT closure), so after that change the app now transitively pulls System.Security.Cryptography into its closure in both the first build and the rebuild. The ReferenceNewAssembly test replaced Program.cs to use SHA256 expecting that to add a new AOT module; with crypto already present, the AOT assembly set is identical before/after, driver-gen.c (written via CopyIfDifferent) keeps its timestamp, and the unchanged: false assertion fails.

Timeline confirms it: the Known Build Error first matched on 2026-07-11 (~1.5 days after #122093 merged on 07-09), as a single continuous failure period.

#122093 is a legitimate product change (zip encryption genuinely needs crypto), so the correct fix is on the test side — reference an assembly (System.Text.RegularExpressions) that is genuinely outside the app closure — rather than reverting it.

Note

This comment was generated with the assistance of GitHub Copilot.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[pavelsavara]

Fixes#130540

This PR fixes Wasm.Build.NativeRebuild.Tests.ReferenceNewAssemblyRebuildTest.ReferenceNewAssembly, which had two independent problems: the AOT case (driver-gen.c not regenerated) and, once that was fixed, the relink case (dotnet.native.wasm size mismatch against a stale published file).

Fix 1 — driver-gen.c not regenerated (AOT case)

Problem

ReferenceNewAssembly(config: Release, aot: True, ...) fails deterministically with:

CompareStat failed:
[Expected changed file: driver-gen.c]

Root cause

driver-gen.c is the AOT modules table, written by MonoAOTCompiler.GenerateAotModulesTable via Utils.CopyIfDifferent(..., useHash: false). It is only rewritten (its timestamp bumped) when the content differs. The content is the ordered list of mono_aot_module__info symbols — i.e. the set of AOT-compiled assemblies.

The test replaces Common/Program.cs with NativeRebuildNewAssembly.cs, which used System.Security.Cryptography (SHA256), expecting that to add a new assembly to the AOT set so driver-gen.c would be regenerated.

However, WasmBasicTestAppalready pulls System.Security.Cryptography into its closure in both builds, via HttpTest.cs ([JSExport]HttpClient → System.Net.Http → crypto) and ZipArchiveInteropTest.cs (System.IO.Compression → crypto, added by #122093). So the AOT assembly set is identical before and after the change, driver-gen.c content is byte-identical, CopyIfDifferent leaves the old timestamp, and the unchanged: false assertion for driver-gen.c fails.

Fix

NativeRebuildNewAssembly.cs now additionally references System.Text.RegularExpressions (Regex), which is not otherwise part of the app's closure (verified: it is absent from the actual failing build's AOT list, and no other source in WasmBasicTestApp uses it). The rebuild therefore genuinely adds a new AOT module, driver-gen.c is regenerated, and the assertion passes. A framework assembly was chosen (rather than a local ProjectReference) because it is simply never pulled in the first build when unused, making it reliably absent. The original crypto usage is kept as-is.

Fix 2 — stale published dotnet.native.wasm picked in the relink case

Problem

With Fix 1 in place, the AOT case passes, but the relink case (aot: False, invariant: False) then fails:

File sizes don't match for
obj/.../wasm/for-publish/dotnet.native.wasm (3066497)
publish/wwwroot/_framework/dotnet.native.r26owxu9r7.wasm (3066264)

This looked flaky (the Windows leg passed while Linux failed), but it is deterministic — it depends on the alphabetical order of two content-hash fingerprints.

Root cause

The test publishes twice into the samewwwroot/_framework:

1. FirstNativeBuildAndRun publishes the baseline app → dotnet.native.<fpA>.wasm.
2. Rebuild (now genuinely referencing a new assembly) relinks dotnet.native.wasm to a larger, differently-fingerprinted file → dotnet.native.<fpB>.wasm, copied into the same directory.

_PublishCopyStaticWebAssetsPreserveNewest never deletes the first publish's fingerprinted copy, so both files coexist. ProjectProviderBase.FindAndAssertDotnetFiles globbed dotnet.*, consumed both matches, and kept the alphabetically-last one — which could be the stale first-publish file — then compared it against the freshly relinked obj output, producing the size mismatch. This latent test-infra bug was previously masked because the test failed earlier (Fix 1) before the relink assertion ran.

Fix

When multiple fingerprinted variants of the same logical file are present, FindAndAssertDotnetFiles now keeps the newest one by last-write time. The rebuild always writes a newer timestamp (guaranteed by the existing 5s delay in NativeRebuildTestsBase.Rebuild), so the assertion reliably compares against the current build output.

Validation

All five ReferenceNewAssembly cases pass locally against a Mono browser-wasm Release build with workloads:

Wasm.Build.Tests Total: 5, Errors: 0, Failed: 0, Skipped: 0

Note

This PR description and change were generated with the assistance of GitHub Copilot.

[Copilot]

Pull request overview

This PR adjusts a WASM native rebuild test asset so that the “rebuild introduces a new referenced assembly” scenario actually changes the AOT-compiled assembly set, ensuring driver-gen.c is regenerated during the rebuild path.

Changes:

• Add a System.Text.RegularExpressions usage (Regex.IsMatch) to the rebuild entrypoint so the rebuild reliably pulls in an additional framework assembly.
• Add a clarifying comment explaining why the extra reference is needed for the test’s native-artifact change expectations.

[pavelsavara]

Regression attribution

The regression was introduced by #122093 ("Add Zip Archives password support", commit 0174483, merged 2026-07-09), which added a new dependency to System.IO.Compression:

<ProjectReferenceInclude="...System.Security.Cryptography\src\System.Security.Cryptography.csproj" />

WasmBasicTestApp uses ZipArchiveInteropTest.cs (System.IO.Compression, [JSExport]-rooted — it's in the app's AOT closure), so after that change the app now transitively pulls System.Security.Cryptography into its closure in both the first build and the rebuild. The ReferenceNewAssembly test replaced Program.cs to use SHA256 expecting that to add a new AOT module; with crypto already present, the AOT assembly set is identical before/after, driver-gen.c (written via CopyIfDifferent) keeps its timestamp, and the unchanged: false assertion fails.

Timeline confirms it: the Known Build Error first matched on 2026-07-11 (~1.5 days after #122093 merged on 07-09), as a single continuous failure period.

#122093 is a legitimate product change (zip encryption genuinely needs crypto), so the correct fix is on the test side — reference an assembly (System.Text.RegularExpressions) that is genuinely outside the app closure — rather than reverting it.

Note

This comment was generated with the assistance of GitHub Copilot.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[pavelsavara]

Fixes#130540

This PR fixes Wasm.Build.NativeRebuild.Tests.ReferenceNewAssemblyRebuildTest.ReferenceNewAssembly, which had two independent problems: the AOT case (driver-gen.c not regenerated) and, once that was fixed, the relink case (dotnet.native.wasm size mismatch against a stale published file).

Fix 1 — driver-gen.c not regenerated (AOT case)

Problem

ReferenceNewAssembly(config: Release, aot: True, ...) fails deterministically with:

CompareStat failed:
[Expected changed file: driver-gen.c]

Root cause

driver-gen.c is the AOT modules table, written by MonoAOTCompiler.GenerateAotModulesTable via Utils.CopyIfDifferent(..., useHash: false). It is only rewritten (its timestamp bumped) when the content differs. The content is the ordered list of mono_aot_module__info symbols — i.e. the set of AOT-compiled assemblies.

The test replaces Common/Program.cs with NativeRebuildNewAssembly.cs, which used System.Security.Cryptography (SHA256), expecting that to add a new assembly to the AOT set so driver-gen.c would be regenerated.

However, WasmBasicTestAppalready pulls System.Security.Cryptography into its closure in both builds, via HttpTest.cs ([JSExport]HttpClient → System.Net.Http → crypto) and ZipArchiveInteropTest.cs (System.IO.Compression → crypto, added by #122093). So the AOT assembly set is identical before and after the change, driver-gen.c content is byte-identical, CopyIfDifferent leaves the old timestamp, and the unchanged: false assertion for driver-gen.c fails.

Fix

NativeRebuildNewAssembly.cs now additionally references System.Text.RegularExpressions (Regex), which is not otherwise part of the app's closure (verified: it is absent from the actual failing build's AOT list, and no other source in WasmBasicTestApp uses it). The rebuild therefore genuinely adds a new AOT module, driver-gen.c is regenerated, and the assertion passes. A framework assembly was chosen (rather than a local ProjectReference) because it is simply never pulled in the first build when unused, making it reliably absent. The original crypto usage is kept as-is.

Fix 2 — stale published dotnet.native.wasm picked in the relink case

Problem

With Fix 1 in place, the AOT case passes, but the relink case (aot: False, invariant: False) then fails:

File sizes don't match for
obj/.../wasm/for-publish/dotnet.native.wasm (3066497)
publish/wwwroot/_framework/dotnet.native.r26owxu9r7.wasm (3066264)

This looked flaky (the Windows leg passed while Linux failed), but it is deterministic — it depends on the alphabetical order of two content-hash fingerprints.

Root cause

The test publishes twice into the samewwwroot/_framework:

1. FirstNativeBuildAndRun publishes the baseline app → dotnet.native.<fpA>.wasm.
2. Rebuild (now genuinely referencing a new assembly) relinks dotnet.native.wasm to a larger, differently-fingerprinted file → dotnet.native.<fpB>.wasm, copied into the same directory.

_PublishCopyStaticWebAssetsPreserveNewest never deletes the first publish's fingerprinted copy, so both files coexist. ProjectProviderBase.FindAndAssertDotnetFiles globbed dotnet.*, consumed both matches, and kept the alphabetically-last one — which could be the stale first-publish file — then compared it against the freshly relinked obj output, producing the size mismatch. This latent test-infra bug was previously masked because the test failed earlier (Fix 1) before the relink assertion ran.

Fix

When multiple fingerprinted variants of the same logical file are present, FindAndAssertDotnetFiles now keeps the newest one by last-write time. The rebuild always writes a newer timestamp (guaranteed by the existing 5s delay in NativeRebuildTestsBase.Rebuild), so the assertion reliably compares against the current build output.

Validation

All five ReferenceNewAssembly cases pass locally against a Mono browser-wasm Release build with workloads:

Wasm.Build.Tests Total: 5, Errors: 0, Failed: 0, Skipped: 0

Note

This PR description and change were generated with the assistance of GitHub Copilot.

[Copilot]

Pull request overview

This PR adjusts a WASM native rebuild test asset so that the “rebuild introduces a new referenced assembly” scenario actually changes the AOT-compiled assembly set, ensuring driver-gen.c is regenerated during the rebuild path.

Changes:

• Add a System.Text.RegularExpressions usage (Regex.IsMatch) to the rebuild entrypoint so the rebuild reliably pulls in an additional framework assembly.
• Add a clarifying comment explaining why the extra reference is needed for the test’s native-artifact change expectations.

[pavelsavara]

Regression attribution

The regression was introduced by #122093 ("Add Zip Archives password support", commit 0174483, merged 2026-07-09), which added a new dependency to System.IO.Compression:

<ProjectReferenceInclude="...System.Security.Cryptography\src\System.Security.Cryptography.csproj" />

WasmBasicTestApp uses ZipArchiveInteropTest.cs (System.IO.Compression, [JSExport]-rooted — it's in the app's AOT closure), so after that change the app now transitively pulls System.Security.Cryptography into its closure in both the first build and the rebuild. The ReferenceNewAssembly test replaced Program.cs to use SHA256 expecting that to add a new AOT module; with crypto already present, the AOT assembly set is identical before/after, driver-gen.c (written via CopyIfDifferent) keeps its timestamp, and the unchanged: false assertion fails.

Timeline confirms it: the Known Build Error first matched on 2026-07-11 (~1.5 days after #122093 merged on 07-09), as a single continuous failure period.

#122093 is a legitimate product change (zip encryption genuinely needs crypto), so the correct fix is on the test side — reference an assembly (System.Text.RegularExpressions) that is genuinely outside the app closure — rather than reverting it.

Note

This comment was generated with the assistance of GitHub Copilot.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[pavelsavara]

Fixes#130540

This PR fixes Wasm.Build.NativeRebuild.Tests.ReferenceNewAssemblyRebuildTest.ReferenceNewAssembly, which had two independent problems: the AOT case (driver-gen.c not regenerated) and, once that was fixed, the relink case (dotnet.native.wasm size mismatch against a stale published file).

Fix 1 — driver-gen.c not regenerated (AOT case)

Problem

ReferenceNewAssembly(config: Release, aot: True, ...) fails deterministically with:

CompareStat failed:
[Expected changed file: driver-gen.c]

Root cause

driver-gen.c is the AOT modules table, written by MonoAOTCompiler.GenerateAotModulesTable via Utils.CopyIfDifferent(..., useHash: false). It is only rewritten (its timestamp bumped) when the content differs. The content is the ordered list of mono_aot_module__info symbols — i.e. the set of AOT-compiled assemblies.

The test replaces Common/Program.cs with NativeRebuildNewAssembly.cs, which used System.Security.Cryptography (SHA256), expecting that to add a new assembly to the AOT set so driver-gen.c would be regenerated.

However, WasmBasicTestAppalready pulls System.Security.Cryptography into its closure in both builds, via HttpTest.cs ([JSExport]HttpClient → System.Net.Http → crypto) and ZipArchiveInteropTest.cs (System.IO.Compression → crypto, added by #122093). So the AOT assembly set is identical before and after the change, driver-gen.c content is byte-identical, CopyIfDifferent leaves the old timestamp, and the unchanged: false assertion for driver-gen.c fails.

Fix

NativeRebuildNewAssembly.cs now additionally references System.Text.RegularExpressions (Regex), which is not otherwise part of the app's closure (verified: it is absent from the actual failing build's AOT list, and no other source in WasmBasicTestApp uses it). The rebuild therefore genuinely adds a new AOT module, driver-gen.c is regenerated, and the assertion passes. A framework assembly was chosen (rather than a local ProjectReference) because it is simply never pulled in the first build when unused, making it reliably absent. The original crypto usage is kept as-is.

Fix 2 — stale published dotnet.native.wasm picked in the relink case

Problem

With Fix 1 in place, the AOT case passes, but the relink case (aot: False, invariant: False) then fails:

File sizes don't match for
obj/.../wasm/for-publish/dotnet.native.wasm (3066497)
publish/wwwroot/_framework/dotnet.native.r26owxu9r7.wasm (3066264)

This looked flaky (the Windows leg passed while Linux failed), but it is deterministic — it depends on the alphabetical order of two content-hash fingerprints.

Root cause

The test publishes twice into the samewwwroot/_framework:

1. FirstNativeBuildAndRun publishes the baseline app → dotnet.native.<fpA>.wasm.
2. Rebuild (now genuinely referencing a new assembly) relinks dotnet.native.wasm to a larger, differently-fingerprinted file → dotnet.native.<fpB>.wasm, copied into the same directory.

_PublishCopyStaticWebAssetsPreserveNewest never deletes the first publish's fingerprinted copy, so both files coexist. ProjectProviderBase.FindAndAssertDotnetFiles globbed dotnet.*, consumed both matches, and kept the alphabetically-last one — which could be the stale first-publish file — then compared it against the freshly relinked obj output, producing the size mismatch. This latent test-infra bug was previously masked because the test failed earlier (Fix 1) before the relink assertion ran.

Fix

When multiple fingerprinted variants of the same logical file are present, FindAndAssertDotnetFiles now keeps the newest one by last-write time. The rebuild always writes a newer timestamp (guaranteed by the existing 5s delay in NativeRebuildTestsBase.Rebuild), so the assertion reliably compares against the current build output.

Validation

All five ReferenceNewAssembly cases pass locally against a Mono browser-wasm Release build with workloads:

Wasm.Build.Tests Total: 5, Errors: 0, Failed: 0, Skipped: 0

Note

This PR description and change were generated with the assistance of GitHub Copilot.

[Copilot]

Pull request overview

This PR adjusts a WASM native rebuild test asset so that the “rebuild introduces a new referenced assembly” scenario actually changes the AOT-compiled assembly set, ensuring driver-gen.c is regenerated during the rebuild path.

Changes:

• Add a System.Text.RegularExpressions usage (Regex.IsMatch) to the rebuild entrypoint so the rebuild reliably pulls in an additional framework assembly.
• Add a clarifying comment explaining why the extra reference is needed for the test’s native-artifact change expectations.

[pavelsavara]

Regression attribution

The regression was introduced by #122093 ("Add Zip Archives password support", commit 0174483, merged 2026-07-09), which added a new dependency to System.IO.Compression:

<ProjectReferenceInclude="...System.Security.Cryptography\src\System.Security.Cryptography.csproj" />

WasmBasicTestApp uses ZipArchiveInteropTest.cs (System.IO.Compression, [JSExport]-rooted — it's in the app's AOT closure), so after that change the app now transitively pulls System.Security.Cryptography into its closure in both the first build and the rebuild. The ReferenceNewAssembly test replaced Program.cs to use SHA256 expecting that to add a new AOT module; with crypto already present, the AOT assembly set is identical before/after, driver-gen.c (written via CopyIfDifferent) keeps its timestamp, and the unchanged: false assertion fails.

Timeline confirms it: the Known Build Error first matched on 2026-07-11 (~1.5 days after #122093 merged on 07-09), as a single continuous failure period.

#122093 is a legitimate product change (zip encryption genuinely needs crypto), so the correct fix is on the test side — reference an assembly (System.Text.RegularExpressions) that is genuinely outside the app closure — rather than reverting it.

Note

This comment was generated with the assistance of GitHub Copilot.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.