¿Qué es ASP.NET?

ASP.NET es un framework de de­sa­rro­llo web del lado del servidor creado por Microsoft y altamente de­sa­rro­lla­do. ASP.NET se utiliza para crear páginas web dinámicas, apli­ca­cio­nes web y servicios basados en web. Después de décadas de de­sa­rro­llo, el framework sigue exi­s­tie­n­do bajo el nombre de ASP.NET Core.

De­sa­rro­lla­do ori­gi­na­l­me­n­te por Microsoft, ASP.NET ahora depende de la .NET Fou­n­da­tion. Si bien las primeras versiones se pu­bli­ca­ron como software pro­pie­ta­rio, el ASP.NET moderno es un proyecto de código abierto.

El ASP.NET que se utiliza hoy en día es el resultado de décadas de de­sa­rro­llo, una tra­ye­c­to­ria que comenzó con ASP para pasar a ASP.NET y, fi­na­l­me­n­te, a ASP.NET Core. En co­n­so­na­n­cia con los avances de la te­c­no­lo­gía web, el framework ha ido cambiando drá­s­ti­ca­me­n­te a lo largo de los años. Primero, vamos a echar un vistazo a la historia del de­sa­rro­llo de ASP.NET:

El Active Server Pages (ASP) original fue el primer lenguaje de scripting del lado del servidor publicado por Microsoft. Lanzado en 1996, Active Server Pages permitía crear páginas web en el servidor de manera dinámica. Otros lenguajes de se­cue­n­cias de comandos suelen depender de Linux como sistema operativo y de un servidor web de código abierto, como Apache. Por el contrario, Microsoft posicionó Active Server Pages como parte del Internet In­fo­r­ma­tion Server (IIS), que se ejecuta en Windows.

La fu­n­cio­na­li­dad básica de ASP puede co­m­pa­rar­se con la de PHP o la de Java Server Pages (JSP). En las tres te­c­no­lo­gías se utilizan archivos de plantilla, que contienen fra­g­me­n­tos de código eje­cu­ta­bles in­cru­s­ta­dos en contenido HTML estático. El código se escribe entre etiquetas es­pe­cia­les para separarlo del HTML. Los dialectos es­pe­cí­fi­cos de Microsoft di­s­po­ni­bles en aquel momento, VBScript, JScript y Pe­r­l­S­cri­pt, se uti­li­za­ban como lenguajes de pro­gra­ma­ción.

Cuando el navegador accede a una URL (“request”), el código se ejecuta en el servidor. La ejecución genera contenido HTML que se inserta en las es­tru­c­tu­ras HTML pre­de­fi­ni­das. En general, el resultado es un documento que consta de contenido HTML estático y generado di­ná­mi­ca­me­n­te, y que se entrega como una respuesta al navegador (“response”) y se muestra al usuario. Cualquier cambio en el contenido de la página, por ejemplo, debido a las entradas del usuario, requería un ciclo completo de request-response y, por lo tanto, que se volviera a cargar la página. A co­n­ti­nua­ción, se muestra un ejemplo de código ASP:

ASP todavía no era un framework. Por el contrario, empleaba unos pocos objetos sueltos sin relación entre sí. A partir de ellos, se tejía un sitio web dinámico:

• Ap­pli­ca­tion
• Request
• Response
• Server
• Session
• ASPError

ASP.NET, el sucesor del ASP clásico, se presentó en el año 2003. En lugar de unos pocos objetos sueltos, utilizaba el framework .NET como una su­b­e­s­tru­c­tu­ra que englobaba los procesos que se requerían con fre­cue­n­cia, como el acceso a las bases de datos o la au­te­n­ti­ca­ción y la au­to­ri­za­ción de usuarios. En conjunto, ASP.NET podría co­m­pa­rar­se a fra­me­wo­r­ks de Java como Struts o Spring.

ASP.NET incluía los fo­r­mu­la­rios Web Forms como ca­ra­c­te­rí­s­ti­ca decisiva. El enfoque de Web Forms permitía a los de­sa­rro­lla­do­res de Windows ex­pe­ri­me­n­ta­dos programar páginas web dinámicas. Los me­ca­ni­s­mos su­b­ya­ce­n­tes a la web pe­r­ma­ne­cían ocultos a los de­sa­rro­lla­do­res, que podían seguir re­cu­rrie­n­do a los flujos de trabajo y entornos de de­sa­rro­llo que les eran fa­mi­lia­res. En pa­r­ti­cu­lar, se uti­li­za­ban he­rra­mie­n­tas visuales es­pe­cí­fi­cas de Microsoft para el de­sa­rro­llo rápido de apli­ca­cio­nes o Rapid Ap­pli­ca­tion De­ve­lo­p­me­nt (RAD).

