Clear caching of javascript in azure

Question

I'm sure this question has been asked before but I can't find one quite the same.

I have an azure cloud service that uses a lot of javascript files. I am still developing the site and so the javascript files change often. When the javascript files have changed I clear my browsing history, selecting 'Temporary Internet files and website files' before re-running the code. However, the website seems to resolutely hold on to my javascript files and keeps running the old code. This is a problem in Chrome, IE and Firefox. If I clear my browsing history a few times it eventually finds the new code.

I know that there are ways to force the browser to reload files by changing the path to the js files for new versions. However I am just testing and don't want to have to update file names each time I change a few lines of code. So I want a way to clear caches within the browser.

I am also using an html5 offline cache for my files so this may be an added complication.

How can I easily clear my old javascript files? Can I do this programmatically?

Answer 1

I have been down this path a few times and no matter what, with no exception, the method that works is adding a query string variable. This is why so many frameworks (eg, jquery, angular) will add a cache busting date based value to the query string for ajax). Every other method has resulted in one headache or another, browser inconsistencies, random errors because one file updated but the other didn't.

Here's one example I am currently using that is using Angular within ASP.NET:

@{
     var v = Request.IsLocal ? DateTime.Now.Ticks : ViewBag.Version;
 }

 <script>var version = "@v";
 <script src="/javascript_file.js?v=@v"></script>

I user a local variable (@v) to set a query string value on the file and I also use it to set up a global JavaScript variable that can be used within js for templates and other files.

If I am working locally, then I always get the latest version of each file. Once I deploy, the version number is set at application start up (using the build version for auto incrementing purposes - so that each deployed version build will have a different version number).

This has the downside that some files that DID NOT change will need to be reloaded, but that's better than trying to tell hundreds of users (hit f5 to reload the page)...

!I am not sure how this will impact offline cache, but I think the same might apply.