Trigger msbuild target when hot reload detects Razor file change (Blazor)

[MisterGoodcat]

I'm using .NET 6.0.100-preview.5.21302.13 and Blazor Server.

I am trying to integrate a CSS framework (tailwind/postcss) with hot reload. My approach is to extend my project file with custom targets to trigger the CSS pre-compile. For scoped CSS this actually works great: I inspect and process the generated scoped files after the target "_GenerateScopedCssFiles" is completed.

When a .razor file is edited though, I cannot seem to find an msbuild target that I can attach my custom logic to as before/after target. I grepped through a verbose log created from "dotnet build" to identify something suitable but no success.

What exactly happens during hot reload when a .razor file changes? Is there some msbuild targets involved at all? The verbose output of "dotnet watch" does not give any clues.

My workaround currently is to run a separate watcher (here: tailwind CLI) for these files, and let "dotnet watch" then process the resulting static CSS.

[pranavkm]

Thanks for the issue report @MisterGoodcat. A lot of what makes hot reload fast is doing work as part of the compiler (using source generators) and avoiding invoking MSBuild. At one point, we were exploring the possibility of moving generating the scoped css too in to the compiler to avoid invoking MSBuild, although that is currently shelved.

To answer your question, no MSBuild is involved on changes to .razor files during hot reload. https://github.com/dotnet/sdk/tree/main/src/BuiltInTools/dotnet-watch#compiled-files-cs-razor-cshtml goes over some of the mechanics of how this works if you are interested. At this point, using a separate watcher would be the recommended way to go.

[MisterGoodcat]

Thank you @pranavkm for the answer. I somehow missed the documentation on hot reload until now, that was an interesting read. It's kind of obvious, but it never occurred to me that hot reload also needs to enable libraries to refresh caches or type information and other things. Is the use of MetadataUpdateHandlerAttribute encouraged also for application code? For example, for performance reasons we cache type information obtained by reflection in some custom features in larger apps. It seems that would be a good candidate to allow hot reload edits on those types when we move to .NET 6 at some point.

[pranavkm]

Is the use of MetadataUpdateHandlerAttribute encouraged also for application code

Yup definitely. We would like libraries and app authors to use this as a way to clear and reconstruct their reflection caches.

Thank you for contacting us. Due to a lack of activity on this discussion issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.

This issue will be locked after 30 more days of inactivity. If you still wish to discuss this subject after then, please create a new issue!