So I had this strange issue today when I deployed an application that was designed in such a way that all of its javascript is stored in external .js files, as opposed to embedding it directly in the page.  I made some pretty heavy changes to the external .js files.

Everything worked great in both the local development environment and the staging environment.  But when I deployed to the production environment, the client-side functionality was not working properly.

I deployed and redeployed, but there was no change.  I looked at the javascript file on the production file system, and it reflected the changes.  But when I viewed the source of the javascript file in the web browser, I could see that none of my updates were reflected.

My first thought was to recycle the application pool, but that didn’t work.  Then I attempted to do an IISRESET.  That DIDN’T WORK either!!!

I went in and deleted my temporary internet files TWICE, and finally the updates were reflected.  I realize that javascript files are supposed to be cached, but I needed my changes to show up.

For the rest of the day, my users were complaining that the application was no longer working.  My instructions to delete the temporary internet files seemed to work in most cases, but I didn’t need my users to have to deal with that.

This is not an issue I typically deal with, because I usually embed my Javascript directly in the web page.  This is only an issue with script references to external .js files, and perhaps it is by design, because in most cases you want your external javascript references to be cached and load super fast!

I did some research and discovered that if you append the javascript file with a unique querystring, it will force the browser to retrieve the latest version of the file.  Some folks on the forums recommend appending the script reference with a date time value so that it is always unique, forcing the browser to always retrieve the latest version.

http://scripts/GMConsultantBench.js?version=%=System.DateTime.Now.ToString()%20%

I don’t fully agree with that approach, because for the most part, I want my .js files to cache. But I would like to control when an update occurs.

I recommend versioning your javascript so that for the most part it remains cache, but when you make an update, you can increment the version number to break through the cache just one time.

http://scripts/GMConsultantBench.js?version=1.0

Or, even better, you can set it to a unique GUID that you store in your web.config and just update the version in the web.config when you deploy an update.  Anyway, you get the idea!

Advertisements