RUBICON IT GmbH

Etablierte Firma

Retargeting einer Anwendung mit ASP.NET Web Forms auf .NET 8

Michael Ketting von RUBICON IT zeigt in seinem devjobs.at TechTalk wie man eine saubere Migration von Web Forms auf .NET 8 durchführt und welche Vorteile dies für ein Dev Team mit sich bringt.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In „Retargeting einer Anwendung mit ASP.NET Web Forms auf .NET 8“ zeigt Michael Ketting, wie sich bestehende Web‑Forms‑Anwendungen mit Core Forms auf .NET 8 betreiben lassen, statt sie in einem riskanten Big‑Bang neu zu schreiben. Anhand der WingtipToys‑Demo demonstriert er die konkreten Schritte (Dependencies aktualisieren, ASP.NET‑Core‑Host anlegen, Core‑Forms‑Pakete einbinden, Program.cs initialisieren, ASPX/ASMX/Master/UserControls mappen, Web.config für targetFramework, Tag‑Prefixe und Session‑State anpassen) sowie geteilte Session/Authentication und die Weiterverwendung von Drittanbieter‑Controls via .NET Framework Bridge (z. B. Telerik). Ergebnis ist ein pragmatischer Migrationspfad: erst Retargeting auf .NET 8, dann schrittweise Modernisierung einzelner Masken im Rahmen von Change Requests.

Von ASP.NET Web Forms zu .NET 8: Der pragmatische Migrationspfad mit Core Forms

Warum dieses Thema jetzt zählt

Wer heute noch eine produktive ASP.NET Web Forms-Anwendung betreibt, kennt das Dilemma: .NET Framework ist stabil, erhält aber primär Security-Updates, während die „interessante Anwendungsentwicklung“ auf .NET weiterzieht. Gleichzeitig sind viele Business-Anwendungen historisch gewachsen, tief mit der Web-Forms-Infrastruktur verwoben und über Jahre, oft Jahrzehnte, von Teams erweitert und gefixt worden. Ein Big-Bang-Neuschreiben? Teuer, riskant, in laufenden Projekten schwer verkaufbar – und häufig der Startschuss für die nächste Ausschreibung.

Genau hier setzt die Session „Retargeting einer Anwendung mit ASP.NET Web Forms auf .NET 8“ von Michael Ketting (RUBICON IT GmbH) an. Wir haben zugehört und den Ansatz verstanden: statt Web Forms neu zu erfinden, wird die bestehende Anwendung mit einem gezielten Retargeting auf .NET 8 gehoben – und anschließend Schritt für Schritt modernisiert, wo es fachlich und wirtschaftlich Sinn ergibt.

„Geht nicht! Machen wir nicht!“ – so die klare Ansage rund um Web Forms auf .NET seitens Microsoft. RUBICON hat sich gefragt: Warum eigentlich nicht?

Die Antwort ist Core Forms: eine Web-Forms-Implementierung für .NET (zuerst .NET 6, mittlerweile .NET 8), die in realen Projekten läuft und das zentrale Problem – die starke Verzahnung von Web-Forms-Code und Laufzeit – pragmatisch adressiert. Unser Fazit nach der Session: Wer sein Team mit modernen .NET-Technologien arbeiten lassen will, ohne Jahre in ein Rewrite zu investieren, bekommt hier einen gangbaren Pfad.

Die Ausgangslage: Alt trifft Neu

Michael Ketting stellt zunächst die langfristige Entwicklung in den Kontext:

Web Forms war Anfang der 2000er ein massiver Produktivitätsschub. Viele Fachanwendungen entstanden auf dieser Plattform.
Microsoft verlagert Neuentwicklung auf .NET. Web Forms bleibt an .NET Framework gebunden.
Web-Forms-Anwendungen sind architekturbedingt stark mit der Infrastruktur verwoben: Event-Handler, Code-Behind, wenig Trennung wie in modernen MVC-Ansätzen.
Große, gewachsene Codebasen mit unzähligen Änderungsanlässen über Jahre – Spezifikationen, Tickets, E-Mails, Bugfixes – machen ein Big-Bang-Neuschreiben wirtschaftlich riskant.

