6
votes

ASP.NET AJAX Cadre côté client n'a pas réussi à charger

J'ai eu cette erreur:

Cadre côté client ASP.NET AJAX n'a ​​pas réussi à charger

avec l'erreur:

'SYS' est indéfini.

L'erreur qpppears dans IE en bas (message d'erreur) et apparaît uniquement lorsque j'exécute le site sur le serveur. sur mon localhost tout fonctionne bien.

J'ai déménagé pour un nouveau serveur et il y a le problème. Dans mon serveur précédent, tout allait bien.

Le problème vient du scriptManager de l'Ajax.

Qu'est-ce que je peux faire? quelque chose dans le web.config ou si la société hôte doit installer quelque chose quelque chose?

ASP.NET 4, IIS 7.5

Le triangle jaune laid sur l'IE n'est pas ce qui me dérange. Le gros problème est que le gestionnaire de script avec le panneau de mise à jour - ne fonctionne pas!


7 commentaires

Oui, rien ne fonctionne. Je me suis perdu sur la recherche. Peut-être que ce que Somone me donnera la bonne réponse.


J'ai eu ces erreurs aussi. Ne vous souvenez pas ce que la question était cependant. Vérification du web.config et que votre pool d'applications utilise réellement .NET 4 serait un bon début.


@Uwekeim - merci. que le premier pense que j'ai fait :(. Le triangle jaune laid sur l'IE n'est pas ce qui me dérange ... Le gros problème est que le gestionnaire de script avec le panneau de mise à jour - ne fonctionne pas! :(


Ne blâmez pas le triangle jaune, c'est innocent ;-)


Lorsque vous utilisez les outils de débogage d'IE, pouvez-vous déterminer si les demandes de scriptresource.Axd reviennent avec 404 erreurs? Ce type d'erreur est le plus souvent causé par des problèmes de configuration des mappages de gestionnaire de votre site.


@LTHIBODEAUX - Merci. J'essaye maintenant ceci - ROELVANLISDONK.NL/?p=1836


Oui, le tutoriel: ROELVANLISDONK.NL/?P=1836 Fixez le problème !! Merci à tous.


6 Réponses :


8
votes

Une solution rapide consiste à mettre à jour votre web.config et à ajouter la section suivante xxx


1 commentaires

Cette section existe déjà dans mon web.config, et l'erreur se produit toujours.



1
votes

J'ai eu la même erreur et, après avoir beaucoup de mal à la tête, j'ai découvert que la personnalité httpmodule que j'avais créée était d'intercepter toutes les demandes HTTP et n'était pas limitée à . ASPX Demandes uniquement.

Mon module a évalué certains critères et redirigé vers une page 404 ou 500 si nécessaire. Le problème était que cela faisait cela pour toutes les demandes, y compris les demandes de ressources .axd telles que le scriptmanager.axd . En filtrant des fichiers .aspx dans le module, tout a commencé par magiquement à travailler à nouveau.

Parfois, ce sont les choses juste sous votre nez qui sont le problème. J'espère que cela aide une seule semelle pauvre et les sauve le temps et les efforts qu'il m'a fallu.

acclamations,

kaine


1 commentaires

Comment filtrer .aspx fichiers?



0
votes

J'ai eu la même erreur depuis deux jours. Enfin je résout le problème. Ajoutez les éléments suivants dans le gestionnaire géré dans IIS.

*_AppService.axd

System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35

ScriptHandlerFactoryAppServices

ScriptResource.axd

System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35

ScriptResource


1 commentaires

Bonjour. J'ai un problème similaire. J'ai vérifié ces mappages de gestionnaire dans IIS 7 et j'ai trouvé toutes les entrées. La différence est que ma version est 4.0. Est-ce que quelqu'un sait si ce sont d'accord avec la version 4 ou si elles devraient utiliser 3.5?



3
votes

J'avais fait face au même problème et que le Culprit était un fichier web.config d'une autre application, qui a été conservé sur la racine Web. (Quelqu'un avait installé l'application sur la racine Web) Une fois qu'il a été déplacé dans un dossier, le problème a disparu.


2 commentaires

Homme, j'avais essayé beaucoup trop de solutions ci-dessus ... le vôtre (le plus simple) a fait le tour. Merci beaucoup de partage !!


Près de 10 ans après avoir besoin de vous dire que sur toutes les pages que j'ai visitées et un groupe de réponses / questions similaires, aucune autre réponse a souligné ce que vous venez de faire ici. Dans mon cas, il y avait un web.config dans le dir racine comme vous l'avez mentionné (je n'ai pas pensé à cette possibilité avant de voir cette réponse). Merci!



1
votes

Juste à des fins de référence, après avoir chassé cette erreur pendant deux jours, nous avons finalement trouvé la raison. C'était complètement différent des autres que les autres ont déclaré ici.

La raison efficace était une entrée erronée dans le fichier "web.config". C'était cette ligne: xxx

Tout le site Web a fonctionné correctement, sauf que les trucs ASP.NET AJAX n'ont pas chargé.

Utilisation de Firefox et du réseau Connectez-vous à la console de développeur Web, j'ai vu une énorme quantité de 302 redirections HTTP de certains fichiers .axd. C'est à dire. Il y avait une boucle sans fin que le navigateur a finalement tué après env. 20-30 Redirection.

La ligne ci-dessus a provoqué ces redirections.

Mon hypothèse est ce comportement:

  1. Il y avait une redirection sans fin pour les fichiers ASP.NET AJAXD .AXD.
  2. Le navigateur a essayé de le charger plusieurs fois.
  3. Le navigateur a finalement abandonné le chargement des fichiers.
  4. Cela a provoqué l'imprimé du message d'erreur ci-dessus:

    Cadre côté client ASP.NET AJAX n'a ​​pas réussi à charger

    La solution était de supprimer la redirection (inutile). Après cela, tout a fonctionné bien, encore une fois.

    (nous avons fait les redirects réels dont nous avions besoin puis en installant le Module de réécriture URL IIS )


0 commentaires

0
votes

Etepte de la solution pour moi était de supprimer les réécroissements de l'URL du site de l'application! La plupart de nos sites sont des pages statiques WordPress, qui avaient besoin des réécrites; Lorsque nous avons converti l'application sur un site, IIS a automatiquement appliqué les réécrites.


0 commentaires