I’m having a real hard time with what seems to be a rather old bug (pre-2009) in the Windows Azure platform. In short, after deploying to Azure I get HTTP 404 responses for JavaScript resources loaded via WebResource.axd. This is a big deal since it breaks most of the AJAX functionality on the website. The interesting part is that things get normal about 2 hours after the deployment and the 404-ing resources start loading normally. And the event more interesting part is that the 404 errors don’t occur after each deployment.
After a lot of Googling around I found a similar case on the Azure forums. Yi-Lun Luo’s last post makes me think the problem in my case is related to the bug he describes. Maybe I’m wrong, but there seems to be a connection between the 2 hours it takes for the 404 errors to cease and the fact that my timezone is UTC +2.
Please, if anyone has had a similar problem or has an idea for a workaround, let me know. I would be really grateful!
We have run into this before on another project. It’s actually not an Azure problem at all, but rather a bug in how the WebResource.axd is loading the assemblies (roughly speaking). The problem is related to the timezone. If the binaries you are building and deploying are in a timezone “ahead” of the timezone you are running the code in then you will run into the problem you are seeing. We specifically ran into the issue when dealing with a control from Telerik. We reached out to Telerik for help and they had some suggestions on thier site.
Basically, you need to “touch” the assemblies you build so that the last modified date is a time prior to the current time in UTC. The link uses this syntax (note commas are important):
copy /b <path to assembly which is built in the future>+,,
The build server was in the Eastern Time zone and the production servers were in the Central Time zone. We would copy the binaries to the production box and perform the command above on them. You could mimick this in Azure with a startup task and that should do the trick.