views:

1327

answers:

6

We are actively developing a website using .Net and MVC and our testers are having fits trying to get the latest stuff to test. Every time we modify the style sheet or external javascript files, testers need to do a hard refresh (ctrl+F5 in IE) in order to see the latest stuff.

Is it possible for me to force their browsers to get the latest version of these files instead of them relying on their cached versions? We're not doing any kind of special caching from IIS or anything.

Once this goes into production, it will be hard to tell clients that they need to hard refresh in order to see the latest changes.

Thanks!

+7  A: 

You need to modify the names of the external files you refer to. For e.g. add the build number at the end of each file, like style-1423.css and make the numbering a part of your build automation so that the files and the references are deployed with a unique name each time.

Serhat Özgel
But how to change ASPX sources automatically to use correct names of external files?
Alexander Prokofyev
It can easily be done by a post build script. Just write a script or a trivial piece of code that looks for *.css or *.js files and renames them and run it after each build. If you have build automation, you can automatically add this script at the end of each build.
Serhat Özgel
+2  A: 

What you might do is to call your JS file with a random string each time the page refresh. This way you are sure it's always fresh.

You just need to call it this way "/path/to/your/file.js?<random-number>"

Example: jquery-min-1.2.6.js?234266

Erick
My only problem with this is that it will never be cached in this scenario. I'd like it to be cached if it hasn't been modified. OrbMan's solution seems to be spot on.
Chris Conway
True. You can also pass via a constant that you change each iteration. Both works very well.
Erick
+1  A: 

In your references to CSS and Javascript files, append a version query string. Bump it everytime you update the file. This will be ignored by the web site, but web browsers will treat it as a new resource and re-load it.

For example:

<link href="../../Themes/Plain/style.css?v=1" rel="stylesheet" type="text/css" />
<script src="../../Scripts/site.js?v=1" type="text/javascript"></script>
DSO
+6  A: 

Rather than a build number or random number, append the last-modified date of the file to the URL as querystring programmatically. This will prevent any accidents where you forget to modify the querystring manually, and will allow the browser to cache the file when it has not changed.

Example output could look like this:

<script src="../../Scripts/site.js?v=20090503114351" type="text/javascript"></script>
RedFilter
A fine idea, if you can devise a way to avoid the perf impact of querying the file attributes of every referenced file on every request.
DSO
Performance impact is pretty much nil, the OS caches that information. If it is a real concern, you can cache the info for 5 seconds or so.
RedFilter
Alternately you can append the last modified date during your build process, that will completely mitigate any performance impact, and prevent the chance of human error in forgetting to modify the file manually.
RedFilter
+1  A: 

you could edit the http headers of the files to force the browsers to revalidate on each request

Ozzy
+4  A: 

Since you mention only your testers complaining, Have you considered having them turn off their local browser cache, so that it checks every time for new content? It will slow their browsers a touch... but unless you are doing usability testing every time, this is probably a whole lot easier than postfixing the filename, adding a querystring param, or modifying the headers.

This works in 90% of the cases in our test environments.

Chad Ruppert
I second this. Your testers should be using closed environments, so it should be easy to configure an environment to either not use caching or "reset" itself, a la virtual machine.
Jeff Meatball Yang
This is not only a problem in a test environment (although that may be the most immediate concern for the OP). When you update a production site, you have to deal with users' browsers that have cached the old version of css/js files.
DSO
For now it only affects our testers. My concern is that it will affect live users once we go to production and we make modifications after it's live.
Chris Conway