Déployer ASP.NET MVC 2 de IIS 7.5 ciblage .NET 3.5

J'ai créé un ASP.NET MVC 2 application dans Visual Studio 2008. J'ai mis la version release de passer par la ASP.NET compilateur de précompiler tous les points de vue, rapetisser Javascript et CSS, nettoyer le web.config, etc. Depuis le déploiement de production est d'aller vers un serveur IIS6, j'ai mis mon pseudo-déploiement en production sur mon ordinateur Windows 7 pour avoir le pool d'applications de s'exécuter en mode classique ciblant le runtime 2.0. J'ai configuré le extensionless gestionnaire dans le web.config c'est nécessaire et tout fonctionnait très bien.

Le problème est venu quand j'ai mis à jour la solution de Visual Studio 2010. Je suis encore le ciblage de 3,5 cadre, mais maintenant, je suis en utilisant MSBuild 4.0 puisque c'est ce que Visual Studio 2010 utilise. Tout se compile correctement, car il fonctionne très bien sous Cassini, mais quand je le déployer dans le même lieu (le même pool d'applications, de l'identité, etc) maintenant il se comporte différemment. J'ai toujours le extensionless gestionnaire dans le web.config, mais maintenant, quand je navigue à la racine de l'application, il ne l'exploration de répertoire, et toutes les routes qu'il avait précédemment géré maintenant de revenir comme des erreurs 404 traitées par les StaticFile gestionnaire des services IIS. Je suis à une perte pour ce qui a changé et est à l'origine de la rupture.

J'ai regardé cette question, mais j'ai déjà vérifié que tous les composants requis sont installés.

OriginalL'auteur Agent_9191 | 2010-05-24

  1. 3

    Avez-vous essayez de déboguer votre itinéraire à l'aide Phil Haack route débogueur sur le serveur?

    Edit:

    Sur IIS 7.5, vous n'avez pas besoin de tout spécial extensionless gestionnaire, cela est géré automatiquement, vous n'avez pas besoin de changer quoi que ce soit. Il est seulement nécessaire sur IIS 6, pour autant que je sais.
    Pourrait-il être le problème? que faire si vous supprimez que gestionnaire particulier? c'est peut-être ce qui est de l'arrêter à coup de pied dans la route du moteur.

    Edit:

    J'ai vérifié, et comme je le pensais, en commençant sur IIS7, le mode par défaut d'un domaine d'application est Mode Intégré. Cela signifie que l'Asp.net pile de coups de pied à chaque requête, alors que dans le mode classique, asp.net a été appelé que lorsque une des extensions spécifiques là où il est appelé aspx (ashx axd sont mappés par défaut à la aspnet_isapi filtre).

    UrlRoutingModule est des coups de pied à chaque demande sans exiger rien de vous, parce que c'est un HttpModule et pas un Gestionnaire. (il a juste besoin d'être enregistrés dans le fichier de configuration de votre application, pas besoin de l'associer à une extension, mais c'est par défaut dans une application MVC. Vous pouvez ouvrir des vous Web.Le fichier de configuration et vérifiez que vous avez sous un nœud 

    <modules runAllManagedModulesForAllRequests ="true">
