Was ist ASP.NET?

Bei ASP.NET handelt es sich um ein aus­ge­reif­tes ser­ver­sei­ti­ges Web­ent­wick­lungs-Framework von Microsoft. Ent­wick­ler setzen ASP.NET ein, um dy­na­mi­sche Websites, Webapps und web­ba­sier­te Services zu rea­li­sie­ren. Nach jahr­zehn­te­lan­ger Ent­wick­lung besteht das Framework heut­zu­ta­ge als ASP.NET Core fort.

Ur­sprüng­lich von Microsoft ent­wi­ckelt, un­ter­steht ASP.NET heute der .NET-Foun­da­ti­on. Während die ersten Versionen noch als pro­prie­tä­re Software ver­öf­fent­licht wurden, handelt es sich beim modernen ASP.NET um ein Open-Source-Projekt.

Das heut­zu­ta­ge zum Einsatz kommende ASP.NET ist das Ergebnis eines jahr­zehn­te­lan­gen Ent­wick­lungs­pro­zes­ses. Dabei verlief der Werdegang von ASP über ASP.NET zu ASP.NET Core. Im Einklang mit dem Fort­schritt der Web­tech­no­lo­gie vollzog sich über die Jahre eine dras­ti­sche Ver­än­de­rung des Frame­works. Schauen wir uns zunächst die Ent­wick­lungs­ge­schich­te von ASP.NET an:

Bei den ur­sprüng­li­chen „Active Server Pages“ (ASP) handelte es sich um die erste von Microsoft ver­öf­fent­lich­te ser­ver­sei­ti­ge Skript­spra­che. Die Active Server Pages erlaubten ab dem Jahr 1996 die dy­na­mi­sche Erzeugung von Webseiten auf dem Server. Andere Skript­spra­chen setzen nor­ma­ler­wei­se auf Linux als Be­triebs­sys­tem und einen Open-Source-Webserver wie Apache. Dem­ge­gen­über po­si­tio­nier­te Microsoft die Active Server Pages als Teil des auf Windows laufenden „Internet In­for­ma­ti­on Server“ (IIS).

Die Grund­funk­tio­na­li­tät von ASP ist in etwa ver­gleich­bar mit PHP oder den „Java Server Pages“ (JSP). Bei allen drei Tech­no­lo­gien kommen Template-Dateien zum Einsatz. Die Template-Dateien enthalten aus­führ­ba­re Code-Schnipsel, die in statische HTML-Inhalte ein­ge­bet­tet sind. Der Code wird zwischen spezielle Tags ge­schrie­ben, um ihn vom um­ge­ben­den HTML ab­zu­gren­zen. Als Pro­gram­mier­spra­chen kamen die damals ver­füg­ba­ren, Microsoft-spe­zi­fi­schen Dialekte VBScript, JScript und Perl­Script zum Einsatz.

Beim Zugriff auf eine URL durch den Browser („Request“) wird der Code auf dem Server aus­ge­führt. Die Aus­füh­rung erzeugt HTML-Inhalte, die in die vor­de­fi­nier­ten HTML-Struk­tu­ren eingefügt werden. Das Ge­samt­ergeb­nis ist ein aus sta­ti­schen und dynamisch erzeugten HTML-Inhalten be­stehen­des Dokument; dieses wird als Antwort an den Browser aus­ge­lie­fert („Response“) und dem Nutzer angezeigt. Jede Änderung an Seiten-Inhalten, z. B. durch Be­nut­zer­ein­ga­ben, er­for­der­te einen kom­plet­ten Request-Response-Zyklus und damit ein Neuladen der Seite. Hier ein Beispiel für ASP-Code:

Bei ASP handelte es sich noch nicht um ein Framework. Vielmehr kam eine lose Sammlung einer Handvoll von Objekten zum Einsatz. Aus diesen strickte man sich eine dy­na­mi­sche Website zusammen:

• Ap­pli­ca­ti­on
• Request
• Response
• Server
• Session
• ASPError