Los fo­r­mu­la­rios Web Forms permitían a los de­sa­rro­lla­do­res de Windows avanzar rá­pi­da­me­n­te con la pro­gra­ma­ción web. Sin embargo, al mismo tiempo, el enfoque limitaba el grado de control sobre las páginas HTML en­tre­ga­das. Poco tiempo después, con ASP.NET MVC, se introdujo un modelo de de­sa­rro­llo al­te­r­na­ti­vo. Este seguía el patrón es­ta­ble­ci­do de modelo-vista-co­n­tro­la­dor (MVC) y permitía im­ple­me­n­tar de manera más limpia el principio de la se­pa­ra­ción de intereses (se­pa­ra­tion of concerns). Basado en el innovador marco Ruby on Rails, ASP.NET MVC ofrecía una buena fu­n­cio­na­li­dad para el andamiaje de los proyectos.

Ac­tua­l­me­n­te, ASP.NET ha sido re­em­pla­za­do por ASP.NET Core, el de­sa­rro­llo posterior. Sin embargo, ambos nombres se utilizan a menudo como sinónimos.

Con el la­n­za­mie­n­to de ASP.NET Core, la or­ga­ni­za­ción del framework cambió por completo. A medida que Microsoft co­n­ti­nua­ba con su tendencia hacia el código abierto, el de­sa­rro­llo de ASP.NET Core se puso bajo los auspicios de la .NET Fou­n­da­tion. El código fuente del proyecto está di­s­po­ni­ble bajo una licencia de código abierto.

A nivel técnico, ASP.NET Core es una versión re­di­se­ña­da de ASP.NET 4.0, que aúna los co­m­po­ne­n­tes de ASP.NET que han ido surgiendo or­gá­ni­ca­me­n­te. El framework hace posible el de­sa­rro­llo de proyectos con ASP.NET Core y el hosting fuera del eco­si­s­te­ma de Windows. En Windows, ASP.NET Core se basa en el framework .NET, mientras que, en otros sistemas ope­ra­ti­vos, se utiliza el framework .NET Core.

De acuerdo con los avances en la te­c­no­lo­gía web, ASP.NET Core es co­m­pa­ti­ble con el uso en la nube. Además del tra­di­cio­nal Internet In­fo­r­ma­tion Server (IIS) de Microsoft, como entorno de alo­ja­mie­n­to de ASP.NET se utilizan co­n­te­ne­do­res y entornos de servidor abiertos. El framework admite código del lado del cliente y enfoques modernos para la pro­gra­ma­ción reactiva. Esto significa que ASP.NET Core es co­m­pa­ra­ble a fra­me­wo­r­ks basados en Ja­va­S­cri­pt como React.

Con el framework ASP.NET se pueden im­ple­me­n­tar proyectos web de todo tipo. En pa­r­ti­cu­lar, es adecuado para páginas web dinámicas y apli­ca­cio­nes web, incluidas las apli­ca­cio­nes de página única o single page app (SPA). También se pueden im­ple­me­n­tar servicios basados en web, como API y sistemas para co­mu­ni­ca­ción en tiempo real. A lo largo de los años, el entorno se ha utilizado con diversos enfoques para di­fe­re­n­tes fines. A co­n­ti­nua­ción, los veremos con más detalle y re­su­mi­re­mos su tra­ye­c­to­ria.

Con el avance de las te­c­no­lo­gías web a partir de la década de 2000, se han ido in­co­r­po­ra­n­do nuevos enfoques al de­sa­rro­llo web en ASP.NET. Ima­gí­na­te­los como una caja de he­rra­mie­n­tas bien or­ga­ni­za­da, con di­fe­re­n­tes he­rra­mie­n­tas di­s­po­ni­bles para cada tipo de proyecto. De­pe­n­die­n­do de los re­qui­si­tos, se pueden combinar varios enfoques en un mismo proyecto. Con el la­n­za­mie­n­to de ASP.NET Core, numerosos modelos de pro­gra­ma­ción de­sa­rro­lla­dos de manera orgánica se reunieron bajo un mismo framework, lo que ayudó a si­m­pli­fi­car la elección del enfoque más adecuado para cada situación.

