WebResource.axd ne mettra pas à jour

Question

première fois ici. J'espère que cette question a du sens:

Nous avons une bibliothèque de contrôles communs, et j'essaie d'utiliser des ressources intégrées pour les images, JS et CSS. Il semble qu'à chaque déploiement sur TEST/PROD, il existe une fenêtre de temps où WebResource.axd renvoie un 404. Une fois cette fenêtre expirée, la page commence à diffuser le contenu correctement. Sur ma machine DEV locale, il semble qu'il y ait des moments où je peux compiler et recharger une page qui utilise des ressources intégrées, et cela montre immédiatement une différence. D'autres fois, il répond comme s'il y avait un cache en attente d'expiration.

choses que j'ai essayé:
- navigation de différentes machines à exclure la mise en cache locale
- iisreset
- net stop w3svc
- supprimer les fichiers temporaires du C: \ Windows \ Microsoft.NET \ \ Framework64 v4.0.30319 \ Temporary ASP.NET Files et C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET Files
- tuer le processus inetinfo.exe
- tuant le processus w3wp.exe
- désactivation de la mise en cache des sorties IIS
- copier l'URL et l'ajout d'un paramètre faux querystring supplémentaire pour imiter une nouvelle demande Page
- en appuyant sur Ctrl-F5 :)

Il semble redémarrant résout le problème.

Mon google kung-fu a dilué les résultats remplis avec la réponse de tout le monde pour vérifier l'espace de noms. Je suis confiant que l'espace de noms est correct. Après un certain temps, la ressource commencera à servir correctement et la version correcte. Et si ça sert à un moment donné, il me semble logique que l'espace de noms soit correct.

Answer 1

Je me excuse pour ne pas revenir à poster une réponse il y a toujours ... Voici la solution que je trouve:

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

La réponse courte est, je compilé dans la zone heure de l'Est, à un déploiement serveur dans le fuseau horaire central. Après une heure, le problème s'est résolu. Ma solution de piratage est d'utiliser touch.exe de UnxUtils http://unxutils.sourceforge.net/ pour changer la date de la DLL, puis le site fonctionne comme d'habitude. :)

Answer 2

Son probablement un problème datetime, Vérifiez la date/heure sur le serveur cible. J'ai un serveur cible qui est à New York et j'ai des problèmes similaires.