Aspnetcore: If browser cache is not disabled during development, updates don't always appear on page refresh

Created on 25 Mar 2018  路  16Comments  路  Source: dotnet/aspnetcore

Ran through the get started sample. One thing I ran into was when I went to do the ToDo list portion I did not initially see the ToDo list nav link in the nav menu when I rendered the page. The browser was caching the first hit so removing the cached browser history allowed the todo list nav link to show up. I am using latest Chrome as the browser. I guess there is a question about cache busting here??

area-blazor

Most helpful comment

OK, it turns out we just weren't returning the correct cache-control header value.

This is now fixed in the code in dev, but if your browser has already cached old resources then you'll need to do a one-time manual clear of your browser cache to get rid of the old ones. Or in the case of Firefox, simply waiting for several hours seems to be sufficient, as its default behavior was to cache the application/octet-stream responses for something like 3 hours. After that, the caching should behave correctly (i.e., when files have changed the browser should get them immediately, and when not, it should get back a "304 Not Modified" response from the server). You should do this manual cache clearing after updating to the next version of Blazor of course. We intend to release 0.2.0 early next week.

Longer term, it would be good if our publishing process generated content-hashed URLs. Then we wouldn't need the browser to check for Etag-based modifications at all. It could just cache all compiled-file responses forever and not check with the server at all.

All 16 comments

I see similar behaviour. Run counter component sample, then change the _increase value step_ to i.e. 2 and run sample again. It will always go with += 1 and won't pick the changes unless the browser cache is disabled.

Is there any workaround for this? It is very annoying :( I have to stop the debugging and start over again in order for my changes to reflect on the screen. Ctrl+R is not working.

@miroslavp Why don't you simply disable browser caching for the time being?

Blazor currently does not supporting debugging and running under the debugger will actually cause issues when using Chrome. For now you should run without the debugger (Ctrl-F5) and refresh the browser as needed.

@danroth27 I was not running under the debugger.

@MihaMarkic Which browser and version are you using?

@danroth27 Using current Firefox x64 59.0.2 on Windows. Currently, if I enable browser caching I get this error when refreshing:

Error: System.TypeLoadException: Could not find method due to a type load error

If I disable caching, then it works. So I can't even repro the original issue. I'm quite sure it wasn't updating the sample as well (without disabling cache).

These are packages I'm using

<ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Razor.Design" Version="2.1.0-preview2-30230" PrivateAssets="all" />
    <PackageReference Include="Microsoft.AspNetCore.Blazor.Browser" Version="0.1.0" PrivateAssets="all" />
    <PackageReference Include="Microsoft.AspNetCore.Blazor.Build" Version="0.1.0" />
    <PackageReference Include="Righthand.Immutable" Version="1.0.2" />
    <PackageReference Include="Righthand.SharpRedux" Version="1.0.3" />
    <PackageReference Include="System.Threading.Tasks.Dataflow" Version="4.8.0" />
    <DotNetCliToolReference Include="Microsoft.AspNetCore.Blazor.Cli" Version="0.1.0" />
  </ItemGroup>

@MihaMarkic What is the target framework for the Blazor project?

<PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <RunCommand>dotnet</RunCommand>
    <RunArguments>blazor serve</RunArguments>
    <LangVersion>7.2</LangVersion>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Razor.Design" Version="2.1.0-preview2-30230" PrivateAssets="all" />
    <PackageReference Include="Microsoft.AspNetCore.Blazor.Browser" Version="0.1.0" PrivateAssets="all" />
    <PackageReference Include="Microsoft.AspNetCore.Blazor.Build" Version="0.1.0" />
    <PackageReference Include="Righthand.Immutable" Version="1.0.2" />
    <PackageReference Include="Righthand.SharpRedux" Version="1.0.3" />
    <PackageReference Include="System.Threading.Tasks.Dataflow" Version="4.8.0" />
    <DotNetCliToolReference Include="Microsoft.AspNetCore.Blazor.Cli" Version="0.1.0" />
  </ItemGroup>

You're target framework looks fine.

So I can't even repro the original issue

Yeah, without a repro there's not much we can do here, but if you see this problem again, please do let us know.

@danroth27 While I can't repro the original issue, I can repro that it doesn't even load now when cache is enabled. Btw I'm using Release config and Ctrl+F5 to start.

@danroth27 Here, I've made a video for you. First refresh is with cache enabled, second is with cache disabled.

I think we need to look into why our static-file serving isn't producing the correct Etag headers, or if it is, what other cache-control headers are needed to get the correct cache invalidation behavior.

I'm not sure if my issue falls under the same category but I have to remove my bin/ and obj/ folder after each change and rebuild.

This is my setup:

  • .NET CLI 2.1.300-preview1-008174
  • Visual Studio Code Version 1.21.1
  • macOS 10.13.3

I tried the blazorhosted template

OK, it turns out we just weren't returning the correct cache-control header value.

This is now fixed in the code in dev, but if your browser has already cached old resources then you'll need to do a one-time manual clear of your browser cache to get rid of the old ones. Or in the case of Firefox, simply waiting for several hours seems to be sufficient, as its default behavior was to cache the application/octet-stream responses for something like 3 hours. After that, the caching should behave correctly (i.e., when files have changed the browser should get them immediately, and when not, it should get back a "304 Not Modified" response from the server). You should do this manual cache clearing after updating to the next version of Blazor of course. We intend to release 0.2.0 early next week.

Longer term, it would be good if our publishing process generated content-hashed URLs. Then we wouldn't need the browser to check for Etag-based modifications at all. It could just cache all compiled-file responses forever and not check with the server at all.

Was this page helpful?
0 / 5 - 0 ratings