Con el clásico Web Forms, las páginas se ensamblan a partir de co­m­po­ne­n­tes pre­de­fi­ni­dos. Se utilizan unos módulos de fo­r­mu­la­rios de aspecto visual y cada co­m­po­ne­n­te se coloca mediante la función de arrastrar y soltar. Esto les resultaba es­pe­cia­l­me­n­te atractivo a los de­sa­rro­lla­do­res con ex­pe­rie­n­cia pro­gra­ma­n­do en Windows, ya que les permitía utilizar las he­rra­mie­n­tas para el de­sa­rro­llo rápido de apli­ca­cio­nes (RAD) con las que estaban fa­mi­lia­ri­za­dos, con la di­fe­re­n­cia de que el producto final no era una apli­ca­ción de Windows, sino una página web dinámica.

El enfoque de Web Forms se basa en el modelo de código su­b­ya­ce­n­te (code-behind) de Microsoft, que obliga a seguir el principio de la se­pa­ra­ción de intereses:

• Los archivos de plantilla con la extensión .aspx definen la es­tru­c­tu­ra HTML de la página y contienen ma­r­ca­do­res de posición para el contenido generado di­ná­mi­ca­me­n­te.
• La propia lógica de la apli­ca­ción se tra­n­s­fie­re a un archivo separado con la extensión .aspx.cs o .aspx.vb. Se trata del archivo code-behind del mismo nombre.
• El cliente recupera el archivo .aspx di­s­po­ni­ble en una URL. Los co­m­po­ne­n­tes estáticos y dinámicos se combinan en el servidor. El documento HTML re­su­l­ta­n­te se entrega al cliente.
• Con cada entrada del usuario en la página, los datos se tra­n­s­fie­ren a la misma URL a través de una solicitud GET o POST y se procesan mediante el archivo code-behind.

Se adopta un enfoque orientado a objetos para im­ple­me­n­tar la lógica de la apli­ca­ción: el archivo code-behind define una clase derivada. El lenguaje de pro­gra­ma­ción utilizado suele ser C# o Visual Basic. Es in­te­re­sa­n­te que el archivo code-behind se pre­co­m­pi­le solo una vez, lo que conlleva una ejecución más rápida y una mayor re­si­s­te­n­cia frente a errores cuando se llama a la página.

En co­n­tra­po­si­ción con el ASP original, los fo­r­mu­la­rios Web Forms re­pre­se­n­ta­ban un paso decidido hacia la se­pa­ra­ción de intereses. Con ASP, los co­m­po­ne­n­tes de código y HTML estático se co­m­bi­na­ban en un solo archivo. En cambio, con Web Forms, se producía una se­pa­ra­ción entre el archivo de plantilla y el archivo code-behind. Con ASP.NET MVC, se añadió otro modelo de pro­gra­ma­ción a ASP.NET, que permitía el de­sa­rro­llo web basado en el patrón de modelo-vista-co­n­tro­la­dor (MVC).

El patrón MVC distingue entre la lógica de la apli­ca­ción (“modelo”), la plantilla de vi­sua­li­za­ción (“vista”) y la in­ter­ac­ción del usuario (“co­n­tro­la­dor”). Una de las ventajas del enfoque de MVC es que cada concepto se puede someter mejor a pruebas. Además, la se­pa­ra­ción de intereses permite utilizar di­fe­re­n­tes co­n­tro­la­do­res. En lugar de enviar toda la entrada del usuario a un único URL y volver a cargar la página, se usa AJAX a través de jQuery, por ejemplo. Esto permite que se vuelvan a cargar partes de la página. Con ASP.NET Core MVC, la tradición de ASP.NET MVC se perpetúa en la versión actual del framework.

ASP.NET Web Forms y ASP.NET MVC son adecuados para de­sa­rro­llar páginas web complejas. Si necesitas varias páginas con co­m­po­ne­n­tes re­uti­li­za­bles, ambos modelos de pro­gra­ma­ción son ideales. Pero ¿y si no las necesitas? Su­po­n­ga­mos que queremos crear una página web sencilla que conste de una sola página o solo unas pocas. Hay algunos co­m­po­ne­n­tes dinámicos, pero la atención se centra más en un diseño so­fi­s­ti­ca­do que en una lógica de apli­ca­ción compleja y en el pro­ce­sa­mie­n­to de la entrada del usuario. En este caso, sería excesivo definir clases propias o es­fo­r­zar­se en la se­pa­ra­ción de acuerdo con el modelo MVC.