Im Talk zitiert Ketting eine Konferenz-Statistik von André Puré von „Sonocube“: In aktiven Projekten wird über fünf Jahre hinweg etwa die Hälfte der Codebasis angefasst. Übersetzt für die Migrationsstrategie heißt das: Wenn ohnehin fortlaufend Features und Bugfixes passieren, warum nicht genau diese Change Requests als Hebel nutzen, um Teile der Anwendung gezielt zu modernisieren?

Die Idee: Retargeting zuerst, Modernisierung danach

Die Migrationsstrategie, die wir aus der Session mitnehmen, ist bewusst zweistufig:

Zuerst die bestehende Web-Forms-Anwendung auf .NET 8 betreiben – ohne Funktionsänderungen. Das reduziert Infrastruktur- und Betriebsschulden, bringt moderne Toolchains und macht die Anwendung anschlussfähig für neue .NET-Features.
Danach über die Zeit – im Zuge echter Change Requests – Masken, Controls und Logikschichten gezielt modernisieren. Das passiert dort, wo der Business-Value liegt (z. B. Warenkorb, komplexe Prozesse), nicht zwangsläufig in Stammdatenmasken.

Das Zielbild ist ausdrücklich nicht „Web Forms auf ewig“, sondern ein sauberer Migrationspfad, bei dem Core Forms als Brücke dient. Am Ende steht eine modernisierte Anwendung, die ohne Core Forms auskommt – nur eben ohne jahrelangen Stillstand bis zum großen Wurf.

Core Forms in Kürze: Was es ist – und was nicht

Core Forms ist eine Web-Forms-Implementierung für .NET 8, entwickelt von RUBICON IT GmbH. Ein paar Eckpunkte aus dem Vortrag:

Produktstatus: produktiv im Einsatz; RUBICON hat Eigeninteresse an aktiver Wartung.
Plattform: aktuell Windows-fokussiert (analog zur historischen Web-Forms-Welt). Linux ist möglich, wenn ein klarer Business-Need besteht; im Vortrag liegt der Fokus auf Windows.
Sprache: Web-Forms-Seiten in C# sind der Standard in den gezeigten Demos. Visual Basic wäre prinzipiell möglich, wenn der entsprechende Compiler eingebunden wird.
Artefakte: ASPX-Seiten, Master Pages, User Controls sowie klassische ASMX-Webservices werden unterstützt.
Drittanbieter: über eine „.NET Framework Bridge“ können Third-Party-Control-Libraries (z. B. Telerik) unverändert weiterverwendet werden.
Lizenzierung: kommerzielles Produkt mit Trial License; die Initialisierung sieht man in der Startup-Logik.

Kurz: Es fühlt sich an wie Web Forms – nur läuft es auf .NET 8 und integriert sich in eine ASP.NET-Core-Anwendung.

Die Demo: Wingtip Toys auf .NET 8 starten

Um die tatsächliche Umsetzbarkeit zu zeigen, demonstriert Ketting das Vorgehen mit „Wingtip Toys“, einer bekannten Microsoft-Demo-Anwendung aus den 2010er-Jahren. Der Ablauf besteht aus wenigen, klaren Schritten und zeigt, wie wenig Code man anfassen muss, um die Anwendung auf .NET 8 zu heben.

1) Abhängigkeiten aktualisieren

Der erste Schritt ist ein genereller Hygieneschritt: NuGet-Pakete und JavaScript-Bibliotheken aktualisieren. Viele Altprojekte haben hier Jahre an Rückstand; bekannte Security-Issues lassen sich so gleich mit beseitigen. Wichtig: Nach wie vor läuft die Anwendung an diesem Punkt auf .NET Framework 4.8 – Core Forms ist noch nicht im Spiel.

2) ASP.NET-Core-Anwendung anlegen

Als Nächstes wird eine leere ASP.NET-Core-Webanwendung über das Standard-Template von Microsoft erstellt. Das bringt die üblichen Basiskomponenten mit (Error Page, Index Page, Settings). Dieser Schritt schafft das Hosting-Fundament für den späteren Core-Forms-Teil.

3) Code kopieren: Wingtip Toys in das neue Projekt übernehmen

