Message d'erreur de l'analyseur: impossible de charger le type «TestMvcApplication.MvcApplication»

J'obtiens l'erreur suivante sur l'un de nos serveurs de production. Vous ne savez pas pourquoi cela fonctionne sur le serveur DEV?

Erreur d'analyse Description: une erreur s'est produite lors de l'analyse d'une ressource requise pour traiter cette demande. Veuillez consulter les détails de l'erreur d'analyse spécifique suivants et modifier votre fichier source en conséquence.

Message d'erreur de l'analyseur : impossible de charger le type «TestMvcApplication.MvcApplication».

Erreur source :

Ligne 1: <% @ Application Codebehind = "Global.asax.cs" Inherits = "TestMvcApplication.MvcApplication" Language = "C #"%>

Fichier source: /global.asax Ligne: 1

Je ne sais pas si quelqu'un a déjà rencontré cette erreur et comment elle a été résolue, mais j'ai atteint la fin. Toute aide serait appréciée.

Je dois également mentionner qu'il s'agit du code publié, donc tout est compilé. Peut-il y avoir quelque chose qui ne va pas avec les paramètres de mon compilateur?

Aucune des autres réponses n'a fonctionné pour moi. J'ai corrigé mon erreur en modifiant le chemin de sortie du projet Web. Je l'avais réglé sur bin \ debug mais le projet Web ne fonctionne pas à moins que le chemin de sortie ne soit simplement défini sur "bin"

Je l'ai eu plusieurs fois. C'est particulièrement frustrant car c'est dès le départ et le message d'erreur ne donne aucune idée de ce qui pourrait être le problème.

Pour résoudre ce problème, cliquez avec le bouton droit sur le titre de votre projet, dans ce cas "TestMvcApplication" et cliquez sur construire .

Cela force le code à se compiler avant de l'exécuter. Ne me demandez pas pourquoi, mais cela a été la solution 100% du temps pour moi.

J'ai constaté que lorsque vous êtes obligé d'utiliser le Gestionnaire de configuration pour fonctionner sous x86 ou autre chose que les paramètres standard du projet "prêt à l'emploi", l'EDI crée un tas de sous-répertoires sous le dossier bin pour le projet Web.

Une fois que cela commence à se produire, si le serveur Cassini est en cours d'exécution, le projet ne fonctionne pas correctement.

Je l'ai corrigé en allant dans les propriétés du projet Web -> Paramètres de construction et en changeant le chemin de sortie en bin \

Puis reconstruisez et tout fonctionne comme il se doit.

Après un long regard, je suis tombé sur le vrai problème ici.

Les assemblys ont été corrompus par le client FTP que j'ai utilisé pour télécharger les fichiers dans un environnement hébergé.

J'ai changé mon client FTP et tout fonctionne comme prévu.

J'ai eu le même problème: le mien était parce que le projet Web avait une cible de plate-forme de x86. Je courais sur une machine 64 bits; les autres projets de la solution ont été définis sur 64 bits.

Pour vérifier vos paramètres, cliquez avec le bouton droit sur le projet et choisissez Propriétés. Sous l'onglet Générer, vérifiez la valeur de «Platform Target».

Vérifiez également la configuration de construction de votre solution (menu Générer> Gestionnaire de configuration) pour vérifier que tous vos projets sont construits sur la même plate-forme.

Dans les deux cas, assurez-vous de vérifier les paramètres à la fois pour le débogage et le mode de libération - sinon vous le ferez fonctionner sur votre machine mais pas lorsque vous le déploierez!