ASP.NET Web Pages es ideal para los casos en que la lógica de la apli­ca­ción tiene menos pro­ta­go­ni­s­mo que un diseño y una pre­se­n­ta­ción so­fi­s­ti­ca­dos. En este modelo, similar al PHP o al ASP clásico, dentro del archivo se combinan es­tru­c­tu­ras HTML estáticas y co­m­po­ne­n­tes de código dinámico. Para ello se utiliza una sintaxis especial. ASP.NET Web Pages es es­pe­cia­l­me­n­te adecuado para crear páginas de ate­rri­za­je (en inglés, landing pages).

Todos los modelos de pro­gra­ma­ción pre­se­n­ta­dos hasta ahora tienen como objetivo generar contenido HTML para el usuario humano. Además, ASP.NET Framework contiene modelos que se utilizan para pro­po­r­cio­nar una in­frae­s­tru­c­tu­ra para los proyectos web. ASP.NET Web API es un modelo de pro­gra­ma­ción para crear API REST. El acceso a los puntos finales de la API se realiza a través de AJAX. Como formato para la tra­n­s­mi­sión de datos, se utiliza JSON o XML.

ASP.NET WebHooks es una im­ple­me­n­ta­ción del patrón WebHooks. Los webhooks permiten publicar y su­s­cri­bi­r­se a eventos que tienen lugar en un sistema. Puede tratarse, por ejemplo, de cargar un archivo o recibir un pago. Un su­s­cri­p­tor registra el cambio, que se rastreará con el sistema de pu­bli­ca­ción. Para ello, tra­n­s­fie­re una URL: el WebHook del mismo nombre. Cuando tiene lugar el evento re­gi­s­tra­do, el sistema de pu­bli­ca­ción llama al WebHook y el su­s­cri­p­tor es informado del evento.

SignalR es un marco para la co­mu­ni­ca­ción en tiempo real entre cliente y servidor. Este framework se basa en el estándar We­b­So­c­kets y permite la tra­n­s­fe­re­n­cia bi­di­re­c­cio­nal de datos. Los na­ve­ga­do­res que no son co­m­pa­ti­bles con We­b­So­c­kets pasan a ser ge­s­tio­na­dos por me­ca­ni­s­mos de reserva. SignalR suele uti­li­zar­se para im­ple­me­n­tar servicios de chat basados en navegador y software de vi­deo­co­n­fe­re­n­cias.

ASP.NET Core es el sucesor de ASP.NET. El framework ASP.NET Core fue reescrito por completo, pero es altamente co­m­pa­ti­ble con su pre­de­ce­sor. Los co­m­po­ne­n­tes de ASP.NET an­te­rio­r­me­n­te separados se han fusionado en la versión Core. Además, algunos co­m­po­ne­n­tes se han de­sa­rro­lla­do desde cero, ma­n­te­nie­n­do los nombres que tenían en la versión anterior. Por ello, el framework SignalR existe tanto en ASP.NET como en ASP.NET Core. Vamos a echar un vistazo a las pri­n­ci­pa­les novedades que ha aportado el de­sa­rro­llo de ASP.NET Core.

Con ASP.NET Core MVC, se han combinado las fu­n­cio­na­li­da­des de ASP.NET MVC y ASP.NET Web API. De esta manera, se pueden de­sa­rro­llar apli­ca­cio­nes web altamente dinámicas con una interfaz de usuario modular y una API su­b­ya­ce­n­te. En el proceso, el framework .NET Core se utiliza como una su­b­e­s­tru­c­tu­ra común. Los conocidos enfoques de .NET para el de­sa­rro­llo con API se pueden aplicar al de­sa­rro­llo con MVC y viceversa.

Razor Pages cubre un nicho similar al que cubría ASP.NET Web Pages en el pasado. Conviene uti­li­zar­lo cuando el patrón de modelo-vista-co­n­tro­la­dor supone una so­bre­ca­r­ga in­ne­ce­sa­ria. Si, por ejemplo, se quiere crear una página de ate­rri­za­je, con Razor Pages se puede im­ple­me­n­tar de manera fácil. La sintaxis de Razor se utiliza para crear la plantilla de la página. Como es habitual en el universo .NET, se puede emplear C# y Visual Basic como lenguajes de pro­gra­ma­ción.

