Quelle version de Cassini dois-je choisir pour la production?Il existe 8 versions publiques de 5 auteurs différents

StackOverflow https://stackoverflow.com/questions/5385006

Question

J'ai trouvé plusieurs versions d'un serveur Web Cassini sans IIS créé par Microsoft. Je l'utiliserais mais je ne suis pas sûr de celui qui est le meilleur, car il y a beaucoup de forks / builds:

Quel serveur Web recommandez-vous des fourches ci-dessus; Hostable Web Core est-il le nouveau Cassini, ou est-ce que j'ai toujours une dépendance sur IIS avec HWC?

Je vous serais reconnaissant de bien vouloir préciser:

  • La sécurité du projet
  • Si le fork est adapté pour servir une interface "Admin" légère
  • Fonctionnalités du site Web
  • Toute dépendance à IIS (telle que HWC).
Était-ce utile?

La solution

Voici un bref aperçu de mon point de vue actuel:

Aucun de ceux-ci, y compris mon code, ne convient à des fins de production. Les limites et les restrictions de l'utilisation des travailleurs simples que tous partagent ne se prêtent pas à des processus critiques à la mission (ce que je perçois comme signifiant «production»). Le moindre n'est pas l'incapacité totale de servir WCF (n'inclut pas les liaisons WebHttp, IIRC) sur une adresse IP autre que LoopBack. Une autre limitation est que toutes les demandes de service sous forme de file d'attente, une à la fois et à partir d'aujourd'hui, TOUTES les demandes sont traitées par le moteur d'exécution, y compris les fichiers texte et image statiques. Cela peut changer dans CassiniDev (le plus tôt possible si le financement est assuré). La mise en cache est également pratiquement inexistante dans toutes les implémentations de l'IIRC.

  • HWC nécessite IIS7
  • L'original est une pièce de musée
  • Dmitry a pris sa retraite de l'entreprise Cassini après que quelques-uns d'entre nous se soient séparés, alors ne cherchez pas de mises à jour là-bas. Son code est un bon point de départ si vous choisissez de démarrer un autre fork de Cassini pour une raison étrange.
  • Cassini ++ est le code de Dmitry avec quelques améliorations, principalement la possibilité d'utiliser une adresse IP externe, mais n'a eu aucune activité depuis avant de démarrer CassiniDev il y a 2 ans.
  • zippy1981 a initialement fourché Dmitry pour résoudre un problème de type de contenu après avoir été un peu paresseux dans sa mise en œuvre. Aucune activité depuis 04-2010

  • Je n'ai aucune expérience avec le port VB de MPosseth, semble en sommeil.

  • UtiDev a quelques fonctionnalités intéressantes telles que l'exécution en tant que service et n'est pas strictement un fork de Cassini. Il est gratuit et redistribuable mais est inactif depuis 2008.

CassiniDev est un outil que j'utilise beaucoup et les fonctionnalités le reflètent. Il prend en charge les versions 2.0, 3.5 et 4.0. Il est construit comme un exe, une dll et comme une baisse 100% compatible (améliorée) en remplacement du serveur de développement de Visual Studio. Il est adapté et facile à utiliser en testant des frameworks et des environnements d'intégration continue ainsi que des exe autonomes et intégrés dans vos propres applications.

Les dernières versions de WebDev.WebServer pour Visual Studio 2010 ont été exécutées via Reflector pour identifier les modifications et très peu ont été trouvées et l'intention a été implémentée dans CassiniDev.

Le développement est actif et a bénéficié d'un peu de financement d'entreprise pour piloter certaines des nouvelles fonctionnalités telles que; un point de terminaison virtuel pour renvoyer les résultats des tests html / javascript à NUnit, MSTest, etc. Un pilote de navigateur qui peut ouvrir un navigateur, servir une page et fermer le navigateur; un début rudimentaire d'un système de configuration prenant en charge les plugins, la seule implémentation actuelle est un plugin CORS qui enverra les en-têtes nécessaires pour prendre en charge le javascript inter-domaines via CORS, XDomainRequest et Flash.

