ASP.NET serveur de développement ou Localhost IIS?

il n'y a rien que le ASP.NET Dev WebService peut faire ce que IIS ne peut pas (vous pouvez définir les points de rupture etc, il suffit de fixer le débogueur VS au ASP.NET runtime).

cependant, le ASP.NET Dev WebService ne représente pas un véritable environnement de production, et en tant que tel, vous pouvez vous faire attraper par des gotchas que vous ne pouvez pas attendre lorsque vous déployez à la production.

pour cette raison, je demande que tout le développement soit fait en utilisant IIS sur une machine locale. Il cela ne prend pas beaucoup de travail pour configurer un site dans IIS.

C'est une très bonne idée. Voici quelques raisons pour:

• Vous n'avez plus besoin admin accès à votre machine de développement web (il peut toujours être utile).
• il est beaucoup plus facile de tester un changement rapide et de continuer le travail, et cycles d'itération plus rapides sont bons .
• il peut simplifier la configuration et le déploiement de vos environnements de développement.
• La version XP de IIS a des limitations qui ne sont pas présentes dans la version Server que Cassini side-steps.

le seul argument que je connaisse est qu'il y a quelques rares cas de bordures où le serveur intégré de Cassini n'imite pas exactement IIS parce que vous utilisez des numéros de port impairs. Je doute que vous les rencontrerez un jour, et utiliser Cassini comme environnement dev primaire n'empêche pas les développeurs d'avoir également accès à IIS sur la machine. en fait, ma configuration préférée est Cassini d'abord pour la plupart des petits travaux, puis déployer dans mon IIS local pour des tests plus approfondis avant de déplacer le code à nouveau dans le dépôt source partagé.

[Modifier]

J'ai oublié de réécrire l'url. Tu as besoin d'un IIS pour ça. Et un exemple d'une limitation de L'IIS XP intégré est que vous êtes limité à un seul site dans XP (peut avoir plusieurs applications, mais c'est une autre chose).

j'ai dû basculer (back) vers IIS pour un projet, parce que j'avais besoin de mettre quelques répertoires virtuels ce qui n'est pas possible sur le ASP.NET développement serveur Web.

comme je l'ai dit ici: https://stackoverflow.com/questions/103785/what-are-the-disadvantages-of-using-cassini-instead-of-iis vos développeurs doivent être conscients que Cassini tourne en tant qu'utilisateur local, qui est généralement un compte administrateur pour les développeurs. Le développement sera capable d'accéder à n'importe quel fichier ou ressource que leur compte peut, ce qui est tout à fait différent de ce qu'ils verront sur un serveur IIS 6.

L'autre chose qui est un assez gros gotcha est débogage services web est beaucoup plus facile en utilisant IIS et vdirs plutôt que Cassini instances séparées.

j'ai utilisé les deux méthodes et je préfère avoir IIS localement plutôt qu'en utilisant le serveur intégré. Au moins, vous êtes plus cohérent avec le déploiement final.

je sais qu'à un moment donné j'ai eu un problème avec L'authentification ne fonctionne pas comme prévu sur Cassini (construit dans le serveur de développement)

en outre, si vous avez besoin de tester des choses comme les plugins ISAPI (un ré-auteur par exemple) Je ne suis pas sûr comment cela se fait sur Cassini.

le port qui change constamment me déconcerte aussi. En outre, pour chaque projet web dans votre solution il allume une autre instance D'un serveur Casini, et chacun prend n'importe où de 20 à 50 MB de mémoire.

j'utilise IIS tout le temps, c'est assez facile à configurer, et vous les gars le font déjà...

aussi, lorsque vous utilisez IIS 5.1, assurez-vous d'obtenir JetStat IIS Admin , il ajoute des fonctionnalités qui est désactivé hors de la boîte sur IIS 5, comme la possibilité de configurer plusieurs sites.

j'ai rencontré les limites suivantes avec le asp.net dev server:

1. ne supporte pas les DIR virtuels. Si vous avez besoin d'eux dans votre application, IIS semble être votre seul choix

2. Classique des pages asp, ne courent pas dans le serveur de dev. Donc, si vous avez une application web mixte (comme je l'ai chez mon client en ce moment), IIS semble être la solution

3. si vous avez besoin d'un administrateur UI pour configurer les paramètres, IIS fonctionne mieux

bien sûr, IIS exige que vous soyez un administrateur local.

une autre distinction que J'ai remarqué est que Cassini fonctionne comme un processus 32 bits et vous n'avez aucun contrôle sur elle, alors que vous pouvez contrôler le pool d'application de votre application IIS pour rejeter 32 bits (en supposant que votre IIS est en cours d'exécution sur un serveur 64 bits). Cela devient particulièrement important si votre application web va appeler des API dans des processus 64 bits tels que SharePoint Foundation / Server 2010. Lorsque vous déboguez votre application web avec Cassini comme votre serveur de déboguage, vous obtiendrez " l'application Web à url n'a pas pu être trouvé. Vérifiez que vous avez tapé correctement L'URL" type errors when instanciating objects. Si vous déboguez en utilisant IIS avec l'application tournant dans un pool d'applications qui tourne en 64 bits avec une identité qui permet l'accès à la base de données sharepoint, alors vous serez en mesure de déboguer correctement.

en VS12 le serveur de développement est très lent, prend quelques secondes pour télécharger un fichier 2kbyte. Cela ne s'est pas produit dans vs10. Lorsque vous avez un tas de fichiers jquery et css, c'est un vrai problème. Aussi chaque page requière tous les fichiers css/js. Test de régression très très lent.

le principal problème que j'ai rencontré avec le serveur dev est SerializationExceptions avec des principes de sécurité personnalisés stockés dans le contexte du thread. Détails ici .