Vamos a ver un ejemplo de una Razor Page. Cabe destacar que, como signo de apertura, se utiliza @ en lugar de las etiquetas de código de apertura y cierre ha­bi­tua­les en los lenguajes de pla­n­ti­llas:

El framework Blazor se basa en la sintaxis de Razor antes me­n­cio­na­da; de hecho, el nombre de Blazor proviene de “Browser + Razor”. Como sugiere el nombre, Blazor se centra en el navegador como entorno de ejecución. Con Razor Pages, las in­ter­ac­cio­nes del usuario se procesan en el servidor. Blazor, por su parte, permite la pro­gra­ma­ción reactiva, en la que cada co­m­po­ne­n­te de la página reacciona di­ná­mi­ca­me­n­te a los cambios en el navegador. Esto hace que Blazor sea más o menos co­m­pa­ra­ble a las te­c­no­lo­gías React, Angular y Vue.

A co­n­ti­nua­ción, te mostramos un ejemplo sencillo de pro­gra­ma­ción reactiva con Blazor. Vi­n­cu­la­mos el valor de un campo de entrada a la variable “name”. Se utiliza la sintaxis de Razor:

Además de la pro­gra­ma­ción reactiva, hay otra ca­ra­c­te­rí­s­ti­ca de Blazor que resulta muy in­te­re­sa­n­te: a través de We­bA­s­se­m­bly, los lenguajes .NET se pueden compilar para ser eje­cu­ta­dos en el navegador. Por lo tanto, a menudo se hace re­fe­re­n­cia a la expresión “.NET in the browser” cuando se habla de Blazor. La ventaja es que el código del lado del cliente no tiene que es­cri­bi­r­se en Ja­va­S­cri­pt. En cambio, el de­sa­rro­llo se realiza en C# o Visual Basic. El código puede acceder a los conocidos co­m­po­ne­n­tes del framework .NET.

Con ASP.NET o ASP.NET Core, los usuarios disponen de un entorno muy de­sa­rro­lla­do para crear una amplia variedad de proyectos web. El marco incluye lenguajes de pro­gra­ma­ción, editores de código e IDE, así como he­rra­mie­n­tas de de­sa­rro­llo y un flo­re­cie­n­te eco­si­s­te­ma de paquetes di­s­po­ni­bles de forma gratuita. Hoy en día se utilizan métodos modernos como la pro­gra­ma­ción reactiva, We­b­So­c­kets y We­bA­s­se­m­bly. Tra­di­cio­na­l­me­n­te, la mayor de­s­ve­n­ta­ja de utilizar ASP.NET era su estrecha relación con Microsoft y la co­n­si­guie­n­te de­pe­n­de­n­cia del proveedor. Con la continua apertura hacia el código abierto, han di­s­mi­nui­do las ob­je­cio­nes en ese sentido.

Los de­sa­rro­lla­do­res fa­mi­lia­ri­za­dos con la pro­gra­ma­ción en el eco­si­s­te­ma de Microsoft son los que más ventajas obtienen de trabajar con ASP.NET, ya que les permite recurrir fá­ci­l­me­n­te a los lenguajes, he­rra­mie­n­tas y flujos de trabajo que ya conocen. El framework .NET, altamente de­sa­rro­lla­do, se utiliza como su­b­e­s­tru­c­tu­ra de ASP.NET, lo que significa que hay co­m­po­ne­n­tes adecuados para gran variedad de apli­ca­cio­nes, una gran ventaja a la hora de de­sa­rro­llar apli­ca­cio­nes complejas de forma rápida y con re­su­l­ta­dos fiables.

El framework .NET tiene una es­tru­c­tu­ra modular y emplea Common Language Runtime (CLR) como entorno de ejecución, lo que permite utilizar di­fe­re­n­tes lenguajes de pro­gra­ma­ción, siempre que cumplan con el estándar Common Language In­fra­s­tru­c­tu­re (CLI). Entre los lenguajes CLI de­sa­rro­lla­dos por Microsoft se incluyen, además de los clásicos C# y Visual Basic, orie­n­ta­dos a objetos, el lenguaje funcional más nuevo F#. Los lenguajes CLI se pueden ejecutar como código del lado del cliente en el navegador a través de Blazor y We­bA­s­se­m­bly.

