I ran two sample Blazor WebAssembly apps accidentally on same port at https://localhost:44381, then things are messed up. One of the apps is erroring out because it tried and failed to load DLLs from the other sample app. I tried going to browser's devtool Application > Clear storage, but no help. How do I totally clean out the DLLs of a Blazor WebAssembly app from browser so that I could start fresh again?
Blazor WASM applications from version 3.1 download a file blazor.boot.json which lists the assemblies along with a sha256 hash to indicate the version. These assemblies are now downloaded to the browser's Application Cache Storage (see example below).
Application -> Clear storage should work - check that Application cache is selected on the Application -> Clear storage page:
Using the Empty Cache and Hard Reload will not clear out this cache, but will reload the blazor.boot.json file, and if the cached files have changed (the hash is different) then they should be reloaded.
You can also clear out individual assemblies from the Cache Storage view - right-click and you can delete them. When you refresh the application, Blazor will download the latest version.
Chrome and the new Edge press F12. This opens the developer tools. Whilst this is open right click the refresh page Icon on the browser. On that menu choose empty cache and hard refresh. This is the only way to clear everything including icons and PWA settings.
Just press Ctrl+F5 it cleans cache and gets files again.
In your .csproj (for your wasm site) file you can force the app to download resources each time it's requested. Bit of a performance hit for the first load, but gets you over the current problem.
<PropertyGroup>
<BlazorCacheBootResources>false</BlazorCacheBootResources>
</PropertyGroup>
There are some caveats - see documentation here: https://learn.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/webassembly?view=aspnetcore-5.0#disable-integrity-checking-for-non-pwa-apps-1
Related
I have a Blazor WASM application using .Net Core 6, and all of the latest nuget packages, hosted using Azure App Services.
As per my understanding, the browser caches the application DLLs appending a sha256 hash code to the filename. The browser keeps the DLLs cached until it reads a new sha256 hash value on the blazor.boot.json, at which point it replaces the old DLL in the cache with a new one.
As per my observations, this works most of the time. If I look at my own browser application cache, using the dev tools, I will see the same version the DLL today, tomorrow, and the next day, as long as there hasn't been any deployments. Then, after a deployment, I open the application in my browser, go back to my cache, and without needing to manually clear anything or do anything out of the ordinary, I will see the DLL with an updated sha256 code.
However, every once in a while, this isnt the case. For example, I have a user, that rarely uses the development environment. The version of the application dll has been cached since august (2 months ago). Additionally, the contents of the blazor.boot.json correctly indicate the new version of the dll. But still, the old version, with a different SHA hash, remains in her cache.
I've seen this behavior before. I can't quite put my finger on what the difference is in the application changes that lead to successful automatic cache busting vs when the old cache continues to persist.
The simple solution is to have the user delete the entire blazor-resources group of dll's to force a new download. However, as we expand the footprint of the app to new users, I don't want to have to ask them to clear their application cache as we are deploying new versions of the code.
Given this example, it seems the failure is somewhere between the retrieval of the updated blazor.boot.json and whatever standard javascript runs to retrieve the new DLLs, which I believe is in the service-worker.js.
Any assistance regarding:
An explanation of why this might be happening (so that I can reliably reproduce the issue and have a valid test case after it's been fixed)
What code/configuration I may be able to force the DLL download... not on every refresh of the app, but at least when the SHA hash has changed.
Thanks,
Mike
I've built a Microsoft Teams channel tab with SSO and I'm hosting the tab application which I've built with React via create-react-app.
The auth works well, and the app loads and runs.
But when I update my app on the web site, the Teams desktop client (Mac and PC) will sometimes cache the old app and will not pick up the changes. But then sometimes it will.
If I run the web client, it usually picks up the changes.
I've verified that I'm serving up new bundles with different names each time I update. But running the Teams desktop devtools I can see that Teams is asking for the old bundle, every time, so it's definitely caching the response from my app's URL.
I've read about the problems people have with the Teams desktop client has with caching Sharepoint content and not picking up content changes. I've tried the cache clearing techniques but they don't seem to work for this issue. And I can't reasonably have users do crazy cache clearing every time I make an update to the tab app.
What should I do? Some have suggested I need to update my version in the app manifest and redeploy to Teams -- that seems really brutal. Do I need to set some cache headers in a certain way to force the Teams client to pick up the new code?
Solution
Set a Cache-Control response header to no-cache (or must-revalidate) for your build/index.html.
Explanation
We had the exact same issue. Turns out it was because we cached our build/index.html.
According to the create-react-app doc, only the content of build/static/ can safely be cached, meaning build/index.html shouldn't be cached.
Why? Because files in build/static/ have a uniquely hashed name and are therefore cache busted on deployment. index.html is not.
What's happening is since Teams uses your old index.html, it tries to load the old /static/js/main.[hash].js defined in it, instead of your new JS bundle.
It works properly in the Teams web client because most browsers send a Cache-Control: max-age=0 request header when requesting your index.html, ignoring any cache set for the file. Teams desktop doesn't as of today.
This seems like an issue with the way your app is managing the default browser caching logic. Are service workers enabled for your app? What cache control headers is your web server returning?
There are some great articles that describe all the cache controls available to you; for example:
https://medium.com/#codebyamir/a-web-developers-guide-to-browser-caching-cc41f3b73e7c
Have you tried doing something like this to prevent caching of your page (do note that long term you might want to use something like ETags which is a more performant option):
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#preventing_caching
P.S. You can also follow the instructions here to open the dev tools in the Desktop Client to debug all this:
(How) can I open the dev tools in the Microsoft Teams desktop client?
And even force clear any cached data/resources for your app:
I'm finding the iterative development cycle quite slow on service fabric as opposed to a standalone .NET Core web application. It does not look like browser link works, hell even refreshing the page doesn't update HTML. From what I can see, you need to restart the whole fabric to update HTML changes.
There has to be something I'm missing.
We have this feature in the pipeline. Will be a few months out, but is coming.
To enable quick iterations on static files and other files that do not need build time compilation, the current hack is to start debugging your app or deploy it to the cluster so it's running. Find the files in the cluster node directory (Typically C:\SfDevCluster\Data\_App\_Node_0\....) edit them there and refresh your browser. Remember to copy changes over to your source before stopping debugging or removing the app, as this will delete those files.
Make sure to set you local cluster in one-node mode, to ensure you only have the files being served from one directory.
Folks:
I'm creating an app using Node Webkit. The purpose of this app is to display images and pdfs. The app needs to download those files from a central repository, and cache them locally. When the app runs offline, the files should still be available, and displayed.
On the face of it, this sounds like appcache is the answer - and that indeed is where I was heading when this was a pure webapp in a browser. However, now I've discovered node-webkit, and here we are.
node-webkit's GitHub wiki states:
"However, application cache is designed for browser use, for apps using node-webkit, it's less useful than the other two method, read HTML5 Application Cache if you want to use it."
But doesn't say why.
I've also researched node.js filesystem - but that seems like a whole magnitude of complexity above what I need.
Can anyone point me in a sensible direction?
Thanks.
It has to do with the nature of App Cache itself.
You specify a manifest file that lists all the static assets required for your app to run offline. You don't have any programmatic access to the cache to add and remove files via JS.
So for a node-webkit app, it'd make more sense to fetch these files and store them in the Application Support folder (Or AppData, depending on the platform). That's where the node.js part is really useful, the file IO stuff.
I have a project that loads http://ajax.googleapis.com/ajax/libs/dojo/1.3.2/dojo/dojo.xd.js, I want to be able use this project offline
I tried to download dojo.xd.js and link to it locally but this still doesn't work offline
In firebug, on the net tab I can see that there are a lot more .js files that load
Is there a simple way of making this work offline?
The way of integration depends on your way of using it.
I assume you have webserver running locally (without inet access)?!
At the dojo website there are several ways of dojo integration available. Just download one of them (do not use CDN) and put the file on your local web server. Then it is available through the local url (can be relative to your site).
If you wan't to build an "offline" app without a webserver then take a look at Adobe AIR and interation of the dojo toolkit with Dojo Extensions for Adobe AIR.
Another option might be the integration together with PhoneGap or Cordova to build an offline App, e.g. for an IPhone etc. with HTML/Javascript. Win8/RT Applications for the M$ AppStore does support HTML/Javascript, too (have not tested this with Dojo).
Keep in mind there are also some security restrictions (e.g. loading and execution of JavaScript) if you plan to "release" your app as simple html file (click to open in browser).