Mit ASP.NET wurde um das Jahr 2003 der Nach­fol­ger des klas­si­schen ASP vor­ge­stellt. Anstatt einer losen Sammlung von Objekten kam das .NET Framework als Unterbau zum Einsatz. Dieses abs­tra­hier­te häufig benötigte Abläufe wie die Au­then­ti­fi­zie­rung und Au­to­ri­sie­rung von Benutzern und den Da­ten­bank­zu­griff. In seiner Ge­samt­heit ist ASP.NET in etwa ver­gleich­bar mit Java-Frame­works wie „Struts“ oder „Spring“.

Als aus­schlag­ge­ben­des Feature enthielt ASP.NET die „Web Forms“. Der Web-Forms-Ansatz erlaubte er­fah­re­nen Windows-Ent­wick­lern, dy­na­mi­sche Webseiten zu pro­gram­mie­ren. Dabei wurden die dem Web zugrunde liegenden Me­cha­nis­men vor den Ent­wick­lern verborgen; diese konnten weiterhin auf ihnen vertraute Workflows und Ent­wick­lungs­um­ge­bun­gen zu­rück­grei­fen. Ins­be­son­de­re kamen Microsoft-spe­zi­fi­sche visuelle Tools zur schnellen An­wen­dungs­ent­wick­lung („Rapid Ap­pli­ca­ti­on De­ve­lo­p­ment“, RAD) zum Einsatz.

Die Web Forms er­mög­lich­ten Windows-Ent­wick­lern einen schnellen Einstieg in die Web­pro­gram­mie­rung. Gleich­zei­tig begrenzte der Ansatz jedoch das Maß an Kontrolle über die aus­ge­lie­fer­ten HTML-Seiten. Mit ASP.NET MVC kam bald ein al­ter­na­ti­ves Ent­wick­lungs­mo­dell hinzu. Dieses folgte dem eta­blier­ten Muster „Model View Con­trol­ler“ (MVC) und erlaubte eine sauberere Trennung der Belange („Se­pa­ra­ti­on of concerns“). Angelehnt an das weg­wei­sen­de Framework „Ruby on Rails“ bot ASP.NET MVC Funk­tio­na­li­tät zum „Scaf­fol­ding“ (in etwa: Gerüstbau) eines Projekts.

In­zwi­schen wurde ASP.NET durch die Wei­ter­ent­wick­lung „ASP.NET Core“ ersetzt. Im Sprach­ge­brauch werden beide Namen aber häufig synonym verwendet.

Mit der Ver­öf­fent­li­chung von ASP.NET Core vollzog sich ein Wandel in der Or­ga­ni­sa­ti­on des Frame­works. Im Zuge der fort­schrei­ten­den Öffnung Mi­cro­softs wurde die Ent­wick­lung von ASP.NET Core unter die Schirm­herr­schaft der .NET Foun­da­ti­on gestellt. Der Quelltext des Projekts liegt unter einer Open-Source-Lizenz vor.

Auf tech­ni­scher Ebene handelt es sich bei ASP.NET Core um ein Re-Design von ASP.NET 4.0. Die organisch ge­wach­se­nen Kom­po­nen­ten von ASP.NET wurden zu­sam­men­ge­führt. Die Ent­wick­lung von ASP.NET-Core-Projekten und das Hosting außerhalb des Windows-Öko­sys­tems wurde er­mög­licht. Unter Windows setzt ASP.NET Core auf dem .NET Framework auf; auf anderen Be­triebs­sys­te­men kommt statt­des­sen das .NET Core Framework zum Tragen.

Im Einklang mit der fort­schrei­ten­den Ent­wick­lung der Web­tech­no­lo­gie ist ASP.NET Core bereit für die Cloud. Als ASP.NET-Hosting-Umgebung kommen neben Mi­cro­softs tra­di­tio­nel­lem Internet In­for­ma­ti­on Server (IIS) offene Server-Um­ge­bun­gen sowie Container zum Einsatz. Das Framework un­ter­stützt kli­en­ten­sei­ti­gen Code und moderne Ansätze der reaktiven Pro­gram­mie­rung. Damit zieht ASP.NET Core gleich mit Ja­va­Script-basierten Frame­works wie React.

