ASP.NET Development Server o Localhost IIS?

Question

Actualmente, nuestro equipo de desarrollo configura todos los sitios web en los que están trabajando en IIS en su máquina local. Estamos pensando en cambiar al uso del servidor de desarrollo ASP.NET incorporado en su lugar.

¿Es esta una buena idea? ¿Cuáles son los pros/contras de usar el servidor de desarrollo ASP.NET? ¿Hay algún problema que debemos tener en cuenta?

Gracias.

NB: El ejecutarse en Windows XP/IIS 5/VS2005

Editar:

No nos dimos cuenta que se llama Cassini .. Más respuestas para Cassini v IIS here.

Answer 1

No hay nada que el ASP.NET Dev WebService pueda hacer que IIS no pueda (Puede establecer puntos de interrupción, etc., simplemente conecte el depurador VS al tiempo de ejecución de ASP.NET).

Sin embargo, el ASP.NET Dev WebService no representa un verdadero entorno de producción, y como tal, puede quedar atrapado por errores que no esperaría al implementar en producción.

Por eso, ordeno que todo el desarrollo se realice mediante IIS en una máquina local. No requiere mucho trabajo configurar un sitio en IIS.

Answer 2

sé que en un momento dado tuve un problema con la autenticación no funciona como se esperaba en la Cassini (construido en el servidor de desarrollo)

Además, si usted necesita probar cosas como plugins ISAPI (un re-escritor, por ejemplo) No estoy seguro de cómo se hace eso en Cassini.

El puerto en constante cambio también es bastante desconcertante para mí. Además, para cada proyecto web en su solución, se activa otra instancia de un servidor Casini, y cada uno lleva de 20 a 50 MB de memoria.

utilizo IIS todo el tiempo, es bastante fácil de instalar, y ustedes ya lo están haciendo ...

Answer 3

Es una muy buena idea. Aquí hay algunas razones para:

• Ya no necesitan acceso de administrador a su máquina para el desarrollo web (que todavía puede ser útil).
• Es mucho más fácil probar un cambio rápido y continuar el trabajo, y faster iteration cycles are good.
• Puede simplificar la configuración y la implementación de sus entornos de desarrollo.
• La versión XP de IIS tiene limitaciones que no están presentes en la versión de servidor que Cassini da pasos laterales.

El único argumento en contra de que sé es que hay un par de bordes muy raros casos en que el servidor integrado de Cassini no hace exactamente IIS imitan porque usted está utilizando números de puerto impares. Dudo que alguna vez te encuentres con ellos, y usando Cassini como el entorno primario de desarrollo no impide que los desarrolladores también tengan acceso a IIS en la máquina. De hecho, mi configuración preferida es Cassini primero para la mayoría del trabajo pequeño, luego se implementa en mi IIS local para realizar más pruebas en profundidad antes de volver a mover el código al repositorio de origen compartido.

[Editar]
olvidó de URL re-escritura. Necesitas IIS para eso. Y un ejemplo de una limitación del XP IIS incorporado es que está limitado a un sitio en XP (puede tener múltiples aplicaciones, pero eso es algo diferente).

Answer 4

He utilizado ambos métodos y prefiero tener IIS localmente en lugar de utilizar el servidor integrado. Por lo menos, es más coherente con la configuración de implementación final.

Answer 5

Tuve que cambiar (volver) a IIS para un proyecto, porque necesitaba establecer algunos directorios virtuales que no es posible en el Servidor web de desarrollo ASP.NET.

Answer 6

Además, cuando use IIS 5.1, asegúrese de obtener JetStat IIS Admin, agrega funcionalidad deshabilitada de fábrica en IIS 5, como la posibilidad de configurar varios sitios.

Answer 7

Como dije aquí: https://stackoverflow.com/questions/103785/what-are-the-disadvantages-of-using-cassini-instead-of-iis sus desarrolladores deben ser conscientes de que Cassini se ejecuta como el usuario local, que generalmente es una cuenta de administrador para los desarrolladores. El desarrollo podrá acceder a cualquier archivo o recurso que su cuenta pueda, que es bastante diferente de lo que verán en un servidor IIS 6.

La otra cosa que llama la atención es que la depuración de servicios web es mucho más fácil usando IIS y vdirs en lugar de separar las instancias de Cassini.

Answer 8

se han topado con las siguientes limitaciones con el servidor asp.net dev:

1. no admite directorios virtuales. Si los necesita en su aplicación, IIS parece ser su única opción

2. Las páginas asp clásicas no se ejecutan en el servidor de desarrollo. Así que si usted tiene una aplicación web mixta (como tengo a mi cliente en este momento), IIS parece ser la solución

3. Si necesita una interfaz de usuario de administración para configurar los ajustes, IIS funciona mejor

Por supuesto, IIS requiere que seas un administrador local.

Answer 9

El problema principal que he encontrado con el servidor de desarrollo es SerializationExceptions con principios de seguridad personalizados almacenados en el contexto del hilo. Detalles here.

Answer 10

Otra distinción que noté es que Cassini se ejecuta como un proceso de 32 bits y usted no tiene control sobre él, mientras que puede controlar el grupo de aplicaciones de su aplicación IIS para rechazar 32 bits (suponiendo que su IIS se ejecuta en un Servidor de 64 bits). Esto se vuelve especialmente importante si su aplicación web llamará a las API en procesos de 64 bits como SharePoint Foundation/Server 2010. Cuando depure su aplicación web con Cassini como su servidor de depuración, obtendrá "La aplicación web en url podría no ser encontrado. Verifique que ha escrito correctamente la URL "escriba errores al crear instancias de objetos. Si depura usando IIS con la aplicación que se ejecuta en un grupo de aplicaciones que se ejecuta como 64 bits con una identidad que permite el acceso a la base de datos de SharePoint, entonces podrá depurar correctamente.

Answer 11

En VS12, el servidor de desarrollo es muy lento, toma unos segundos descargar un archivo de 2kbytes. Esto no sucedió en vs10. Cuando tienes un montón de archivos jquery y CSS esto es un problema real. Además, cada página vuelve a consultar todos los archivos css/js. Prueba de regresión muy muy lenta.