Rationalize BlazorILLink incrementalism in hosted+VS+RID+publishing case #20413
Description
If all the following are true:
- You have a Blazor WebAssembly "hosted in ASP.NET Core" application
- You're performing a publish of the server project from inside VS (this doesn't repro with command-line publish)
- You are publishing with a specific RID (e.g.,
win-x64)
... then our _LinkBlazorApplication target tries to run more than once: first when VS builds the client project, then a second time during the server project build when SWA calls GetCurrentProjectStaticWebAssets.
The _LinkBlazorApplication has incrementalism checks, but it thinks the outputs are out-of-date because the client project's project.assets.json has been changed in between these two calls. Presumably this is something special to do with how VS does publish-with-RID.
This causes PWAs to break (see #19822) because:
- The linker produces nondeterministic output (or at least different output each time), hence files with different hashes
- The service worker asset manifest targets do successfully implement incrementalism, so the SWAM isn't regenerated, and it contains the hashes from the previous time the linker ran
Note that we can't fix this by making the SWAM get regenerated each time (i.e., remove or suppress its incrementalism) because during this type of publish flow, if you have a transitive reference from the client project to a RCL, the GetCurrentProjectStaticWebAssets on the client project runs in a context where it can't evaluate project references, so that target only outputs SWA entries for the client project, not the transitively-referenced RCL.
It's not clear what a desirable fix for this really would be, but we have a workaround in place and the issue may disappear in .NET 5 if the linker targets get integrated into the underlying non-Blazor-specific SDK so this all happens in a different order with different incrementalism rules.
cc @javiercn since we were discussing this