Aunque, en un principio, ASP.NET se lanzó como software pro­pie­ta­rio ge­s­tio­na­do por Microsoft, hoy es un proyecto de código abierto au­s­pi­cia­do por la .NET Fou­n­da­tion. En el tra­n­s­cu­r­so de este proceso de apertura, se es­ta­ble­cie­ron el ad­mi­ni­s­tra­dor de paquetes NuGet y el re­po­si­to­rio público de paquetes co­rre­s­po­n­die­n­te. De manera co­m­pa­ra­ble a NPM o RubyGems, los de­sa­rro­lla­do­res de ASP.NET tienen a su di­s­po­si­ción un eco­si­s­te­ma de paquetes de uso libre.

La mayor ventaja de ASP.NET, es decir, utilizar el eco­si­s­te­ma es­pe­cí­fi­co de Microsoft, es también el mayor in­co­n­ve­nie­n­te de esta te­c­no­lo­gía, ya que, por lo general, el mundo del de­sa­rro­llo web se basa en gran medida en pla­ta­fo­r­mas, lenguajes y formatos gratuitos y abiertos. Asimismo, los de­sa­rro­lla­do­res que se in­tro­du­cen en el universo .NET por primera vez se en­cue­n­tran con una abru­ma­do­ra variedad de versiones y modelos de pro­gra­ma­ción para elegir.

En el pasado, quien quería trabajar con el framework ASP.NET solo podía hacerlo en Windows. Desde hace años, Microsoft ha buscado abrirse de manera co­n­ce­r­ta­da hacia es­tá­n­da­res am­plia­me­n­te uti­li­za­dos y de código abierto. Con la aparición de ASP.NET Core, el marco ahora es co­m­pa­ti­ble con las tres pri­n­ci­pa­les familias de sistemas ope­ra­ti­vos: Windows, macOS y Linux. También es posible mantener el entorno de de­sa­rro­llo en un co­n­te­ne­dor Docker.

El ASP.NET clásico solo se podía alojar en Internet In­fo­r­ma­tion Server (IIS), la te­c­no­lo­gía de servidor de Microsoft: una gran de­s­ve­n­ta­ja en co­m­pa­ra­ción con otros fra­me­wo­r­ks de de­sa­rro­llo web, los cuales también se ejecutan en Linux. El alo­ja­mie­n­to ASP.NET tiene re­qui­si­tos es­pe­cia­les y no está di­s­po­ni­ble para todos los pro­vee­do­res. Cabe decir que era posible utilizar otros se­r­vi­do­res web mediante Mono, que permite im­ple­me­n­tar .NET de forma gratuita. Sin embargo, el cambio real solo se produjo con la aparición de .NET Core y la Open Web Interface for .NET (OWIN). OWIN desacopla las apli­ca­cio­nes ASP.NET del servidor web su­b­ya­ce­n­te, eli­mi­na­n­do uno de los mayores ob­s­tácu­los del uso de este framework.

El framework ASP.NET es pa­r­ti­cu­lar en términos de entorno de alo­ja­mie­n­to. Otros fra­me­wo­r­ks de de­sa­rro­llo web basados en los lenguajes PHP, Java, Python o Ja­va­S­cri­pt se ejecutan en se­r­vi­do­res Linux. En cambio, para el hosting de apli­ca­cio­nes ASP.NET, antes se ne­ce­si­ta­ba Windows como sistema operativo de servidor. También se utilizaba el servidor web Internet In­fo­r­ma­tion Services (IIS) de Microsoft. Para alojar una apli­ca­ción ASP.NET en los se­r­vi­do­res de Windows, se tenía que utilizar Managed Windows Hosting. Con este modelo de alo­ja­mie­n­to, los se­r­vi­do­res son ma­n­te­ni­dos co­n­s­ta­n­te­me­n­te por el proveedor, que pro­po­r­cio­na ac­tua­li­za­cio­nes del software.

El hosting de las apli­ca­cio­nes ASP.NET Core es mucho más relajado. Además de en IIS, estas se pueden alojar en gran variedad de entornos de servidor. Para ello se utiliza el servidor web Kestrel integrado, que se ejecuta en Windows, Linux y macOS. Los se­r­vi­do­res web más populares, como Nginx y Apache, pueden co­n­fi­gu­rar­se como proxy inverso y uti­li­zar­se junto con Kestrel. La al­te­r­na­ti­va HTTP.sys de Kestrel también está di­s­po­ni­ble en Windows.