...
<add name="UrlRoutingModule" type=.../>
</modules>

    Êtes-vous sûr de déployer le MVC assemblées sur le serveur?
    Vérifiez que Système.Web.Mvc, Système.Web.Routage et Système.Web.Abstraction références ont la Copie Locale de la propriété à true pour être sûr que vous utilisez la même assemblées en local et sur le serveur de production...

    Si tout cela est correct, je ne sais pas comment t'aider plus... j'espère que cela va vous aider, ou au moins de vous mettre sur le droit de pistes.

    EDIT:
    Oww... il suffit de lire votre dernier commentaire... désolé, j'ai manqué l'élément classique de la mode. Votre titre mentionne IIS7.5 et j'ai pris beaucoup trop de choses. c'est pourquoi je me suis confus.

    Honnestly maintenant, j'ai dû chercher dans le livre de Steven Sanderson. Il a une liste de vérification pour le dépannage IIS6 de déploiement.
    Je sais que vous dites que c'est seulement lors de l'utilisation de MSBuild 4 qu'il échoue, mais il peut encore être utile

    Vérifiez que par Défaut.aspx est définie comme valeur par défaut le contenu de la page. Qui pourrait être la source de la 404.

    De extensionless url, la dernière fois que j'ai déployé pour IIS6 j'ai utilisé un simple joker de la carte et je n'ai jamais eu un problème...
    Si vous êtes toujours en difficulté désolé que je pouvais pas l'aider... non pas que je n'ai pas essayer 🙂 bonne chance

    Ce n'est pas de frapper le moteur de routage. C'est ça le problème. Malgré le web.config en cours de configuration, IIS semble l'ignorer et de le retourner standard 404. Permettant IIS suivi révèle que le routage des gestionnaires et des modules ne sont pas en cours d'exécution.
    En réponse à votre edit, j'avais besoin de gestionnaire dans les il y quand il a été compilé à l'aide de MSBuild 3.5. Sinon, IIS ne sais pas envoyer la page par le moteur de routage.
    hm, je suis un peu confus, parce que la génération ne devrait pas changer quoi que ce soit concernant le traitement de la demande. Votre problème semble se produire avant même qu'il ne frappe à votre application. Pourriez-vous vérifier que votre pool d'application s'exécute en Mode Intégré? Je dois partir maintenant, mais je vais poster une longue réponse plus tard.
    Le pool d'application est en cours d'exécution en mode Classique, parce que la production finale de serveur est en cours d'exécution IIS6 (comme je l'ai dit dans la question), donc j'essaye de rester aussi proche que possible. Comme je l'ai dit, lorsque la base de code est compilé à l'aide de MSBuild 3.5 il fonctionne comme prévu. Lors de la compilation à l'aide de MSBuild 4 (mais encore le ciblage 3.5 framework), il est à l'origine du problème.

    OriginalL'auteur Stéphane

  2. 2

    J'ai connu ce problème aujourd'hui, dans un scénario similaire.

    Le problème sur mon cas était dû au fait que asp 32 bits a été enregistré au lieu de 64 bits, à l'origine du problème avec le routage.

    Il a été résolu en tapant la commande suivante dans l'invite de commande

    CD c:\windows\microsoft.net\framework64\v4.0.30319
aspnet_regiis -i
    J'ai d'abord modifications de l'application de la piscine pour v4.0, qui a supprimé l'erreur, cependant ISS n'était pas le chargement de l'application MVC (au lieu d'essayer de montrer le répertoire) après l'exécution de la commande ci-dessus (semblait à installer .net 4) la demande a couru (de même que l'utilisation de visual studio serveur de dev).

    OriginalL'auteur Elfdragore

  3. 0

    Quelques idées à essayer

    • Avez-vous exécuter n'importe quel type de comparaison
      entre la sortie de la VS2008 et
      VS2010 projets? Juste que la vérification de la
      solution de mise à niveau n'a pas changé
      quoi que ce soit.
    • Avez-vous le web.config
      targetFramework attribut défini sur le
      compilation élément?
    • Êtes-vous certain que vous n'êtes pas en cours d'exécution
      en quelque chose comme l'exécution d'une application x86
      dans un x64 application de la piscine?

    Je devine que vous êtes bien sur, mais depuis Cassini a pas de problèmes avec l'application, je continue à pencher vers le web.config questions. Avez-vous vos modules/gestionnaires correctement enregistré dans l'élément? Puisque vous êtes en cours d'exécution en Mode Classique, vous aurez besoin à la fois de la "vieille" et la "nouvelle" (référence 1, référence 2).

    il n'y a pas un targetFramework dans le web.config, mais j'ai targetFrameworkVersion défini dans le fichier de projet lui-même. Depuis que je suis précompilation et de le déployer sur IIS dans les deux scénarios, je ne sais pas si le web.la config est nécessaire. Comme pour les sorties entre les deux il est difficile de faire la comparaison binaire depuis que je suis en utilisant Entity Framework et il a du faire quelques modifications pour le VS2010 d'outils.
    Mise à jour rapide. J'ai essayé le réglage de la targetFramework l'attribut de l'élément de compilation et d'essayer de construire le projet a abouti à VS2010 disant qu'il n'est pas nécessaire avant d'atteindre le framework 4.0. Aussi, je doute que c'est un x86 vs x64 question comme je suis à la compilation et à l'exécution strictement sur du matériel x86 et OS.
    Un peu de chance avec le module/gestionnaire d'enregistrements dans le web.config? Que l'on considère les plus prometteurs et de les adapter à la "symptômes"

    OriginalL'auteur Josh

  4. -3

    J'ai déjà posté cette solution dans un autre thread, mais je vais me répéter.
    Utilisation classique mode pipeline de pool d'applications:

    le texte d'alt http://img823.imageshack.us/img823/3684/20100612135212.png

    Aussi dot oubliez pas d'installer Redirection HTTP module dans fonctionnalités Windows Activer ou désactiver.

    Si vous avez regardé mes réponses à @stephanie, vous verrez que j'ai déjà en cours d'exécution le pool d'applications en mode classique. Et si vous avez regardé le lien, dans la question, j'ai dit que j'avais les composants déjà installés (y compris l'adresse HTTP de Redirection).

    OriginalL'auteur Vitaliy Ulantikov