Comment corriger l'erreur ASP.NET "Le fichier 'nnn.aspx' n'a pas été pré-compilé et ne peut pas être demandé."?
J'ai un site Web VS 2005 que je publie à l'aide de "Publier le site Web" et je désactive les trois cases à cocher. J'ai également un projet de déploiement qui récupère les fichiers publiés et crée un MSI. J'installe ensuite le package sur un serveur de test séparé.
En d'autres termes, l'ensemble du site est pré-compilé. Cependant, lorsque je consulte un fichier .aspx dans un sous-dossier spécifique nommé "Services", je reçois une exception HttpException:
System.Web.HttpException: le fichier '/myapp/Services/mypage.aspx' n'a pas été pré-compilé et ne peut pas être demandé.
Si je vais dans un fichier .aspx dans un autre dossier, que ce soit la racine ou un autre sous-dossier, cela fonctionnera correctement.
Le contenu de mypage.aspx lui-même est le suivant: <%@ Page Language="C#" AutoEventWireup="true" CodeFile="mypage.aspx.cs" Inherits="Services_mypage" %>"
Dans le dossier /myapp/bin, je peux voir un fichier mypage.aspx.989dc2fb.compiled. Le contenu de ceci semble pointer vers un certain assemblage qui est également présent dans le dossier bin.
Pourquoi cette erreur se produit-elle? Le fichier .compiled est là, et l'assembly est là, et le type en question est présent dans cette assemblée (je peux le voir dans le navigateur d'objets). Est-ce quelque chose à propos du nom ou du contenu du fichier .compiled? Ai-je la mauvaise version en quelque sorte? Que signifie le nombre apparemment aléatoire dans le nom de fichier .compiled et est-il important?
Je tiens également à mentionner que ce problème est apparu soudainement et que je ne suis pas sûr des changements qui ont pu être apportés depuis que le logiciel a fonctionné correctement il y a quelques jours (mais à ma connaissance, aucun).
Je n'ai pas eu cette erreur, mais après un peu de recherche sur Google, je suis tombé sur ce lien. Je ne sais pas si vous l'avez déjà vu: http://forums.asp.net/t/956297.aspx
Modifier (ajouter le texte clé):
Cette erreur survient lorsqu'une référence est spécifiée dans web.config et que le dossier/site de déploiement ne contient pas ces dll installées sur le système ou que le dossier bin ne les contient pas (s'il s'agit d'assemblages privés). Par exemple: (ajoutez Assembly = "Namespace1.NameSpace2, Version = x.x.x.x, Culture = neutre, PublicKeyToken = 31bf3856ad364e35" /) Si votre composant web.config contient des assemblys comme celui-ci et que le serveur déployé ne contient pas ces éléments dans le bac ou le compte GAC, cette erreur se produit.
Les utilisateurs signalaient que les assemblages manquants sur le serveur de destination étaient la cause principale dans leur cas, mais qu'ils avaient la même erreur que vous. Bizarre.
Peut-être que c'est le problème?
Juste comme une note de bas de page à toutes les réponses ci-dessus qui ont résolu le problème en republiant pour remplacer une Assemblée manquante ... Alors que j'avais déjà résolu ce problème avec la même solution, je viens de rencontrer une autre raison qui pourrait aider d'autres.
Le paramètre "Activer les applications 32 bits" de mon pool d’application sur mon site était défini sur false. En remplaçant ceci par true via la boîte de dialogue "Paramètres avancés" du pool d'applications, j'ai résolu mon problème.
Espérons que cela aide un autre ventouse pauvre.
J'ai eu cette erreur quand j'ai mis à jour un site de 2.0 à 4.0. L'erreur était due à un fichier PrecompiledApp.config dans le répertoire root du site. Une fois que j'ai supprimé ce fichier, le site a commencé à fonctionner.
Je lutte pour résoudre ce problème depuis quelques jours. Au moins dans mon cas, le message d'erreur était complètement trompeur et n'avait rien à voir avec un site Web précompilé. Il existe de nombreux articles ou publications qui donnent de nombreuses réponses différentes qui ne font qu'ajouter à la confusion. Personnellement, je pense que cette erreur est principalement due à des références manquantes ou à une gestion incorrecte des versions. Afin de résoudre le problème aussi rapidement que possible, vous devez l'exclure ou autrement corriger la référence manquante/erronée.
Pour ce faire, vous devez utiliser un outil appelé "Viewer Log Binding Assembly". Cet outil vous indiquera les références manquantes ou les versions incorrectes. S'il y a une référence manquante/incompatible, continuez et corrigez-la; sinon, vous devez effectuer les autres tours de magie tels que la vérification de l'app Pool 32 bits ou des autorisations.
Pas:
Sur votre serveur, créez les dossiers suivants
C:\fuslog C:\fuslog\logs
Copiez la visionneuse du journal de liaison d’assemblage sur votre serveur à l’aide de C:\fuslog:
Vous pouvez trouver le programme à un endroit comme celui-ci
C:\Program Files (x86)\SDK Microsoft\Windows\v7.0A\Bin\fuslogvw.exe
Vous pourriez avoir besoin de regarder "Program Files" au lieu de "Program Files (x86)" ou chercher dans différentes vesions au lieu de "v7.0A"
Exécuter fuslogvw.exe sur le serveur
Cliquez sur "Setting ..."
Assurez-vous que "Journal des échecs de liaison au disque" est coché
Vérifiez le chemin d'activation du journal personnalisé et entrez les informations suivantes dans la zone: C:\fuslog\logs
Cliquez sur OK
Recyclez/réinitialisez votre pool d'applications pour appliquer une nouvelle liaison.
Cliquez sur Actualiser. Maintenant, vous pouvez voir la liaison échouée ici
Le meilleur moyen de trouver la liaison exacte consiste à accéder à c:\fuslog\logs\Default. Ici, vous pouvez trouver les échecs de liaison exacts. Certains ne sont pas pertinents et vous devez trouver le point critique par essais et erreurs. Le mien était l'échec suivant:
System.Web.Mvc, Version=4.0.0.1, Culture=neutral, PublicKeyToken=31bf3856ad364e35
J'ai résolu le problème en ajoutant l'entrée suivante sur mes sites Web web.config:
<configuration>
...
<runtime>
...
<!-- Added this entry to fix the issue -->
<dependentAssembly>
<assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="0.0.0.0-4.0.0.1" newVersion="4.0.0.0" />
</dependentAssembly>
...
</runtime>
...
</configuration>
J'espère que cela aide les autres à résoudre rapidement le problème.
Cette erreur m'est survenue et je l'ai résolue.
Lorsque vous souhaitez publier votre site, cochez la case Utiliser les assemblys à noms fixes et à page unique dans Visual Studio.
Vous verrez que ce problème sera résolu!
Nous avons résolu ce problème en redémarrant l'AppPool, après avoir essayé plusieurs des autres solutions. La republication n'était pas une option à cette occasion.
Il s’est avéré qu’il s’agissait d’un fichier manquant (non Web) DLL dans le fichier MSI, qui, je suppose, a été utilisé par les pages générant l’erreur. Un message d'erreur assez trompeur, je dirais, car la page a certainement été précompilée, mais il manquait une référence à cette DLL.
Cette option a résolu le problème pour moi. Fondamentalement, il supprime tous les fichiers orphelins laissés après le déploiement précédent.
J'ai eu le même problème aujourd'hui. Certains forums disent qu'il manque une référence sur votre site Web et que c'est certainement le cas dans votre cas. Bien que tous les assemblys nécessaires soient inclus, vous avez peut-être déployé votre site Web sur un serveur IIS avec une infrastructure 3.5, n'est-ce pas?
Eh bien, c’était mon cas. J’ai donc copié le fichier web.config à partir d’un site Web ASPX 3.5 original, modifié certaines parties (supprimé d’autres références d’assemblage 3.5) et essayé de le déployer à nouveau.
J'ai rencontré le même problème. Mon problème a été résolu en supprimant les fichiers du dossier des fichiers asp.net temporaires de cette carte:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root
Le redéploiement des mêmes fichiers a également résolu ce problème dans mon cas.
Alors peut-être qu'avant d'essayer quoi que ce soit d'autre, essayez de déployer votre application à nouveau (le contenu du dossier bin devrait suffire)
BTW: Dans mon cas, l'erreur a commencé lorsque le lecteur C manque d'espace.
Bonne codage! ChiTec
Je sais que l'erreur consiste à se plaindre de quelque chose d'autre, mais je vous promets que le problème ne concernait que le permission d'accès insuffisante (identité de service réseau ou d'application ou IUSR) permettant au compte asp.net de fonctionner avec ce fichier spécifique. .
cela était dû à déploiement inhabituel} et au mélange des fichiers bin avec les nouveaux fichiers publiés dans notre environnement VPS.
Solution:
ces autorisations de fichier spécifiques doivent être remplacées par des autorisations de dossier Bin correctes, comme pour les autres fichiers qui fonctionnent correctement (et wo cette erreur) dans Bin.
Commencez par vérifier l'espace disque disponible. J'ai eu cette erreur quand nous avons manqué d'espace sur le disque dur hébergeant IIS.
Pour moi, j'avais un script qui supprime le dossier de production, puis copie les nouveaux fichiers.
Le script n'a pas réussi à supprimer correctement le dossier de production, laissant l'ancien et le nouveau fichier mélangés, ce qui a provoqué l'erreur.
J'ai supprimé manuellement le dossier entier et redéployé avec succès ... puis mis à jour le script.
j'étais confronté à ce problème lorsque j'ai déployé certaines modifications sur mon site existant.
Pour résoudre ce problème, j’ai supprimé tous les fichiers du dossier bin et les ai redéployés.
Le problème a ensuite résolu.
J'espère que cela pourra aider quelqu'un.
Finalement, j'ai trouvé le problème. Si vous utilisez MVC Framework comme moi, veuillez mettre à jour votre version de MVC. Dans mon cas, j'ai modifié MVC 4.0.0.0 en 4.0.0.1 et vérifié les propriétés de "copie locale" de toutes les références de projet sur "True". Après que mon problème soit résolu. Veuillez vérifier la version de MVC dans tous les fichiers de configuration (4.0.0.0-> 4.0.0.1)
Et surveillez les messages d’avertissement du compilateur asp.
Si vous obtenez cette erreur lors de l'exécution d'un script MSBuild, il est probable que votre projet est un projet 2.0 ou 3.5 et que MSBuild utilise le compilateur 4.0. Essayez d’ajouter TargetFrameworkMoniker = "3.5" à vos directives AspNetCompiler.
Dans mon cas, je ne téléchargeais pas les DLL communes telles que AjaxControlToolkit.dll, Telerik.dll, etc., j'avais téléchargé le dossier complet publié et il le réparait.
Cette erreur peut également se produire si vous avez un fichier .compiled dans bin pour une page qui ne fait plus partie de votre projet. Vous recevez ceci à la place de 404 essentiellement. Supprimez le fichier .compiled et vous obtenez 404.
En cas de mise à jour, puis recompiler. copier à nouveau tous les fichiers du dossier bin et le fichier particulier mis à jour à partir de son dossier respectif.
Dans mon cas, le fichier 'nnn.aspx.xxxxxxxx.compiled' a été supprimé par WebDeploy, car j'ai exécuté deux tâches simultanément dans le même espace de travail Jenkins. Le deuxième travail a supprimé certains fichiers lors de la création du package WebDeploy.
Dans le cas d’une erreur concernant une vue asp.net mvc razor (.cshtml), le dossier/bin contenait deux fichiers .compiled pour la même vue. L'un d'eux était vieux et devait être supprimé.
J'ai également eu une deuxième vue dans le sous-dossier de vues de contrôleur qui devait également être supprimée.
Un problème est dû au fait que j'ai déplacé une vue du sous-dossier de vues du contrôleur vers le dossier partagé. Toutefois, mon processus de déploiement (Visual Studio Publish) n'a pas supprimé la vue obsolète et les fichiers view.compiled du serveur. Vous pouvez demander à Visual Studio de toujours nettoyer le dossier de destination, mais cela ralentirait le processus de déploiement.
J'ai eu le même problème lorsque j'ai commencé à utiliser VWD Express 2012 (après avoir utilisé Express 2010, qui fonctionnait normalement). . Le problème est parti.
C'est la solution pour VS 2008.
Veuillez cocher la case ci-dessous pour résoudre le problème.
