If you build with trimming enabled, future builds with it disabled will produce incorrect output

[kg]

Description

cc @radical

If I do an incremental build with EnableAggressiveTrimming=true, then do another one later with it =false after changing some .cs files, not everything is rebuilt so you get outputs that have type load failures and such, like so:

fail: console.error: Unhandled exception in _finalize_startup Error: System.TypeLoadException: Could not load type of field 'System.Runtime.InteropServices.JavaScript.Runtime:_boundObjects' (0) due to: Could not resolve type with token 01000012 from typeref

Obliterating my artifacts folder and then doing a full build is usually the fix for this.

Will come back and paste in my exact build command lines later once my rebuild is done.

Configuration

dotnet/runtime/main current as of today

Regression?

No

[ghost]

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

Issue Details

---

Description

cc @radical

If I do an incremental build with EnableAggressiveTrimming=true, then do another one later with it =false after changing some .cs files, not everything is rebuilt so you get outputs that have type load failures and such, like so:

fail: console.error: Unhandled exception in _finalize_startup Error: System.TypeLoadException: Could not load type of field 'System.Runtime.InteropServices.JavaScript.Runtime:_boundObjects' (0) due to: Could not resolve type with token 01000012 from typeref

Obliterating my artifacts folder and then doing a full build is usually the fix for this.

Will come back and paste in my exact build command lines later once my rebuild is done.

Configuration

dotnet/runtime/main current as of today

Regression?

No

Author:	kg
Assignees:	-
Labels:	arch-wasm
Milestone:	-

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[lewing]

@radical status on this?

[radical]

This issue is with local dotnet/runtime builds. Lower priority as compared to other issues, so haven't had a chance to look at this.

I'm working on incremental builds now, so after that we can see if this becomes a problem for user projects.

[lewing]

@radical is this fixed?

[radical]

@radical is this fixed?

No, this will be fixed after the publish->build changes. This one will need to copy the untrimmed assemblies to a single path, and use that for mono-aot-cross.

[radical]

There are two parts to the build here:

1. the assemblies getting built, and published
2. after publish, wasm generating the app bundle based on assemblies in publish/

I think the issue here is from (1).

• But there is a problem with switching from EAT/non-EAT, which is that the app bundle doesn't get cleared out.
• So, if you first built without trimming, then the bundle would have all the untrimmed assemblies.
  • And then you build with trimming, then the new trimmed assemblies just overwrite the older ones. But the completely trimmed out assemblies don't get removed.

This gets fixed in #57556 .

I couldn't reproduce the exact issue here, but that also might be because we recently added support for incremental wasm builds. So, we'll have to see if you hit this issue again, and then debug.

[radical]

Should be fixed by #58913 .