La page de destination du codeplex montre son âge et la documentation n'a pas été mise à jour depuis des années mais la source montre l'activité et j'ai généralement des échantillons / tests qui permettent de démarrer rapidement les fonctionnalités. J'espère avoir le temps de rédiger des documents appropriés.

Les bogues sont corrigés et les fonctionnalités sont mises en œuvre lorsque le temps le permet.

De mon point de vue, le seul choix est entre CassiniDev et UtiDev. Évidemment, je choisis CassiniDev, en fonction de mes besoins, UtiDev pourrait être mieux adapté.

UtiDev est un très bon produit mais est en sommeil. Il a quelques fonctionnalités intéressantes que je vais éventuellement voler, telles que l'exécution en tant que service et la desserte de plusieurs sites sur une seule IP.

Mon .02. Bien qu'il puisse sembler que je branche sans vergogne mon propre travail, le fait est que j'utilise CassiniDev tous les jours en développement et en test, comme le font 100 (0?) Autres. Je suis heureux que d'autres trouvent de la valeur dans le travail, mais bien que je fasse de mon mieux dans la mesure du temps qui me le permet, je ne peux pas garantir le temps de réponse aux problèmes et aux fonctionnalités et je ne veux pas créer d'attentes inappropriées.

Autres conseils

UltiDev Cassini n'est pas réellement en sommeil. Son successeur, UltiDev Web Server Pro (UWS), est en cours de développement depuis plus d'un an et s'est rapproché d'IIS (en termes de fonctionnalités, pas de taille ou de complexité). Les versions de test d'UltiDev Web Server Pro sont publiées une fois toutes les quelques semaines et sont déjà assez stables.

Pour commenter certains des points de Sky:

  • Le nouvel UWS contourne le runtime ASP.NET lors de la diffusion de contenu statique.
  • UltiDev Cassini n'est pas limité aux adresses IP / noms d'hôte en boucle. Le nouvel UWS utilise le pilote du noyau http.sys comme écouteur - identique à IIS.
  • UltiDev Cassini et UWS effectuent des requêtes de file d'attente mais gèrent en parallèle par des threads regroupés.
  • L'incapacité de servir WCF avec WsHttpBinding n'est pas une limitation de SimpleWorkerRequests, mais plutôt de l'hypothèse de WCF que chaque fois qu'il est hébergé dans un ASP.NET AppDomain, il est hébergé soit IIS, soit Cassini d'origine, et rien d'autre. Les tentatives pour convaincre MS de changer qui ont duré plus de deux ans ont échoué. En fin de compte, WCF hébergé dans le domaine d'application ASP.NET conclut qu'il n'est sûr que lorsqu'il est sous IIS, sans faire une telle hypothèse lorsqu'il est hébergé par un processus .net aléatoire / domaine d'application sans ASP.NET. Pourtant, WCF avec BasicHttpBinding fonctionne bien.

Salutations, Vlad.

Vous pouvez essayer Mono XSP ou mod_mono avec un environnement Apache ou un serveur cgi rapide mono derrière un nginx! Quelle est votre motivation pour ne pas utiliser un IIS?

Mon travail est basé sur Cassini de Dmitry Robsman la version 4.0 de mon port VB est basée sur la dernière version que j'ai pu trouver à ce moment-là sur la page de Dmitry il sait que j'ai fait un port VB de son travail car il m'envoie un e-mail avec CC à Lisa Feigenbaum pour m'en remercier.

Je n'ai jamais reçu de commentaires d'une personne qui se plaignait que quelque chose ne fonctionnait pas, cela répondait juste à mes besoins comme il est (donc pas besoin de travailler dessus), je sais qu'il y avait dans le passé un CassineEX où se tenait l'EXpour Extended, j'ai téléchargé le truc et j'ai d'abord voulu utiliser celui-là, mais il était assez gonflé à mon avis, je voulais juste un serveur Web simple, petit et aussi rapide que possible, je n'avais pas besoin de fonctions de journal et de tous les autres éléments implémentésdans la version EX.

Mais comme vous le voyez, je supporte toujours la version VB de Cassini, elle n'est ni morte ni laissée pour compte ,,, :-)

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top