publicar net deploy asp asp.net host asp.net-core

asp.net - deploy - publicar net core en iis



ASP.NET vNext es host agnóstico, ¿qué significa en profundidad? (2)

La historia del hosting ASP.NET

En 2002, había básicamente un servidor web para la plataforma .NET, y eso era IIS. Unos años más tarde, el servidor web de desarrollo de Visual Studio ("Cassini", anteriormente parte de la matriz web original) apareció como un servidor de solo desarrollo. Pero todos estos finalmente utilizaron System.Web como la capa de alojamiento entre la aplicación y el servidor web. El host System.Web está estrechamente vinculado a IIS y es muy difícil de ejecutar en otros hosts. Incluso la implementación en el servidor web VS Dev fue limitada porque solo admitía ciertas características. Por lo tanto, como tal, todavía había un solo "host" de calidad de producción para las aplicaciones ASP.NET típicas que dependían de System.Web.

Avance rápido alrededor de una década y OWIN convirtió en una interfaz entre aplicaciones y servidores web. Esto permitió a cualquier aplicación compatible con OWIN hablar a través de OWIN a un servidor web que tenía una capa de alojamiento compatible con OWIN. Microsoft escribió Katana como una implementación de OWIN que podría alojar ASP.NET Web API, ASP.NET SignalR y muchos frameworks de terceros sobre varios servidores, incluidos IIS (e IIS Express), el servidor de host propio de Katana y hosts personalizados ( es decir, ejecutar el host de Katana en una aplicación personalizada). Hay otra implementación de OWIN llamada Nowin que debería poder ejecutar las mismas aplicaciones que Katana. Este es un ejemplo de agnosticismo del anfitrión.

Ahora avanzamos rápidamente unos años más y está ASP.NET vNext , que sigue un modelo muy similar a OWIN en términos de tener middleware y tener agnosticismo de host. ASP.NET vNext también tiene capas de compatibilidad para los componentes de la aplicación de middleware OWIN.

ASP.NET vNext host agnosticism

ASP.NET vNext es host agnost de la misma manera que Katana y OWIN. Las aplicaciones escritas usando ASP.NET vNext solo conocen una capa de abstracción del host, como la IApplicationBuilder (anteriormente IBuilder ). Las aplicaciones no hablan directamente con el servidor web. Gran parte de esta abstracción se realiza a través de "interfaces de funciones" para que algunos servidores puedan implementar características y otros puedan elegir no hacerlo.

Opciones de alojamiento web

Las aplicaciones ASP.NET vNext se pueden hospedar en IIS, IIS Express, su propio EXE personalizado, en el nuevo servidor Kestrel multiplataforma y, sin duda, más hosts en el futuro.

Ni Katana ni ASP.NET vNext son reemplazos para IIS u otros hosts, aunque ambos tienen servidores web alternativos. IIS admite algunas características más avanzadas en comparación con Katana y ASP.NET vNext, como el calentamiento de aplicaciones y la gestión de vida útil de las aplicaciones (es decir, qué hacer cuando falla la aplicación, controlar cuánta memoria usa y otros tipos de aceleración) , administración remota, etc.

Beneficios de OWIN, ASP.NET vNext y ser host agnóstico

No puedo hablar sobre las motivaciones para crear OWIN porque nunca formé parte de ese grupo. Pero los méritos de tener una abstracción de servidor de servidor web son muchos:

  • Puede cambiar entre hosts con relativa facilidad. Por ejemplo, es común ejecutar localmente en un servidor de solo desarrollo que se puede ejecutar con permisos mínimos. Luego, al desplegar en producción, quizás se use un host con más funciones como IIS. IIS, sin embargo, requiere permisos administrativos para instalar, que no todos tienen en sus estaciones de trabajo.
  • Más opciones de alojamiento pueden existir. De regreso en el día debido a la estrecha dependencia de ASP.NET en IIS, solo podía existir un host, por lo que efectivamente no había "mercado" para otros hosts.
  • Ciertos tipos de pruebas son más fáciles de escribir teniendo un host de prueba en memoria. Esto se usa con bastante frecuencia para probar toda la pila de una aplicación web, pero sin llamadas a la red.

Las motivaciones para ASP.NET vNext se enumeran en parte en el sitio oficial ASP.NET vNext en el tutorial de Introducción . Un breve resumen es: tener una plataforma multiplataforma, de código abierto, lado a lado, pago por uso, host-agnostic para la creación de aplicaciones y servicios web. Suena como algo de marketing, pero estos son todos aspectos clave del sistema. NodeJS ofrece prácticamente el mismo conjunto exacto de características, aunque, por supuesto, una vez que se observan los detalles, existen muchas diferencias de implementación y, sin duda, también diferencias filosóficas más profundas. Las motivaciones para admitir estas características generalmente son autoexplicativas.

Audiencia para ASP.NET

Tenga en cuenta que esto se trata de la audiencia de ASP.NET en general, que incluye todo, desde formularios web ASP.NET, a MVC, API web, SignalR, Katana y ASP.NET vNext. Cualquiera de estos marcos es adecuado para cualquier proyecto de tamaño y debe ser utilizable por cualquier desarrollador razonablemente experto. Esto es evidente al observar los tamaños de los proyectos que los usan. Este mismo sitio (StackOverflow.com) está construido en parte usando ASP.NET MVC, por algunos desarrolladores muy avanzados (supongo), sin embargo, hay muchos sitios mucho más pequeños que usan MVC construido por novatos relativos. ASP.NET vNext es la versión futura de la mayoría de estos mismos marcos, y como tal apunta al mismo tipo de aplicaciones y al mismo tipo de desarrolladores.

Más información

Para obtener más información sobre ASP.NET vNext y OWIN, consulte una publicación de blog de uno de los desarrolladores: http://whereslou.com/2014/06/10/asp-net-vnext-moving-parts-owin/

De acuerdo con ASP.NET vNext tutorial : vNext is host agnostic . You can host your app in IIS, or self-host in a custom process vNext is host agnostic . You can host your app in IIS, or self-host in a custom process

¿Alguien podría ayudarme a entender esto en profundidad al mostrar la diferencia entre el host asp.net actual y el nuevo?

Teniendo en cuenta que vNext sigue siendo un objeto de movimiento rápido y muy brillante, tal como están las cosas actualmente, es una especie de "medio" host agnóstico.

La especificación de middleware que define y aplica no permite una interfaz muy genérica para organizar programas. Entonces la forma en que desarrollas es la misma. Pero las aplicaciones vNext son en sí mismas servidores y, de forma extraña, actualmente se les exige que incluyan bibliotecas de pegamento para el tipo de servidor que está utilizando.

Puede observar esto al ver que debe proporcionar el tipo de servidor que desea usar dentro de su archivo project.json . Si los proyectos vNext fueran realmente agnósticos, seleccionaría un servidor a nivel de sistema y apuntaría a, montará o ejecutará su aplicación desde el servidor elegido.

Es un poco complicado debido a los ciclos de vida implicados, después de que termines aquí, te animo a que te dirijas a este problema de github en el proyecto vNext, en el que intento abogar por un diseño verdaderamente desacoplado.