Diferencias en el comportamiento entre IIS y el servidor de desarrollo web ASP.Net?

Durante el desarrollo, generalmente pruebo las aplicaciones ASP.Net usando el Servidor de Desarrollo Web (a veces llamado Cassini). Ocasionalmente, cuando publico en un entorno real de IIS, noto que la aplicación se comporta de manera diferente.Diferencias en el comportamiento entre IIS y el servidor de desarrollo web ASP.Net?

Entonces, ¿cuáles son las diferencias entre la forma en que se comportan los servidores IIS de producción y el Servidor de desarrollo web ASP.Net? No me refiero a las diferencias en los conjuntos de características (claramente IIS tiene muchas características que no están presentes en WDS), sino diferencias en la forma en que manejan ASP.Net.

BTW: Hay algunas diferencias notadas en las respuestas a this question, pero estoy seguro de que debe haber más.

Fuente

2010-03-22 Kramii

Hay un montón de preguntas similares (véase la lista en el lado derecho), por ejemplo: http://stackoverflow.com/ preguntas/1988022/how-you-you-compare-iis-cassini-as-production-servers – M4N

De hecho, y he vinculado a uno de los más útiles en mi pregunta. Sin embargo, estoy buscando una respuesta más completa que la que encontré en otros lugares. – Kramii

¿No debería ser esto wiki de la comunidad? –

Algunas diferencias podrían ser:

No puede utilizar directorios virtuales mientras se trabaja con Cassini. Esto podría provocar un comportamiento inesperado al implementar por primera vez, debido a permisos de carpeta faltantes. (Por ejemplo, tiene un directorio/image/en su máquina local, pero en IIS/image/es el directorio virtual que señala elsehwere)
Algunos conjuntos de terceros (como ComponenArt Web DLL) causan problemas con problemas de puertos específicos. Lo mejor es para desarrollar con IIS para minimizar problemas de compatibilidad en la implementación.
TrustLevel del objetivo de IIS podría ser más baja que la configuración de desarrollo, esto podría provocar un funcionamiento incorrecto, dependiendo de lo que haces con el IIS, como leer el tiempo de actividad.

Fuente

2010-03-22 11:17:26 citronas

Su último punto es un poco desilusionante. El nivel de confianza, ya sea que trabaje con Cassini o con IIS en la * misma * máquina, siempre evaluará de la misma manera. Cuando implemente en producción, no importará si desarrolló su aplicación en Cassini o IIS porque el nivel de confianza no está controlado por el servidor. – Kev

Gracias por mencionar – citronas

lo siento citronas - se equivoca en el punto 1,/v: "/" es el valor predeterminado, pero puede especificar cualquier profundidad de vdir que desee, tanto desde la página de propiedades web como desde la línea de comandos. El punto 2 realmente no tiene sentido. 'Alguna gente dice'. Y el número 3 ya ha sido cubierto. No tengo más remedio que -. Aclamaciones. –

Algunas cosas que he recogido here y en otros lugares:

El contexto de seguridad en el que los respectivos servidores ejecutan aplicaciones ASP.NET es diferente. Para el servidor Dev, esta es la cuenta del usuario actual. Para IIS, este es el contexto del usuario especial (ASPNET o SERVICIOS DE RED) que generalmente tiene privilegios limitados.
Para un sitio web, el servidor de desarrollo somete los archivos estáticos (imágenes y hojas de estilos, etc.) a la autorización de ASP.NET. Sin embargo, IIS sirve archivos estáticos sin usar reglas de autorización.
El servidor de desarrollo no es compatible con SMTP, por lo que no puede enviar correos electrónicos directamente desde este servidor.
El servidor de desarrollo no es compatible con HTTPS.
Existe una diferencia en la forma en que los dos servidores manejan las rutas que contienen "//". Según los informes, el servidor Dev es más indulgente.
El Dev puerto elegido al azar en lugar del puerto HTTP estándar 80.

Fuente

2010-03-22 11:35:25 Kramii

Diferencias en el comportamiento entre IIS y el servidor de desarrollo web ASP.Net?

Respuesta

Cuestiones relacionadas