[Mvc][Blazor] Update static web assets design to account for additional scenarios added over time

[javiercn]

• Blazor WASM
• Blazor Desktop
• CSS isolation
• PWAs
• Root project not being the "top level" project.

Over the past two years we've added a lot of features on top of static web assets without the design having the right concepts for those. As a result we have added additional MSBuild code to workaround limitations in the current design and have paid the price in additional time for developing each feature.

With the new work we are doing in 6.0 this is again taking place. Instead of pushing through, we are at a breaking point where it will be better to pay-off technical debt now and improve the existing design with the primitives we need. Here are a few of the items we need to consider:

• Generate and persist a list to track static web assets during build.
  • Due to the many combinations of --no-build, --no-dependencies implementing features where assets are computed during build is really hard to get right.
  • Examples of these are implementing the service-worker-assets manifest for PWAs and scoped CSS bundles.
  • We can simplify this by making sure we persist a list of assets at the end of the project build and use that list in other situations like publish --no-build or when a parent project calls GetReferencedProjectStaticWebAssets.
• Build and Publish time assets: We don't have the ability to distinguish between the two and this ends up causing issues with things like Blazor linked assemblies or the service-worker.js file.
  • The assets that we produce during build might be completely different than the ones we produce during publish and we should account for that.
• We don't have a first class concept for assets that are computed as part of the build like Blazor dlls, or scoped css files and as a result when we build features that involve them we end up having to add them to certain item groups at different points in the build, which makes it really hard to reason about it across all the multiple build combinations.
• Assets that are specific to the project and assets that should only be copied when referenced from a parent project. An example of this is the bundle.scp.css file that we generate with the scoped css files for a project should only be copied to the output folder when it is not the top-level project like on a razor class library.
  • We need the ability to declare that some file needs to be considered an asset only when the project is being referenced by another project.
  • The oposite is also true, we don't need to copy the transitive CSS bundle when the project is just being referenced by another project.
• Ability to force a project becoming the transitive closure root of the dependency graph:
  • In the past we always had a top level project (Wasm, Web) that was at the top level of the "project dependency graph". With Blazor Desktop that's not the case and we need to do additional work to make this work, changing the behavior in all places that matter.

The goal here is to make sure we update the static web assets design to include the necessary improvements to support all the features we've added without those features having to deeply know about static web assets.

Our goal should be that outside the razor SDK (Blazor, Desktop, CSS isolation, etc) we should be able to declare static web assets once and have the system do the right thing across build, publish, pack, and different combinations (NoBuild, NoDependencies, DeplyOnBuild).

Ideally, any feature built on top should only require to declare the static web assets with the correct shape and have static web assets handle the rest transparently across build, publish, pack, etc.

[ghost]

Thanks for contacting us.

We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.