Mit dem ASP.NET Framework lassen sich Web­pro­jek­te aller Couleur rea­li­sie­ren. Ins­be­son­de­re gehören dazu dy­na­mi­sche Websites und Web­an­wen­dun­gen, inklusive „Single Page Apps“ (SPA). Ferner lasen sich web­ba­sier­te Dienste wie APIs und Systeme für Echt­zeit­kom­mu­ni­ka­ti­on umsetzen. Für die ver­schie­de­nen Ein­satz­zwe­cke kamen im Laufe der Jahre ver­schie­de­ne Ansätze zum Tragen. Wir gehen im Folgenden auf diese ein und geben einen Überblick über die his­to­ri­sche Ent­wick­lung.

Mit dem Fort­schritt der Web­tech­no­lo­gien seit den 2000er Jahren wurden immer neue Ansätze zur Web­ent­wick­lung in ASP.NET in­te­griert. Sie können sich diese wie einen wohl­sor­tier­ten Werk­zeug­kas­ten vor­stel­len: Für ver­schie­den­ar­ti­ge Projekte stehen un­ter­schied­li­che Werkzeuge zur Verfügung. Je nach An­for­de­rung lassen sich mehrere Ansätze innerhalb eines Projekts kom­bi­nie­ren. Mit dem Er­schei­nen von ASP.NET Core wurden die zahl­rei­chen, organisch ge­wach­se­nen Pro­gram­mier­mo­del­le zu­sam­men­ge­führt. Dies führte zu einer Ver­ein­fa­chung bei der Wahl der ge­eig­ne­ten Ansätze.

Mit den klas­si­schen Web Forms werden Seiten aus vor­de­fi­nier­ten Kom­po­nen­ten zu­sam­men­ge­fügt. Dabei kommt ein visueller Formular-Baukasten zum Einsatz; einzelne Kom­po­nen­ten werden per Drag-and-Drop po­si­tio­niert. Besonders attraktiv war dies für Ent­wick­ler mit Erfahrung in der Windows-Pro­gram­mie­rung. Sie konnten die ihnen ver­trau­ten Werkzeuge für „Rapid Ap­pli­ca­ti­on De­ve­lo­p­ment“ („schnelle An­wen­dungs­ent­wick­lung“, RAD) nutzen. Mit dem Un­ter­schied, dass als End­pro­dukt keine Windows-Ap­pli­ka­ti­on, sondern eine dy­na­mi­sche Website erzeugt wurde.

Der Web-Forms-Ansatz beruht auf Mi­cro­softs Code-Behind-Modell. Dieses erzwingt eine Trennung der Belange:

• Template-Dateien mit der Endung .aspx de­fi­nie­ren die HTML-Struktur einer Seite und enthalten Platz­hal­ter für dynamisch erzeugte Inhalte.
• Die ei­gent­li­che An­wen­dungs-Logik wird in eine separate Datei mit der Endung .aspx.cs bzw. .aspx.vb aus­ge­la­gert. Hierbei handelt es sich um die na­mens­ge­ben­de Code-Behind-Datei.
• Der Client ruft die unter einer URL ver­füg­ba­re .aspx-Datei ab. Auf dem Server werden die sta­ti­schen und dy­na­mi­schen Be­stand­tei­le kom­bi­niert. Das daraus re­sul­tie­ren­de HTML-Dokument wird an den Client aus­ge­lie­fert.
• Bei Be­nut­zer­ein­ga­ben auf der Seite werden die Daten per GET- oder POST-Request an dieselbe URL über­tra­gen und von der Code-Behind-Datei ver­ar­bei­tet.

