The problem:

In Visual studio I created a Mapped folder - Layouts. In it I have subfolders and one of them is js (full with javascript files). In that folder I have the scripts.js file. I include this file in the masterpage and deploy the project - the file loads ok and is accessable (no problems there). Then I needed to make changes to it and added them. When I deployed (full deploy) those changes are not there (it still loads the old content).

Additional info:

-All the paths to the file are ok and the correct file is loaded.

-No cache involved (I deleted it) - still the same.

-SharePoint is 2013, VS 2013 as well (if that could matter).

Edit 1:

I went to the file system ..../15/.../js and found the file. It is the latest version with the changes. I rechecked the paths in the master page and the cache - the problem is not there.

I used the design manager to create the masterpage from html. Could this cause such problems.

Any ideas?

4 Answers 4


Caching on SharePoint is a tricky thing. I have also experienced this behaviour, when the file was refreshed on the filesystem, I could see the changes in it if I opened it on the server, but web browsers were retrieving the old (chached) version, even if I pressed CTRL+F5.

Later edit: I have experienced this odd caching even if we performed IISRESET during the deployment of the new files. It was simply independent of the server, it was the cache of each and every user's browser. We could have either sent out a communication, that they should clear their cache or press CTRL+F5, but that would have seemed pretty unprofessional from the IT department. We also analyzed the possibility of creating a policy which would force everyones browser to clear its cache, but the network team objected, that this would cause an unnecesary and high traffic, because thousand of users would download again the files from the servers, and most of those haven't even changed. Cuasing all the fuss just for one or two files out of 15-20 was not making sense. End of later edit

Fortunately, there is a simple solution to this: whenever you change a js, css or even an image file, add a diferent revision number to its URL. For example:

Version 1 --> <script src="/_layouts/js/script.js?v=1"></script>

Version 2 --> <script src="/_layouts/js/script.js?v=2"></script>

You can add anything in the querystring, it can be a hash of the file, a guid, just make sure that it will be different whenever the file changes. (And it would be nice if you would make sure that the query string changes only when the content of the file really changes, else you force the browser to retrieve the file from the server fot nothing). Sharepoint is already doing this. If you observe the corev4.css or sp.js references, they all have a revision number in the querystring.

You can obtain this revision number easily by using a method in SPUtility, which works only for files on the file system (which is your case) which generates a correct revision number for the referenced files. Please check SPUtility.MakeBrowserCacheSafeLayoutsUrl and this other stackexchange post for more details.

Later edit: as it seems from some of the comments in the linked post, MakeBrowserCacheSafeLayoutsUrl is not always working as expected. I haven't used it in production yet, so I can't confirm or deny this. But we have succesfully used version numbers in production environment, the version being generated via a script during build by TFS. But you can also update the version by hand whenever you change the content. And this is guaranteed to work everytime, no need to clear the browser cache, and it works for both files on the file system and the content database (like references from style library)

  • Your neglecting the fact that yes that is fine but you have to also once again cause an issreset for the token to be sent again! using this method would as you said send a new number version but unless you do an issreset it will still send the old token not the new! so back to square one! so any time you update the js file you need to reset so the server gets the new token! thats not good on live servers!!! or production when you have tight time to test! clearing the browser cache is the best option as it doesnt effect any user!
    – Ali Jafer
    Commented Jan 28, 2014 at 10:33
  • 1
    Usually when you deploy WSPs to production (which is the only way to refresh files under _layouts) you also do an IISRESET. But without changing the version in the querystring, there is no guarantee that new version of the files will be taken. Telling users that they should hit CTRL+F5 or they should clear browser cache, is not desirable in most organizations: you want your deployments be as invisible as possible, trying not to make any noise about it :)
    – Norbert
    Commented Jan 28, 2014 at 10:40
  • Maybe my answer is not clear enough, I will modify it to make sure what I really meant.
    – Norbert
    Commented Jan 28, 2014 at 10:41
  • but your wrong! as an example, my project is fine(wsp) but i only need to make some ammendments to the js file... that means when i update the file on the server i have to do an iisreset... doing crtl +f5 is not always the case its browser dependant. Once the browser is closed then it picks up the new js anyway rather than an iisreset in a business is a big no no on live servers unless you want users to lose page and any process that could be happning at that given time!doing an iisreset should not be an option unless its on a dev server or out of hours!
    – Ali Jafer
    Commented Jan 28, 2014 at 11:07
  • btw im not saying your solution is wrong! just that you need todo an iisreset to get the new token to register! this happens anyway when your upgrading or deploying a wsp! which needs to be done out of hours or duing down time!
    – Ali Jafer
    Commented Jan 28, 2014 at 11:10

You need to do IISReset and it will load the new JS file.. Also make sure you press Ctrl + F5 on browser for complete reload..

PS: Please make sure you perform IISReset in off business hours (if in Production).. If its development environment, you are good to go..

  • doing an iisreset should not be an option unless its on a dev server or out of hours!
    – Ali Jafer
    Commented Jan 28, 2014 at 10:41
  • 1
    Let the questioner decide that @aliSharepoint Commented Jan 28, 2014 at 11:11
  • its not a matter of let the questioner decide, its fact and bad practice todo an iisreset during uptime! that is very very bad advice and annoyed/upset customers if on live!
    – Ali Jafer
    Commented Jan 28, 2014 at 11:14
  • 2
    Just coz it annoys customers in your company, doesn't mean that's the case everywhere.. Plus the questioner never mentioned it was live environment, I have updated my answer to replicate this Commented Jan 28, 2014 at 11:18
  • what you do in dev reflects on production and live! if your company uses the product on production and they are doing some calculation or adding forms or what not youll lose it as youve done an iisrest! thats why iv said its bad! plus you should get it right on the dev server ready for live, what if you hit the same issue?
    – Ali Jafer
    Commented Jan 28, 2014 at 11:23

Right Click on Internet Explorer and Select In Private Browsing. It will make sure latest .js files are loaded.

  • not all versions of ie have this!
    – Ali Jafer
    Commented Jan 28, 2014 at 9:48
  • Which versions don't have it. IE 10, IE 11 have it. Since @Gesh is using SP 2013. I assume he may be using IE 10 or IE 11 and both have it. Commented Jan 28, 2014 at 9:53
  • ie 9 i dont think, ie8 and below dont... just beacuse your using sp2013 doesnt mean that youll be using ie10+, i hate it! companies are slow at upgrading or reluctant to upgrade even tho its a requirement!
    – Ali Jafer
    Commented Jan 28, 2014 at 10:04
  • Personally speaking I have found "In private browsing" much better than doing ctrl +f5, clearing cache or issrest simply because it is much faster than other options when it comes to working in dev environment. Moreover, you are sure that you are using latest .js files. Commented Jan 28, 2014 at 10:32
  • yes your right if it existed for all browsers! unfortunatly its only for new!
    – Ali Jafer
    Commented Jan 28, 2014 at 10:36

its not the masterpage as the masterpage only stores the url location of the js file! and its not the location of the js files themselfs! As you noted they are updated correctly! You could do an iisreset but that is over the top especially if its on a live server or on a test server thats used internally! the issue lies with the browser as all are correct appart from seeing the old js within the browser! I usualy hit ctrl + f5 as that usually works to fully refresh the page. If its still cashing the js than you need to go into developer tools (f12) for ie or firebug ect and clear the browser cashe:

tools -> developer tools (f12) -> wait for it to load -> under html tab you should see a box with a red x witin bottom right.. click that and reload page using ctrl + f5

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.