Quels sont les (dés) avantages d’utiliser Cassini au lieu de IIS?

J’ai constaté qu’à certaines occasions, je pouvais modifier le source lors du débogage, y a-t-il d’autres avantages à utiliser le serveur Web intégré Visual Studio au lieu d’un répertoire virtuel dans IIS?

J’utilise Windows XP sur mon environnement de développement et une instance locale d’IIS 5. Je travaille sur plusieurs projets, alors j’utilise plusieurs répertoires virtuels pour gérer tous les différents sites.

Y a-t-il des inconvénients?

Le serveur Web intégré de Visual Studio s’appelle Cassini et voici quelques-unes de ses limites …

  • Il ne peut héberger qu’une seule application ASP.NET par port.
  • Il ne prend pas en charge HTTPS.
  • Il ne prend pas en charge l’authentification.
  • Il ne répond qu’aux requêtes localhost.
  • Démarrage lent comparé à IIS

Toutes les réponses précédentes sont d’excellentes réponses – voici une gottcha avec Cassini qui pourrait nécessiter IIS sur le destkop.

Cassini s’exécute dans le contexte du développeur, et non en tant qu’utilisateur IIS (IUSR_, IWAM ou dans WinXP x64, le processus w3wp). Cela peut être un peu pénible si un site Web accède à des fichiers externes ou crée des fichiers temporaires. C’est plus évident lorsque votre développeur s’exécute en tant qu’administrateur de son bureau.

Lorsque vous vous déplacez vers le serveur IIS, quelque chose auquel vous auriez eu access dans Cassini ne fonctionne pas de la même manière. CACLing avec IIS_WPG est généralement tout ce qu’il faut pour résoudre, mais si votre développeur ne pense pas à cela, ils seront rapidement frustrés par leur déploiement.

Cassini ne prend pas en charge les répertoires virtuels

On dirait qu’une troisième option arrive bientôt: IIS Express .

Le serveur intégré fonctionne bien pour les grandes entresockets qui ne veulent pas donner aux développeurs un access administrateur sur leurs propres machines pour configurer IIS.

Un autre inconvénient que je rencontre est sur un site Web authentifié par Forms utilisant IPrincipal / IIdentity . Cassini changera d’ AppDomains sans avertissement (ou remarque).

Consultez ce billet de blog pour plus de détails. Le mal de tête à ce sujet m’a fait laisser tomber Cassini et restr avec IIS.

Le serveur Web Visual Studio est moins tolérant sur // dans le chemin.

Il refusera de servir un lien tel que: http://localhost:52632/main//images/logo.jpg où IIS fera l’affaire.

C’est assez obscur, mais cela signifie que nous avons beaucoup de travail à faire pour éliminer toutes les // occurrences.

Il y a un bogue dans la façon dont le serveur intégré gère les HTTPModules – il y a une solution de contournement , mais je déteste avoir à mettre du code qui ne sera jamais nécessaire dans la production.

  • Vous devez avoir Visual Studio pour l’utiliser (dans des circonstances normales)

  • Il ne répond qu’à localhost, donc vous ne pouvez pas donner le lien http://simon-laptop:37473/app1 à un ami pour voir votre site sur le réseau

  • Gros désavantage: il est plus difficile de faire fonctionner un violoniste car le trafic localhost n’est pas envoyé via le proxy.

Edit: en utilisant http://ipv4.fiddler:37473 est le meilleur moyen de faire fonctionner Fiddler.

Si vous référencez par le Web l’URL des services Web présents sur le serveur Web intégré, le port peut changer. Sauf si vous avez défini un “Port spécifique” mentionné dans la page Options du projet-> Propriétés.

C’est quelque chose auquel je me suis habitué maintenant. Je mets toujours un port spécifique. Maintenant, lorsque parfois le serveur Web se bloque (je l’ai déjà fait), je change simplement le numéro de port et tout va bien. Je pense que le redémarrage permettra également de résoudre ce problème.

Le serveur intégré signifie que le développeur n’a pas besoin de savoir comment configurer IIS pour tester son site.

Vous pourriez soutenir que c’est un inconvénient et qu’un développeur Windows devrait au moins en savoir plus sur IIS. Ou vous pourriez dire qu’un développeur qui n’est pas un administrateur système ne devrait pas du tout jouer avec le serveur Web.

Cassini ne prend pas non plus en charge les pages ASP classiques. Ceci n’est qu’un problème pour les projets hérités où d’anciennes pages ASP existent toujours (comme notre application Web au travail).