Für die Im­ple­men­tie­rung der An­wen­dungs-Logik kommt ein ob­jekt­ori­en­tier­ter Ansatz zum Tragen: Die Code-Behind-Datei definiert eine ab­ge­lei­te­te Klasse. Als Pro­gram­mier­spra­che kommt für ge­wöhn­lich C# oder Visual Basic zum Einsatz. In­ter­es­sant ist, dass die Code-Behind-Datei einmalig vor­kom­pi­liert wird. Dies führt zu einer schnel­le­ren Aus­füh­rung und höherer Ro­bust­heit gegenüber Fehlern während des Aufrufs der Seite.

Im Gegensatz zum ur­sprüng­li­chen ASP waren die Web Forms ein richtiger Schritt in Richtung Trennung der Belange. Bei ASP lagen sta­ti­sches HTML und Code-Be­stand­tei­le in ein und derselben Datei vermischt vor. Mit den Web Forms erfolgte die Trennung in Template- und Code-Behind-Datei. Mit ASP.NET MVC erhielt ASP.NET ein weiteres Pro­gram­mier­mo­dell, das die Web­ent­wick­lung nach dem Muster Model View Con­trol­ler (MVC) erlaubte.

Das MVC-Muster grenzt An­wen­dungs-Logik („Model“), Dar­stel­lungs-Template („View“) und Nut­zer­inter­ak­ti­on („Con­trol­ler“) von­ein­an­der ab. Zu den Vorteilen des MVC-Ansatzes zählt, dass sich die einzelnen Belange besser testen lassen. Ferner erlaubt die Trennung der Belange, ver­schie­de­ne Con­trol­ler zu nutzen. Anstatt sämtliche Be­nut­zer­ein­ga­ben an eine einzelne URL zu senden und dabei die Seite neu zu laden, kommt bei­spiels­wei­se AJAX via jQuery zum Einsatz. Dies erlaubt das Neuladen von Teilen der Seite. Mit ASP.NET Core MVC setzt sich die Tradition von ASP.NET MVC bis in die heutige Version des Frame­works fort.

Die ASP.NET Web Forms und ASP.NET MVC sind gut geeignet, um komplexe Websites zu rea­li­sie­ren. Benötigt man mehrere Seiten mit wie­der­ver­wend­ba­ren Kom­po­nen­ten, bieten sich beide Pro­gram­mier­mo­del­le an. Was jedoch, wenn man dies nicht benötigt? Nehmen wir an, wir möchten eine simple Website bauen, die nur aus einer einzigen Seite oder einer Handvoll Seiten besteht. Es gibt ein paar dy­na­mi­sche Be­stand­tei­le, aber der Fokus liegt eher auf einem aus­ge­feil­ten Layout als komplexer An­wen­dungs-Logik und der Ver­ar­bei­tung von Nut­zer­ein­ga­ben. Dann wäre es Overkill, eigene Klassen zu de­fi­nie­ren oder eine Auf­spal­tung nach dem MVC-Muster an­zu­stre­ben.

Für Fälle, in denen weniger die An­wen­dungs-Logik im Vor­der­grund steht als aus­ge­feil­tes Layout und Design, bieten sich die ASP.NET Web Pages an. Ähnlich dem klas­si­schen ASP oder PHP findet innerhalb einer Datei eine Kom­bi­na­ti­on aus sta­ti­schen HTML-Struk­tu­ren und dy­na­mi­schen Code-Be­stand­tei­len statt. Dabei kommt eine spezielle Syntax zum Einsatz. Besonders gut eignen sich ASP.NET Web Pages für die Er­stel­lung von Landing­pa­ges.

Die bisher vor­ge­stell­ten Pro­gram­mier­mo­del­le haben allesamt zum Ziel, für den mensch­li­chen Nutzer bestimmte HTML-Inhalte zu erzeugen. Darüber hinaus enthält das ASP.NET Framework jedoch auch Modelle, die dazu dienen, In­fra­struk­tur für Web­pro­jek­te be­reit­zu­stel­len. Bei ASP.NET Web API handelt es sich um ein Pro­gram­mier­mo­dell zur Er­stel­lung von REST-APIs. Zugriffe auf die Endpoints der API finden über AJAX statt. Dabei kommt JSON oder XML als Format für Da­ten­über­tra­gung zum Einsatz.