J'ai essayé toutes les solutions ci-dessus mais pas de chance. L'ajout d'une ligne <add assembly="*" />à web.config l'a corrigé pour moi. (Vous pouvez également ajouter au fichier machine.config ou racine web.config de la version appropriée du framework .NET, je ne l'ai pas essayé) Merci à MS Support pour la solution.

J'ai eu ce qui ressemblait à la même erreur. J'ai essayé de nombreuses suggestions de nombreuses pages uniquement pour découvrir que le problème était que le site Web était défini sur la mauvaise version de .Net

Peu importe le nombre de recompilations ou de personnes disant «problème de configuration», personne n'a fait valoir que la version .net devait être vérifiée.

Cela m'arrive lorsque je renomme mon projet / solution. Allez dans le dossier du projet dans l'explorateur Windows (sortez de VS). Trouvez et ouvrez le fichier Global (peut-être que vous trouverez 2 fichiers, ouvrez qui n'ont pas l'extension ".asax.cs"), et modifiez la ligne d'erreur avec le chemin correct. Bonne chance!

J'ai rencontré exactement le même problème il y a quelques jours - pour autant que je sache, c'était un problème avec un IIS 64 bits exécutant une application Web 32 bits. Nous avons changé notre serveur de production en 32 bits et ce problème a disparu.

Assurez-vous que votre espace de noms par défaut dans les propriétés du projet Web est le même que l'espace de noms dans Global.asax.cs. J'avais modifié l'espace de noms par défaut pour en faire un sous-espace de noms, le changer a résolu ce problème pour moi.

Par souci d'exhaustivité, j'ai inclus mon problème et comment je l'ai résolu:

Si vous comme moi et avez httphandlers via web.config et que vous avez des redirections de votre global.asax.cs (peut-être dans Session_Start ()) comme dans mon cas, vous obtenez cette erreur si votre projet de démarrage n'a pas de référence définie qui pointe vers la cible vers laquelle pointe votre httphandler !! (mais vous n'obtiendrez pas d'erreurs de construction, juste des erreurs d'exécution)

Alors:

1. Vérifiez votre web.config pour tous les éléments externes
2. Vérifiez que votre projet de démarrage a toutes les références dont il a besoin.

À votre santé.

La seule fois où j'ai vécu cela, c'était lorsque le framework MVC n'était pas installé sur le serveur. Cela pourrait-il être le cas?

Une section Pages manquante dans Views \ Web.config pourrait également être en cause.

J'ai eu la même erreur et aucune de vos solutions n'a aidé. Je pense que mon problème était simplement le nom que j'avais choisi pour le projet. J'avais nommé mon projet `` interface '' qui, lorsque j'ai eu l'erreur d'analyse, disait qu'il ne pouvait pas se charger:

Ligne 1: <% @ application Codebehind = "Global.asax.cs" Inherits = " @interface .MvcApplication" Language = "C #" %>

Où il y avait un signe «@» pour une raison quelconque. Je suppose que le mot «interface» est réservé à autre chose et il a ajouté le symbole @ mais cela a évidemment cassé quelque chose. J'ai supprimé le projet et en ai créé un nouveau avec un nom différent sans problème.

En voici un autre:

1. J'avais travaillé sur un projet d'API Web qui utilisait localhost: 12345.
2. J'ai extrait une branche différente du contrôle de code source contenant le même projet.
3. J'ai exécuté le projet sur la branche et j'ai obtenu l'erreur.
4. Je suis allé dans "Propriétés> Web> URL du projet" et j'ai cliqué sur "Créer un répertoire virtuel"
5. Une boîte de dialogue est apparue m'indiquant que l'URL était mappée vers un répertoire différent (le répertoire du projet d'origine).
6. J'ai cliqué sur OK et le répertoire virtuel a été remappé.
7. L'erreur est partie.

J'espère que cela aide quelqu'un quelque part :)

J'ai eu beaucoup de problèmes et d'erreurs à résoudre, certaines des réponses ci-dessus m'ont aidé, mais l'astuce finale qui a fait que cela a fonctionné pour moi était: Accédez à votre projet, cliquez sur Propriétés.

Accédez à l'onglet Package / Publish Web et assurez-vous que la configuration est définie sur Release et Platform to All Platforms.