Vous ne pouvez pas utiliser les répertoires virtuels 🙁

Si vous faites du hobby à la maison en utilisant XP Home, vous ne pouvez pas installer IIS localement.

Le serveur intégré n’est pas aussi configurable et fonctionne sur un port impair, donc si vous comptez sur un comportement spécifique, cela peut être gênant.

Je prends souvent le meilleur des deux mondes et crée une application dans IIS, et utilise le serveur Web intégré pour un débogage plus efficace.

Cassini se veut un serveur de test léger. L’idée est qu’un développeur n’a pas besoin d’avoir IIS installé et configuré pour tester son application. Utilisez IIS si vous le connaissez et que vous l’avez configuré et que votre boîte peut le gérer. Cassini n’est pas censé être un remplaçant.

Lorsque vous utilisez IIS sous Vista ou Windows 7 avec UAC activé, vous devez exécuter Visual Studio avec des droits d’administration. Si vous faites cela, vous ne pouvez pas faire glisser un repository de votre shell vers Visual Studio (même si vous exécutez une instance de explorer.exe en tant qu’administrateur).

Pour cette raison, j’utilise Cassini pour la plupart des projets.

Pour info, Windows XP 64 bits est fourni avec IIS 6.

Ceci est un vieux thread commencé il y a 2 ans. Je suis tombé sur UtilDev Cassini pendant que je cherchais sur Google. Ça me semble prometteur. Au moins, il a la capacité d’exécuter plusieurs sites simultanément. Cette fonctionnalité est très utile pour moi, car je travaille sur 2 sites différents et je dois continuellement basculer entre eux en utilisant IIS.

Voici une troisième raison: bien qu’UWS Pro soit probablement plus proche d’IIS que de Cassini (même s’il est inspiré par Cassini et provient du fournisseur de la fourche UltiDev Cassini), son objective principal est d’être redissortingbuable avec les applications ASP.NET. entrer la description de l'image ici

Installez IISAdmin et vous pouvez configurer des sites distincts dans IIS 5 au lieu d’utiliser des répertoires virtuels.

Le serveur Web intégré est un peu moins robuste que IIS, mais ne nécessite aucune configuration.

Il se peut que vous ne souhaitiez pas toujours que vos projets de développement soient exposés sur votre serveur IIS (même votre serveur IIS local), de sorte que le serveur intégré convient à cela.

Toutefois, si votre application doit accéder à des ressources en dehors des normes pour une application Web, vous pouvez déboguer fréquemment dans IIS afin que votre application s’exécute avec des permissions restreintes et que vous puissiez voir les points critiques.

Nous avons également rencontré des problèmes avec le serveur intégré VS concernant certains contrôles tiers qui placent leurs scripts dans le dossier \ aspnet_client. Étant donné que le dossier n’est pas là lorsque vous n’exécutez pas sous IIS, les contrôles ne fonctionnaient pas. Il semble beaucoup plus simple de toujours travailler avec IIS et d’éviter des problèmes étranges.

Une différence que j’ai trouvée est que le serveur de développement gère le téléchargement de fichiers différemment de IIS. Vous ne pouvez pas intercepter l’erreur si le fichier en cours de téléchargement est plus volumineux que votre paramètre Max_File_Size. La page meurt et renvoie un 500.

Un autre inconvénient est qu’il envoie chaque requête via le fichier asax de gloabal, qui inclut toutes les demandes d’images et de feuilles de style. Cela signifie que si vous avez du code là-dedans qui fait des choses avec les noms de fichiers, comme une recherche, alors les fichiers auxiliaires seront également traités.

Également via IIS, vous n’avez pas à vous soucier de mémoriser automatiquement et de définir un numéro de port stupide dans votre URL localhost. C’est quelque chose de génial sur lequel Cassini s’est directement appuyée … une grosse douleur dans le cul. Qui veut se souvenir d’un numéro de port abritant. Il suffit de lancer le damn site dans IIS..plain et simple.

Si votre projet réside dans le répertoire IIS, vous pouvez toujours modifier le code, tout dépend de sa publication ou non. Vous rencontrerez tellement de problèmes sur Cassini vs IIS lorsque vous déboguez certains scénarios basés sur des permissions, comme l’authentification Kerberos et Ntlm ainsi que des problèmes tels que la compression du serveur, etc. tests approfondis lors de la publication sur IIS.