Bei ASP.NET WebHooks handelt es sich um eine Im­ple­men­tie­rung des WebHooks-Musters. WebHooks erlauben das Ver­öf­fent­li­chen und Abon­nie­ren von Er­eig­nis­sen, die in einem System statt­fin­den. Dabei kann es sich z. B. um das Hin­zu­fü­gen einer Datei oder den Empfang einer Zahlung handeln. Ein Abonnent re­gis­triert die zu ver­fol­gen­de Änderung beim ver­öf­fent­li­chen­den System. Dazu übergibt er eine URL – den na­mens­ge­ben­den WebHook. Tritt das re­gis­trier­te Ereignis auf, ruft das ver­öf­fent­li­chen­de System den WebHook auf; der Abonnent wird über das Ereignis in­for­miert.

Bei SignalR handelt es sich um ein Framework zur Echtzeit-Kom­mu­ni­ka­ti­on zwischen Client und Server. Das Framework baut auf dem Web­So­ckets-Standard auf und erlaubt den bi­di­rek­tio­na­len Transfer von Daten. Browser, die Web­So­ckets nicht be­herr­schen, werden über Fallback-Me­cha­nis­men un­ter­stützt. SignalR kommt häufig zum Einsatz, um brow­ser­ba­sier­te Chat-Dienste und Vi­deo­kon­fe­renz-Software zu rea­li­sie­ren.

Bei ASP.NET Core handelt es sich um den Nach­fol­ger von ASP.NET. Das ASP.NET Core Framework wurde neu ge­schrie­ben, weist jedoch eine hohe Kom­pa­ti­bi­li­tät zum Vorgänger auf. Vormals separate Be­stand­tei­le von ASP.NET wurden in der Core-Version zu­sam­men­ge­führt. Ferner wurden manche Kom­po­nen­ten neu ent­wi­ckelt und behielten ihren be­stehen­den Namen bei. So existiert das SignalR Framework sowohl in einer ASP.NET- als auch ASP.NET-Core-Version. Schauen wir uns die wich­tigs­ten Neu­ent­wick­lun­gen von ASP.NET Core an.

Mit ASP.NET Core MVC wurden Funk­tio­na­li­tä­ten von ASP.NET MVC und ASP.NET Web API vereint. So lassen sich hoch­dy­na­mi­sche Web­an­wen­dun­gen mit modularer Be­nut­zer­ober­flä­che und da­hin­ter­lie­gen­der API ent­wi­ckeln. Dabei kommt als ge­mein­sa­mer Unterbau das .NET Core Framework zum Tragen. Vertraute Ansätze aus der .NET-API-Ent­wick­lung lassen sich auf die MVC-Ent­wick­lung über­tra­gen und vice versa.

Die Razor Pages füllen eine ähnliche Nische wie vormals die ASP.NET Web Pages. Der Einsatz bietet sich dann an, wenn das Model-View-Con­trol­ler Muster unnötigen Overhead dar­stel­len würde. Möchte man z. B. eine Landing­pa­ge bauen, lässt sich diese als Razor Page mit geringem Aufwand im­ple­men­tie­ren. Zum Erstellen des Seiten-Templates kommt die Razor-Syntax zum Einsatz. Als Pro­gram­mier­spra­chen lassen sich, wie im .NET-Universum üblich, C# und Visual Basic nutzen.

Schauen wir uns eine bei­spiel­haf­te Razor Page an. Auffällig ist, dass anstelle der ansonsten in Template-Sprachen üblichen öffnenden und schlie­ßen­den Code-Tags ein öffnendes @-Zeichen zum Einsatz kommt:

Das Blazor Framework setzt auf die bereits erwähnte Razor-Syntax; in der Tat steht Blazor für „Browser + Razor“. Wie der Name andeutet, liegt der Fokus von Blazor auf dem Browser als Lauf­zeit­um­ge­bung. Bei den Razor Pages findet die Ver­ar­bei­tung der Nutzer-In­ter­ak­ti­on auf dem Server statt. Blazor hingegen er­mög­licht die reaktive Pro­gram­mie­rung, bei der einzelne Sei­ten­kom­po­nen­ten im Browser dynamisch auf Än­de­run­gen reagieren. Damit ist Blazor in etwa ver­gleich­bar mit den Tech­no­lo­gien React, Angular und Vue.

Hier ein simples Beispiel für reaktive Pro­gram­mie­rung mit Blazor. Wir binden den Wert eines Ein­ga­be­felds an die Variable Name. Dabei kommt die Razor-Syntax zum Einsatz:

Neben der reaktiven Pro­gram­mie­rung ist ein weiteres Merkmal von Blazor hoch­in­ter­es­sant: Per We­b­As­sem­bly lassen sich die die .NET-Sprachen für die Aus­füh­rung im Browser kom­pi­lie­ren. Blazor wird daher manchmal auch als Ansatz für „.NET in the browser“ be­zeich­net. Der Vorteil liegt darin, kein Ja­va­Script für den kli­en­ten­sei­ti­gen Code schreiben zu müssen. Statt­des­sen erfolgt die Ent­wick­lung in C# oder Visual Basic; der Code kann auf die ver­trau­ten Kom­po­nen­ten des .NET Frame­works zugreifen.

Mit ASP.NET bzw. ASP.NET Core steht eine aus­ge­reif­te Umgebung für die Ent­wick­lung un­ter­schied­lichs­ter Web­pro­jek­te zur Verfügung. Zum Umfang gehören Pro­gram­mier­spra­chen, Code-Editoren und IDEs sowie Ent­wick­lungs­tools und ein flo­rie­ren­des Ökosystem frei ver­füg­ba­rer Pakete. Heut­zu­ta­ge kommen dabei moderne Methoden wie reaktive Pro­gram­mie­rung, Web­So­ckets und We­b­As­sem­bly zum Einsatz. Der größte Nachteil bei der Nutzung von ASP.NET war tra­di­tio­nell die enge Bindung an Microsoft und der damit ein­her­ge­hen­de Vendor Lock-in. Mit der fort­schrei­ten­den Öffnung hin zu Open Source ist dies mitt­ler­wei­le weniger be­denk­lich.

Den größten Vorteil bei der Nutzung von ASP.NET ziehen Ent­wick­ler, die mit der Pro­gram­mie­rung im Microsoft-Ökosystem vertraut sind. Diese greifen kom­for­ta­bel auf die ihnen bekannten Sprachen, Tools und Workflows zurück. Als Unterbau von ASP.NET kommt das aus­ge­reif­te .NET Framework zum Einsatz. Damit stehen passende Kom­po­nen­ten für eine große Vielzahl von An­wen­dungs­fäl­len bereit. Ein großer Vorteil, wenn es darum geht, komplexe An­wen­dun­gen schnell und er­geb­nis­si­cher um­zu­set­zen.

Das .NET Framework ist modular aufgebaut und enthält die „Common Language Runtime“ (CLR) als Lauf­zeit­um­ge­bung. Diese erlaubt die Nutzung ver­schie­de­ner Pro­gram­mier­spra­chen, solange diese dem „Common Language In­fra­struc­tu­re“ (CLI) Standard ent­spre­chen. Zu den von Microsoft ent­wi­ckel­ten CLI-Sprachen gehört neben den ob­jekt­ori­en­tier­ten Klas­si­kern C# und Visual Basic die neuere funk­tio­na­le Sprache F#. Per Blazor und We­b­As­sem­bly lassen sich die CLI-Sprachen als kli­en­ten­sei­ti­ger Code im Browser ausführen.

