Blazor hot reload of scoped css loses referenced css

[uecasm]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

This may be a duplicate of #37592, except that was closed as fixed, and the bug is still present.

When running dotnet watch and editing a .razor.css file in the main application, it will "reload scoped css" but this discards CSS from referenced libraries.

Expected Behavior

All CSS should remain loaded.

Steps To Reproduce

1. Clone https://github.com/uecasm/HotReloadStyles.git
2. Launch with dotnet watch
3. Observe that, as expected, the scoped styles from both Index.razor.css in the main app and Component1.razor.css in the library have been merged, resulting in (including border, padding, and green background):
   
4. Simply re-save the Index.razor.css file without making any changes.
5. Observe that, not as expected, the Index.razor.css styles still apply but the Component1.razor.css styles have been lost (no border or padding but still green background):
   
6. Press Ctrl-R or relaunch dotnet watch and observe that all styles are loaded again.

Possibly also of note is that editing the Component1.razor.css file does update the styles if editing Index.razor.css has not yet unloaded them, but does not restore them after it has.

Exceptions (if any)

No response

.NET Version

6.0.300

Anything else?

.NET SDK (reflecting any global.json):
 Version:   6.0.300
 Commit:    8473146e7d

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19041
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\6.0.300\

Host (useful for support):
  Version: 6.0.5
  Commit:  70ae3df4a6

.NET SDKs installed:
  2.1.511 [C:\Program Files\dotnet\sdk]
  6.0.200 [C:\Program Files\dotnet\sdk]
  6.0.300 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

[uecasm]

It looks like the fundamental issue is that on a full build, the generated HotReloadStyles.styles.css file contains the following import automatically:

@import '_content/ClassLibrary/ClassLibrary.bundle.scp.css';

On triggering a hot-reload regeneration of this file, the @import is lost and it only shows the other content.

[uecasm]

Possibly also of note is that if I instead launch the app from VS2022 (17.2.3) and use the hot reload integration in that, it appears to reload correctly. (Although it does log Unknown payload: { "type": "Ping" } to the console.)

[javiercn]

@uecasm thanks for the additional details.

I suspect what's happening here is that the environment state is not correctly restored during hot reload. We should make scoped CSS load the build assets file to ensure that the referenced project files can be taken into account.

Thanks for contacting us.

We're moving this issue to the .NET 7 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.

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.