Die gesamte Codebasis von Wingtip Toys wird per Copy & Paste in das neue Projekt gelegt. Ketting macht das bewusst side-by-side, um Alt und Neu parallel zeigen zu können. Technisch wäre auch eine direkte Übernahme möglich, aber für die Demo ist die Trennung übersichtlicher.

4) Projektdatei und Konfiguration anpassen

Jetzt kommen die gezielten Anpassungen, die das Retargeting greifbar machen:

Paket-Referenzen aus dem alten packages.config werden in die neue Projektdatei übernommen – ergänzt um die Core-Forms-Pakete.
Da Full-Framework-Assemblies referenziert werden, wird eine entsprechende NuGet-Warnung deaktiviert.
Output-Pfade und Verzeichnisse werden angepasst (angelehnt an ASP.NET-Core-Defaults, jedoch für den konkreten Einsatz justiert).
Neben der web.config liegt eine app.config, wie in der Demo gezeigt.
In der web.config werden u. a. das Target Framework angehoben, Tag-Prefixes registriert und das Session-State-Modul für Core Forms eingehängt. Auch zusätzliche Assembly-Referenzen werden gesetzt, die früher vom Designer automatisch kamen.

5) Startup-Logik in Program.cs

Die Program.cs der ASP.NET-Core-Anwendung bleibt vertraut, bekommt aber einige wichtige Ergänzungen:

Lizenzinitialisierung (Trial oder produktiv) – Core Forms ist ein kommerzielles Produkt.
Eine Initialize-Methode wird früh ausgeführt. Hintergrund: Web-Forms-Code nutzt vielfach statische Strukturen; eine frühzeitige Initialisierung verhindert, dass etwas „nebenbei“ vor der korrekten Konfiguration benutzt wird.
Core Forms wird als Service eingebunden, und die ASPX-Dateien werden registriert. Ketting betont explizit, dass dies analog zu Razor-Routing wirkt – inklusive Unterstützung für Master Pages, User Controls und ASMX.

Mit diesen Anpassungen startet Wingtip Toys auf .NET 8 – im Debugger sichtbar auf .NET Core 8 –, kompiliert die ASPX-Seiten beim ersten Aufruf und läuft. In der Demo wirkt der Start sogar spürbar schneller.

„Und dann konnten wir es starten.“ – Der entscheidende Moment nach wenigen, gezielten Projektänderungen.

Produktivitätsfeatures für den Übergang: Session- und Auth-Integration

Die Brücke zwischen Alt und Neu steht mit dem Retargeting. Im zweiten Teil der Session zeigt Ketting, wie man beides produktiv verknüpft – in Form von Shared Session und wählbaren Authentifizierungsmodellen. Ziel: Modernisierung, ohne die Legacy-Teile zu isolieren.

Gemeinsame Session zwischen Core Forms und ASP.NET Core

Core Forms implementiert zunächst das Standard-Sessionverhalten von ASP.NET Web Forms. Zusätzlich stellt es eine In-Memory-Object-Session als Service bereit, die in die Pipeline integriert werden kann. Dadurch lassen sich Session-Daten zwischen Core-Forms-Seiten (ASPX) und modernen ASP.NET-Core-Teilen (z. B. Razor Pages) teilen – im selben Prozess.

Ketting demonstriert das anhand eines simplen Counters, der in beiden Welten inkrementiert werden kann. Ruft man abwechselnd eine Razor Page und eine ASPX-Seite auf, sieht man, wie der Counter von 1 auf 2 auf 3 usw. weiterläuft. Die Botschaft ist klar: Man kann bestehende Sitzungen und Statusinformationen nahtlos gemeinsam nutzen – ohne Umwege, ohne Sonderlocken.

Aus Modernisierungssicht ist das wertvoll, weil man fachliche Übergänge bauen kann, ohne Benutzersitzungen zu fragmentieren. Schreiben in die Session ist möglich, Ketting rät aber im Geiste der Modernisierung, die Session-Nutzung eher zurückzufahren.

Authentifizierung: getrennt, geteilt oder read-only geteilt

Für Authentifizierung skizziert der Vortrag drei Konfigurationsvarianten:

Standardfall: getrennte Authentifizierung – einmal in ASP.NET Core, einmal in Core Forms. Das ist die sichere Standardeinstellung, um unbeabsichtigte Seiteneffekte zu vermeiden.
Shared Authentication: beide Welten können die Authentifizierung initialisieren und nutzen. So kann man – je nach Projektstand – an beiden Enden andocken.
Shared Read-Only: der Principal wird in ASP.NET Core erzeugt und in Core Forms nur lesend verwendet. Das eignet sich, wenn man die Authentifizierung vollständig auf die moderne Plattform verlagern möchte, um dort neue Services und Integrationen zu nutzen. Core Forms konsumiert dann lediglich den vorhandenen Principal.

Der praktische Gewinn: Teams können Auth Schritt für Schritt nach ASP.NET Core ziehen – mit all den Integrationen, die Microsoft und Dritte heute anbieten – und den bestehenden Web-Forms-Teil weiterhin betreiben, ohne Auth dort doppelt zu pflegen.

Drittanbieter-Controls: „Es funktioniert einfach“ – dank .NET Framework Bridge

Viele Web-Forms-Anwendungen basieren auf mächtigen Control-Suites wie Telerik oder DevExpress. Die Frage „Und was ist mit unseren Controls?“ ist daher ein Klassiker. Kettings Antwort: Es geht. Dafür existiert die „.NET Framework Bridge“ als NuGet-Package, die die nötige Kompatibilität herstellt.

In der Demo kopiert er Beispiele direkt von der Telerik-Demoseite in eine Core-Forms-Anwendung und zeigt vertraute Interaktionen:

Ein DataGrid, in dem Sortierung erwartungsgemäß funktioniert.
Ein Tree, in dem Drag-and-drop einfach läuft.

„Das ist natürlich das Problem bei solchen Demos: Wenn es einfach funktioniert, dann sind die Demos langweilig.“

Gerade diese „Langeweile“ ist hier das Feature: Die Controls funktionieren unverändert, was Migrationsrisiken drastisch reduziert.

Betriebsaspekte: Windows-first, Linux bei Bedarf

Core Forms läuft laut Vortrag aktuell auf Windows – konsistent mit der Historie von Web Forms. Ketting betont aber, dass Linux möglich wäre, wenn ein konkreter Business-Need entsteht. Praktisch bedeutet das: Wer zügig migrieren will, kann das auf der gewohnten Windows-Infrastruktur tun; wer später OS-Strategien ändern möchte, kann das Thema gesondert planen.

Architekturgedanke: Brücke statt Tunnel

Aus Sicht der Softwarearchitektur hat uns besonders die Staffelung überzeugt: Retargeting als Infrastrukturmaßnahme jetzt, Modernisierung als Feature-Arbeit über die nächsten Jahre. Drei Gründe, warum dieser Ansatz für Enterprise-Teams attraktiv ist:

Er minimiert Vorabinvestitionen. Statt Millionenbudget für ein Wagnis bindet man Aufwand an ohnehin geplante Changes.
Er hält Entwickler motiviert. Teams können sofort mit .NET 8, C# 11/12 und modernen Bibliotheken arbeiten – statt mit .NET Framework und C# 6.
Er reduziert Projektrisiko. Fachlich kritische Teile werden dort modernisiert, wo sie zählen – etwa im Warenkorb – nicht dort, wo wenig Business Value schlummert.

Die im Vortrag zitierte Beobachtung von „Sonocube“ – dass in aktiven Projekten über die Jahre große Teile der Codebasis ohnehin verändert werden – stützt den Ansatz empirisch: Nach fünf Jahren hat man eine beachtliche Menge kritischer Pfade ohnehin angefasst und damit gute Ankerpunkte für gezielte Modernisierung genutzt.

Schritt-für-Schritt: Was wir konkret mitnehmen

Wer eine Web-Forms-Anwendung betreibt und die Brücke zu .NET 8 schlagen will, kann sich entlang der folgenden Leitplanken bewegen – genau so, wie sie in der Session demonstriert wurden:

Altprojekt aufräumen: Dependencies (NuGet, JS) aktualisieren, ohne Verhalten zu ändern.
Leere ASP.NET-Core-Anwendung erstellen: Standard-Template genügt.
Code übernehmen: Web-Forms-Code in das neue Projekt kopieren (für Demos side-by-side, in Projekten je nach Bedarf integrieren).
Projektdatei anpassen: Paket-Referenzen migrieren, Core-Forms-Pakete hinzufügen, Warnungen und Output-Pfade justieren, app.config ergänzen.
web.config aktualisieren: Target Framework anheben, Tag-Prefixes registrieren, benötigte Assemblies referenzieren, Session-State-Modul für Core Forms aktivieren.
Startup-Logik ergänzen: Lizenz initialisieren, eine frühe Initialize-Methode vorsehen, Core Forms als Service einhängen, ASPX/ASMX/Master/User Controls registrieren.
Anwendung starten: .NET 8 im Debugger prüfen, erste Kompilation der ASPX-Seiten abwarten – die App läuft.
Session teilen (optional): In-Memory-Object-Session registrieren und Use-Object-Session aktivieren; so können Razor Pages und ASPX-Seiten denselben Zustand lesen/schreiben.
Auth-Strategie wählen: getrennt, shared oder shared read-only – je nach Modernisierungsziel und bestehender Infrastruktur.
Drittanbieter-Controls weiterverwenden: .NET Framework Bridge als NuGet-Package einhängen; Controls wie Telerik funktionieren unverändert.

Realismus statt Dogma: Warum der Ansatz in Enterprise-Kontexten überzeugt

Ketting skizziert nüchtern, warum Big-Bang-Migrationen häufig an Business-Realitäten scheitern: Kunden zweifeln an ROI und Laufzeit, Ausschreibungszyklen bringen Unsicherheit, und auch die Erfolgsquote von Ablöseprojekten ist nicht makellos. Die Alternative, Core Forms als Brücke, liefert dagegen sofortige Effekte:

Betrieb auf .NET 8: moderne Runtime, Ökosystem, Tooling.
Wandel ohne Unterbrechung: Fachliche Weiterentwicklung geht weiter – und wird zur Modernisierung genutzt.
Entwicklerzufriedenheit: Statt auf .NET Framework „eingesperrt“ zu sein, können Teams moderne Sprachfeatures und Bibliotheken nutzen (Ketting nennt C# 11/12 und eine „Frozen Collection“ als Beispiel für zeitgemäße Libraries).

Dass Core Forms produktiv eingesetzt wird und RUBICON als Hersteller Eigeninteresse an nachhaltiger Wartung hat, erhöht die Planungssicherheit.

Quellen, Demos und Einstieg

Ketting verweist im Talk auf die zentralen Einstiegspunkte:

Website: coreforms.net (kompakte Infos)
Pakete: auf NuGet verfügbar
Dokumentation: GitHub-Wiki „coreforms.docs“ – inklusive Anleitungen zu Third-Party-Libraries, Authentifizierung/Autorisierung und Trial-Lizenz
Demos: Wingtip-Toys-Umsetzung sowie Telerik-Beispiele, wie in der Session gezeigt

Wichtig: Die Trial License erlaubt einen unkomplizierten Start in Demos und Tests. Für Produktion wird eine reguläre Lizenz benötigt.

Unser Fazit

„Retargeting einer Anwendung mit ASP.NET Web Forms auf .NET 8“ von Michael Ketting (RUBICON IT GmbH) liefert das, was Enterprise-Teams brauchen: keinen Heilspruch, sondern ein belastbares Vorgehensmodell. In wenigen Projektdatei-Änderungen läuft Web Forms auf .NET 8, Session und Auth können wohldosiert geteilt werden, und Third-Party-Controls bleiben intakt. Danach beginnt die Modernisierung dort, wo die Fachlichkeit pulsierend ist.

Wer Verantwortung für gewachsene Web-Forms-Systeme trägt und gleichzeitig sein Team für aktuelle .NET-Technologien begeistern will, findet in Core Forms eine Brücke, die auffallend wenig Reibung erzeugt – und die die Investition auf die nächsten echten Changes verteilt. Genau dieser Pragmatismus macht den Ansatz stark.

„Core Forms ist die Lösung, wenn man einfach mal schnell sein Entwicklerteam von .NET Framework morgen nach .NET bringen möchte und nicht erst in fünf Jahren.“

Am Ende steht nicht „Web Forms forever“, sondern eine modernisierte Anwendung auf .NET – nur ohne teuren Stillstand dazwischen.