visual studio publicar net mvc from asp asp.net visual-studio iis cassini

asp.net - studio - ¿Cuáles son las(des) ventajas de utilizar Cassini en lugar de IIS?



visual studio 2015 publish to iis (28)

A menudo tomo lo mejor de ambos mundos y creo una aplicación en IIS, y uso el servidor web incorporado para una depuración más eficiente.

He descubierto que, en algunas ocasiones, puedo editar el origen mientras se depura, ¿hay alguna otra ventaja de usar el servidor web incorporado de Visual Studio en lugar de un directorio virtual en IIS?

Estoy usando Windows XP en mi entorno de desarrollo y una instancia local de IIS 5. Trabajo en varios proyectos, así que uso múltiples directorios virtuales para administrar todos los sitios diferentes.

¿Hay alguna desventaja?


Aquí hay una razón para una tercera vía: aunque UWS Pro está probablemente más cerca de IIS que de Cassini (aunque está inspirado en Cassini y es del proveedor de la bifurcación Cassini de UltiDev), su objetivo principal es ser redistributable junto con las aplicaciones ASP.NET.


Cassini es un servidor web de prueba ligero. La idea es que un desarrollador no necesita tener IIS instalado y configurado para probar su aplicación. Usa IIS si eres más familiar con él y lo tienes configurado y tu caja puede manejarlo. Cassini no pretende ser un reemplazo.


Cassini no es compatible con directorios virtuales


Cassini tampoco es compatible con páginas ASP clásicas. Este es solo un problema para los proyectos heredados donde todavía existen viejas páginas ASP (como nuestra aplicación web en el trabajo).


Cuando utiliza IIS en Vista o Windows 7 con UAC habilitado, debe ejecutar Visual Studio con derechos administrativos. Si hace esto, no puede arrastrar una gota de su shell a Visual Studio (incluso si ejecuta una instancia de explorer.exe como administrador).

Por esta razón uso Cassini para la mayoría de los proyectos.


El servidor integrado funciona bien para las grandes corporaciones que no desean otorgar a los desarrolladores ningún acceso de administrador en sus propias máquinas para configurar IIS.


El servidor integrado no es tan configurable y se ejecuta en un puerto impar, por lo que si cuenta con un comportamiento específico, puede ser problemático.


El servidor integrado significa que el desarrollador no tiene que saber cómo configurar IIS para probar su sitio.

Podría argumentar que esto es una desventaja, y que un desarrollador de Windows debería saber al menos ese IIS. O podría argumentar que un desarrollador que no es un administrador de sistemas no debería estar jugando con el servidor web en absoluto.


El servidor web de Visual Studio es menos indulgente con // en la ruta.

Se negará a servir un enlace como: http://localhost:52632/main//images/logo.jpg donde IIS lo hará.

Eso es bastante oscuro, pero significa que tenemos que arreglar mucho para deshacernos de todas las // ocurrencias.


El servidor web incorporado es un poco menos robusto que IIS, pero no requiere configuración, por lo que es solo una compensación.

Es posible que no siempre desee que sus proyectos de desarrollo estén expuestos en su servidor IIS (incluso su servidor IIS local), por lo que el servidor integrado es bueno para eso.

Sin embargo, si su aplicación va a acceder a recursos fuera de la norma para una aplicación web, entonces puede desear depurar con frecuencia en IIS para que su aplicación se ejecute con permisos restringidos y pueda ver dónde estarán los puntos débiles.


El servidor web incorporado para Visual Studio se llama Cassini y aquí hay algunas de sus limitaciones ...

  • Puede alojar solo una aplicación ASP.NET por puerto.
  • No es compatible con HTTPS.
  • No es compatible con la autenticación.
  • Responde solo a las solicitudes de localhost.
  • Inicio lento comparado con IIS

Este es un hilo viejo que comenzó hace 2 años. Me encontré con UtilDev Cassini mientras buscaba en Google. Me parece prometedor Al menos tiene la capacidad de ejecutar múltiples sitios simultáneamente. Esa característica es realmente útil para mí, porque trabajo en 2 sitios diferentes y tengo que cambiar continuamente entre ellos usando IIS.


