WebResource.axd won't update

Question

first time here. I hope this question makes sense:

We have a library of common controls, and I'm attempting to steer towards using embedded resources in it for images, JS, and CSS. It seems that upon each deploy to TEST/PROD, there is a window of time where WebResource.axd is returning a 404. After that window of time expires, suddenly the page starts serving out content properly. On my local DEV machine it seems that there are times when I can compile and reload a page that is using embedded resources, and it immediately shows a difference. Other times it responds like there is a cache waiting to expire.

Things I've tried:
- browsing from different machines to rule out local caching
- iisreset
- net stop w3svc
- delete temp files from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files and C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
- killing the inetinfo.exe process
- killing the w3wp.exe process
- disabling IIS Output Caching
- copying the URL and adding in an extra false querystring parameter to mimic a new page request
- pressing Ctrl-F5 :)

It seems rebooting fixes the issue.

My google kung-fu has diluted results filled with everyone's answer to check the namespace. I am confident the namespace is correct. After a while the resource will start serving out properly and the correct version. And if it DOES serve at some point, it seems logical to me that the namespace must be correct.

Answer 1

Its probably a datetime issue, Check the date/time on the target server. I have a target server that is in NY and i am having similar problems.

Answer 2

I apologize for not coming back to post an answer forever ago... Here is the solution I found:

http://jamesnearn.blogspot.com/2011/08/webresourceaxd-returns-404-and-then.html

The short answer is, I compiled in Eastern time zone, deployed to a server in Central time zone. After an hour, the issue resolved itself. My hack solution is to use touch.exe from UnxUtils http://unxutils.sourceforge.net/ to change the DLL's date and then the site works like normal. :)