Seite 2: Neuschreiben statt Migrieren

Inhaltsverzeichnis

Die Unterschiede der verfügbaren Architekturmodelle bei ASP.NET und ASP.NET Core machen deutlich, dass nicht in allen Fällen eine Migration im engeren Sinne möglich ist, sondern in vielen Fällen ein Neuschreiben notwendig wird – zumindest der oberen Anwendungsschichten (Benutzerschnittstellenbeschreibung und Benutzerschnittstellensteuerung). Wie viel des alten Programmcodes sich dabei wiederverwenden lässt, hängt von der Güte der gewählten Softwarearchitektur ab. Je klarer Geschäftslogik und Datenzugriff von der Benutzerschnittstellensteuerung abgetrennt sind, desto einfacher lassen sich diese Schichten Geschäftslogik und Datenzugriff wiederverwenden.

Migration von MVC auf Core MVC

Als vergleichsweise einfache, aber auch recht aufwändige Migration lässt sich der Umstieg vom klassischen ASP.NET MVC auf ASP.NET Core MVC bezeichnen. In diesem Fall können Softwareentwickler zumindest die Razor View-Syntax fast unverändert beibehalten. Die im alten ASP.NET MVC noch erlaubte View Engine mit der klassischen, in den 1990er Jahren mit Active Server Pages eingeführten Platzhalter-Syntax (<% … %>) gibt es in ASP.NET Core allerdings nicht mehr. Wer sie noch verwendet, muss viel umstellen.

In jedem Fall sind Entwickler von der Änderung bei den Webserver-APIs betroffen: Es haben sich alle Klassen zur Interaktion mit dem Webserver geändert, insbesondere für den Zugriff auf die aktuelle URL, Browserinformationen, Cookies und andere Informationen aus HTTP-Anfrage und HTTP-Antwort sowie auch sonstige Klassen für die Zustandsverwaltung (beispielsweise Session-Variablen und Caching) und Konfigurationsdaten. Dies betrifft auch darauf aufbauende Funktionen wie URL-Rewriting, Benutzerverwaltung und Authentifizierung.

Im klassischen ASP.NET wurden diese Webserver-APIs von der Assembly System.Web (System.Web.dll) bereitgestellt, allen voran von dem eingebauten Objekt HttpContext.Current mit Unterobjekten wie Server, Request, Response und Session. Die Assembly System.Web ist aber in ASP.NET Core nur noch ganz rudimentär vorhanden (für URL-Encoding und -Decoding für Nicht-Webanwendungen). Microsoft hat die System.Web-Funktionalität in ASP.NET Core auf viele Assemblies in einzelnen NuGet-Paketen verteilt, darunter

• Hosting von Webanwendungen (Microsoft.AspNetCore.Hosting)
• Konfiguration (Microsoft.Extensions.Configuration, Microsoft.Extensions.Configuration.Json, Microsoft.Extensions.Configuration.Xml, Microsoft.Extensions.Configuration.Ini, Microsoft.Extensions.Configuration.EnvironmentVariables, Microsoft.Extensions.Configuration.CommandLine, Microsoft.Extensions.Configuration.AzureKeyVault)
• Fehlerbehandlung (Microsoft.AspNetCore.Diagnostics)
• Protokollierung (Microsoft.Extensions.Logging)
• Mehrsprachigkeit (Microsoft.AspNetCore.Localization und Microsoft.AspNetCore.Mvc.Localization)
• Cookies (Microsoft.AspNetCore.Http und System.Net.Primitives)
• Sitzungen (Microsoft.AspNetCore.Session)
• URL Rewriting (Microsoft.AspNetCore.Rewrite)
• Caching (Microsoft.Extensions.Caching, einschließlich der Integration mit Redis im Paket Microsoft.Extensions.Caching.Redis und SQL Server Microsoft.Extensions.Caching.SqlServer)
• Cross Origin Resource Sharing (CORS, Microsoft.AspNetCore.Cors)
• Benutzerverwaltung (Microsoft.AspNetCore.Identity)
• Authentifizierung (Microsoft.AspNetCore.Authentication)
• Zugriffskontrolle (Microsoft.AspNetCore.Authorization)

ASP.NET Core arbeitet zudem umfassend mit Dependency Injection (NuGet-Paket Microsoft.Extensions.DependencyInjection). Alle diese API-Änderungen bedeuten konkret, dass der Startcode einer Webanwendung und einiges von dem Programm in den Controllern, gegebenenfalls auch in in Views enthaltenen Programmcode, umgeschrieben werden muss. Das ist manuell zu erledigen.

Es existiert auch kein Werkzeug, das ein ASP.NET-MVC-Projekt automatisch in ein ASP.NET-Core-MVC-Projekt umbaut. Letztlich kommt man auch hier zu dem Vorgehensmodell, das in Teil 2 dieser Serie für WPF- und Windows Forms-basierte Desktopanwendungen ausführlich beschrieben wurde und welches man kurz zusammenfassen kann mit: Neues leeres Projekt anlegen, Dateien für Controller, Views und sonstige Klassen umkopieren und so lange umprogrammieren, bis es wieder läuft. Allerdings ist der bei ASP.NET MVC notwendige Änderungsaufwand bei weitem höher als bei WPF- und Windows-Forms-Anwendungen, denn bei letzteren beiden gibt es keine solch gravierenden API-Änderungen.

Zusätzlich schlagen in Webprojekten noch die Änderungen in den .NET-Basisklassen durch, welche auch bei WPF- und Windows-Forms-Migrationen erforderlich sind. In ASP.NET Core 1.0, 1.1, 2.0, 2.1 und 2.2 hatte ein .NET-Softwareentwickler noch die Option, ASP.NET Core wahlweise auf klassischem .NET Framework oder .NET Core zu betreiben. Mit dem Betrieb auf .NET Framework konnten Entwickler einigen Migrationsaufgaben im Bereich der Basisklassen entgehen beziehungsweise die Migration schrittweise durchführen. Seit ASP.NET Core 3.0 erlaubt Microsoft den Weg über das klassische .NET Framework leider nicht mehr, daher ist nun zwingend .NET Core als Basis zu verwenden. Heute noch auf eine Version vor ASP.NET Core 3.0 zu setzen, ist aber wenig sinnvoll, weil die Versionen 1.0, 1.1, 2.0 und 2.2 nicht mehr von Microsoft unterstützt werden. Für die Long-Term-Support-Version 2.1 endet der Support am 21.8.2021.

Eine Migration von ASP.NET Webpages auf ASP.NET Core Razor Pages ist mit ähnlich hohem Aufwand verbunden wie der Umstieg von ASP.NET MVC auf ASP.NET Core MVC, soll aber an dieser Stelle wegen der geringen Marktrelevanz von ASP.NET Webpages nicht weiter diskutiert werden.