FYI, Windows XP de 64 bits viene con IIS 6.


Instale IISAdmin, y puede configurar sitios separados en IIS 5, en lugar de utilizar directorios virtuales.


No puedes usar directorios virtuales :(


Otra desventaja es que envía todas las solicitudes a través del archivo global asax, que incluye todas las solicitudes de imágenes y hojas de estilo. Esto significa que si tienes un código que hace cosas con los nombres de los archivos, como una búsqueda, entonces los archivos auxiliares también se procesarán.


Parece que una tercera opción llegará pronto: IIS Express .


Si ''referencia web'' la url para servicios web que están en el servidor web incorporado, el puerto podría cambiar. A menos que haya establecido un "Puerto específico" mencionado en la página de opciones Proyecto-> Propiedades.

Esto es algo a lo que me he acostumbrado ahora. Siempre configuro un puerto específico. Ahora, cuando a veces el servidor web falla (he tenido que suceder), simplemente cambio el número de puerto, y todo está bien. Creo que reiniciar también arreglará esto.


Si su proyecto reside en el directorio de IIS, aún puede editar el código, solo depende si ha sido publicado o no. Te encontrarás con problemas en el Cassini vs IIS cuando estés depurando ciertos escenarios basados ​​en permisos, como la autenticación kerberos y ntlm, así como problemas como la compresión del servidor, etc. En general, la Cassini está bien para desarrollar, pero asegúrate de hacerlo. pruebas exhaustivas cuando se publica en IIS.


Si trabaja como hobby en casa usando XP Home, no puede instalar IIS localmente.


También a través de IIS, no tiene que preocuparse por recordar automáticamente y establecer un número de puerto estúpido en su url localhost. Eso es algo funky con el que se confía directamente Cassini ... un gran dolor en el culo. ¿Quién quiere recordar algún número de puerto externo? Simplemente ejecute el maldito sitio en IIS..plain y simple.


También hemos visto algunos problemas con el servidor integrado VS en relación con algunos controles de terceros que colocan sus scripts en la carpeta / aspnet_client. Como la carpeta no está allí cuando no se está ejecutando en IIS, los controles no funcionaron. Parece mucho más simple trabajar siempre con IIS y evitar problemas extraños.


Todas las respuestas anteriores son excelentes respuestas: he aquí una versión con Cassini que podría requerir IIS en el destkop.

Cassini se ejecuta en el contexto del desarrollador, no como el usuario de IIS (IUSR_, IWAM o en WinXP x64, el proceso w3wp). Esto puede ser un poco doloroso si tiene un sitio web que está accediendo a archivos externos o creando archivos temporales. Es más evidente cuando su desarrollador se está ejecutando como administrador de su escritorio.

Cuando te mueves al servidor IIS, algo a lo que tendrías acceso en Cassini no funciona de la misma manera. Normalmente, CACLing con IIS_WPG es todo lo que se necesita para solucionarlo, pero si el desarrollador no está pensando en esto, se frustrará rápidamente con su implementación.


Una diferencia que he encontrado es que el servidor de desarrollo maneja la carga de archivos de forma diferente que IIS. No se puede interceptar el error si el archivo que se está cargando es más grande que su configuración Max_File_Size. La página simplemente muere y devuelve un 500.



Otra desventaja con la que me he encontrado es en un sitio web autenticado de Forms que usa IPrincipal / IIdentity . Cassini cambiará los AppDomains sin previo aviso (o aviso).

Consulte esta publicación en el blog para obtener más información. El dolor de cabeza me hizo abandonar Cassini y seguir con IIS.


  • Necesita ejecutar Visual Studio para usarlo (en circunstancias normales)

  • Solo responde a localhost, por lo que no puede proporcionar el enlace http://simon-laptop:37473/app1 a un amigo para ver su sitio a través de la red.

  • Gran desventaja: es más difícil hacer funcionar el violín porque el tráfico del host local no se envía a través del proxy.

Editar: usando http://ipv4.fiddler:37473 es la mejor forma de hacer que Fiddler trabaje con él.