`dotnet watch run` should refresh the browser window when static files are changed

[DamianEdwards]

Add support for dotnet watch run to refresh the browser window when changes to static files are detected.

• Default set of static files watched should include: *.css, *.js, *.jpg, *.png, *.gif
• Static files to watch should be configurable via existing mechanism in MSBuild (i.e. <Watch /> item type and watch item metadata)
• When changes to configured static files are detected the browser should have the content cache for the current app cleared via the Clear-Site-Data header before being refreshed
  • Note this capability needs to be investigated to determine its utility and applicability to this feature, along with the best way to incorporate it, e.g. as a separate Fetch request to the app site before the refresh, or as an added response header to the next HTML response from the site after a change is detected.
• The different actions performed by dotnet watch run when changes to different files are detected should be represented via MSBuild metadata like the file watch list itself, e.g. build and refresh browser, build only, refresh browser only, dynamically swap out image/CSS (future), etc. This will allow for customization by the user for more advanced scenarios along with different defaults for different app models (e.g. Blazor component CSS must be rebuilt due to the CSS isolation feature)
  • Approach 1, different metadata attribute per action:

    <Content Include="**/*.css" Watch="true" OnWatchChangeBuild="False" OnWatchChangeRefreshBrowser="True"  />

  • Approach 2, single metadata attribute but multiple values:

    <Content Include="**/*.css" Watch="true" OnWatchChange="RefreshBrowser;SomethingElse"  />

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[RickStrahl]

Regarding Refreshing non-HTML content there are some odd browser behaviors that AFAIK can't be worked around due to the way the caching works.

This isn't a solution, but some observations I've found in my Live Reload component (using the same mechanism):

• Static HTML File changes are detected and will auto-refresh, so that works fine typically
• CSS, Image and sometimes script files will often not refresh the very first time they are changed
• These files will auto-refresh after an initial hard refresh has occurred

I've tried all sorts of things including explicit browser force refresh and delay refreshing, but none of that worked reliably to get a CSS file for example to refresh the very first time it is changed. However, after a one-time manual refresh the same CSS file will auto-refresh. This doesn't make sense but it seems to be the consistent behavior seen in all browsers.

According to Eric Lawrence who chimed in on a tweet from @DamianEdwards this appears to be due to the way the cache is set up for related resources which doesn't monitor file changes. The odd thing is that it works after a manual refresh.

One hacky solution might be to explicitly and separately load the CSS file in the browser with a cache busting URL first, and then refresh the page with the plain URL.

[pranavkm]

We've added support for this as part of 6.0. Reloading css files uses a combination of using cache busting urls and the Clear-Site-Data header to do it's best.