Assurez-vous enfin que «Éléments à déployer (s'applique à toutes les méthodes de déploiement)» est défini sur «Tous les fichiers de ce dossier de projet»

Cela a ensuite bien fonctionné pour moi.

Ce problème est compliqué car il est facile de confondre la cause première avec quelle que soit la cause immédiate.

Dans mon cas, la cause immédiate était que la solution est configurée pour utiliser la restauration de package NuGet, mais que le serveur n'était pas connecté à Internet, donc NuGet n'a pas pu télécharger les dépendances lors de la création pour la première fois.

Je pense que la cause première est simplement que la solution est incapable de résoudre correctement les dépendances. Il peut s'agir d'une configuration de chemin incorrecte, d'une version incorrecte d'un assembly, d'assemblys en conflit ou d'un déploiement partiel. Mais dans tous les cas, l'erreur indique simplement qu'il ne peut pas trouver le type spécifié dans global.asax car il ne peut pas le construire.

Assurez-vous que l'espace de noms dans le Global.asaxfichier correspond à celui du Global.csfichier ie

Global.asax: Some.Website.Webapplication

Global.cs: Some.Website(moins la 'WebApplication')

J'ai essayé la plupart des réponses ci-dessus et elles n'ont pas fonctionné. Pour une raison quelconque, la simple fermeture et la réouverture de VS ont résolu le problème pour moi.

Mon problème a été résolu lorsque j'ai converti dans IIS le dossier physique qui contenait les fichiers vers une application. Faites un clic droit> convertir en application.

Pour moi, c'était parce que j'avais temporairement exclu le fichier du projet. Je l'ai simplement inclus dans le dos du projet, puis cela a fonctionné.

Dans mon cas, la référence de System.Web.MVC manquait dans mon projet. Mais après l'ajout de références, le problème était le même, j'ai donc vérifié les propriétés de mon dossier Bin, c'était en lecture seule. Juste après l'avoir rendu accessible en écriture, tout fonctionne correctement.

J'obtenais une erreur parce que j'ai déployé l'application en tant que répertoire virtuel et que j'obtenais une erreur d'analyseur "Impossible de charger le type", puis j'ai déployé l'application en tant que site Web et je n'obtenais plus cette erreur.

Aucune des autres réponses n'a résolu cette erreur pour moi.
J'ai trouvé une solution qui a fonctionné, que je suggère pour ceux qui se trouvent dans la même situation:

1. Fermer Visual Studio
2. Accédez à Projets \ votreProjet \ votreProjet
3. Renommer Web.Debug.config et Web.Release.config
4. Reconstruisez et exécutez votre application

Je n'ai jamais vraiment compris ce qui en était la cause. Je pense que quelque part j'ai dû manquer des fichiers. J'ai eu l'erreur après la publication sur un nouveau serveur. Finalement, j'ai copié le site du site de travail. Ensuite, le site a fonctionné et a donc continué à publier sur le nouveau serveur.

Suivez ces étapes:

1. Construire
2. Panneau de configuration
3. Mettez le projet AnyCPU
4. Retour pour générer
5. Prêt, après cela, suivez simplement les mêmes étapes pour le transmettre à x86 ou x64

Pour moi, j'avais une DLL incluse avec mon projet qui devait être exécutée dans un environnement 32 bits.

Le serveur a été configuré pour exécuter le site Web en mode 32 bits, mais je n'ai pas pu exécuter l'application sur ma machine 64 bits car le localhostdossier n'avait pas été spécifié pour s'exécuter en mode 32 bits.

J'ai juste eu un problème similaire.

La raison en était que je changeais un fichier.aspx.c et que je devais faire une reconstruction propre. Après cela, tout a fonctionné.

Mon problème était que j'essayais de créer une application Web ASPX dans un sous-dossier d'un dossier contenant déjà un fichier web.config, et

J'ai donc ouvert le dossier parent dans Visual Studio en tant que site Web (Ouvrir> Site Web) J'ai pu ajouter une nouvelle page ASPX d'élément qui n'avait aucun problème d'analyse / de chargement.

Pour moi, le problème ne concernait que certains (longs) liens du site Web et a été retracé jusqu'à URLScan ayant la configuration par défaut d'une limite de longueur d'URL de 260.

J'ai eu le même problème. Essayez de:

Faites un clic droit sur le projet et sélectionnez Nettoyer, puis cliquez à nouveau avec le bouton droit de la souris et sélectionnez Reconstruire et exécutez le projet pour voir s'il a fonctionné.