Ur­sprüng­lich begann ASP.NET als pro­prie­tä­re Software unter der Kontrolle von Microsoft. Heut­zu­ta­ge handelt es sich um ein Open-Source-Projekt unter Schirm­herr­schaft der .NET Foun­da­ti­on. Im Zuge dieser Öffnung wurden der NuGet Pa­ket­ma­na­ger und das da­zu­ge­hö­ri­ge öf­fent­li­che Paket-Re­po­si­to­ry etabliert. Ver­gleich­bar mit NPM oder RubyGems steht ASP.NET-Ent­wick­lern damit ein Ökosystem frei nutzbarer Pakete zu Verfügung.

Der größte Vorteil von ASP.NET – die Nutzung des Microsoft-spe­zi­fi­sches Öko­sys­tems – ist gleich­zei­tig auch der größte Nachteil der Tech­no­lo­gie. Denn die Web­ent­wick­lung baut ansonsten größ­ten­teils auf freien und offenen Platt­for­men, Sprachen und Formaten auf. Ent­wick­lern, die das erste Mal in das .NET-Universum ein­tau­chen, bietet sich eine ver­wir­ren­de Vielfalt an Versionen und Pro­gram­mier­mo­del­len.

Wer mit dem ASP.NET Framework ent­wi­ckeln wollte, konnte dies tra­di­tio­nell nur unter Windows tun. Seit Jahren betreibt Microsoft eine kon­zer­tier­te Öffnung hin zu breit ein­ge­setz­ten Standards und Open Source. Mit dem Er­schei­nen von ASP.NET Core klappt die Ent­wick­lung nun auch auf den drei großen Be­triebs­sys­tem-Familien Windows, macOS und Linux. Ferner ist es somit möglich, die Ent­wick­lungs­um­ge­bung in einem Docker-Container vor­zu­hal­ten.

Klas­si­sches ASP.NET ließ sich nur auf Mi­cro­softs haus­ei­ge­ner Ser­ver­tech­no­lo­gie Internet In­for­ma­ti­on Server (IIS) hosten. Ein großer Nachteil gegenüber anderen Web­frame­works, die allesamt auch auf Linux laufen. ASP.NET-Hosting bedingt spezielle An­for­de­run­gen und ist nicht bei allen Providern verfügbar. Zwar war es möglich, mit „Mono“ als freier .NET-Im­ple­men­tie­rung andere Webserver ein­zu­set­zen. Der echte Wandel stellte sich jedoch erst mit dem Er­schei­nen von .NET Core und dem „Open Web Interface for .NET“ (OWIN) ein. OWIN ent­kop­pelt eine ASP.NET-Anwendung vom dar­un­ter­lie­gen­den Webserver. Damit ist eine der größten Hürden beim Einsatz von ASP.NET gefallen.

Das ASP.NET Framework ist speziell in Bezug auf die Hosting-Umgebung. Sonstige Web­frame­works auf Basis der Sprachen PHP, Java, Python oder Ja­va­Script laufen allesamt auf Linux-Servern. Nur zum Hosting von ASP.NET-An­wen­dun­gen war tra­di­tio­nell Windows als Server-Be­triebs­sys­tem er­for­der­lich. Ferner kam zwingend Mi­cro­softs Webserver Internet In­for­ma­ti­on Services (IIS) zum Einsatz. Zum Hosten einer ASP.NET-Anwendung auf Windows-Servern sollte Managed Windows Hosting gewählt werden. Bei diesem Hosting-Modell werden die Server ständig vom Anbieter gewartet und mit Software-Updates versorgt.

Weitaus ent­spann­ter ist es um das Hosting von ASP.NET-Core-An­wen­dun­gen bestellt. Diese lassen sich neben IIS auf einer Vielzahl von Ser­ver­um­ge­bun­gen hosten. Dabei kommt der in­te­grier­te Kestrel-Webserver zum Einsatz, der auf Windows, Linux und macOS läuft. Beliebte Webserver wie Nginx und Apache lassen sich als Reverse Proxy kon­fi­gu­riert zusammen mit Kestrel einsetzen. Unter Windows steht ferner die Kestrel-Al­ter­na­ti­ve HTTP.sys zur Verfügung.