WinForms- oder WPF-Anwendung ins Web bringen, ohne alles neu zu schreiben

In vielen Unternehmen, besonders in Produktion, Logistik und Großhandel, ist das wichtigste Programm keine Webanwendung. Es ist eine Desktop-Anwendung in WinForms oder WPF, vor zehn oder fünfzehn Jahren gebaut, und das ganze Geschäft läuft darüber.

Und sie funktioniert. Genau das ist auch das Problem, denn niemand will etwas anfassen, das funktioniert. Aber rundherum sammeln sich Dinge an, die immer mehr kosten.

Zuerst die ehrliche Wahrheit: WinForms und WPF sind nicht tot

WinForms und WPF werden auch unter .NET 10 unterstützt. Wenn Sie die Anwendung von .NET Framework auf aktuelles .NET umstellen, kann sie noch Jahre laufen.

Das Problem ist also nicht, dass sie aufhört zu funktionieren. Das Problem ist alles drumherum.

Wo eine Desktop-Anwendung anfängt, Geld zu kosten

• Installation auf jedem PC. Eine neue Version heißt, von PC zu PC zu gehen, oder ein Skript, das auf der Hälfte scheitert. Und dann arbeiten fünf Leute mit fünf verschiedenen Versionen.
• Homeoffice und Außendienst. Für den Zugriff von außen braucht es Citrix oder Remote Desktop, mit Lizenzen und Servern, die bezahlt werden.
• Tablet im Lager, Handy im Außendienst. Darauf läuft die Desktop-Anwendung nicht.
• Datenbank-Passwort auf jedem PC. Die meisten alten Desktop-Anwendungen verbinden sich direkt mit der Datenbank, also stehen Benutzername und Passwort der Datenbank in der Konfiguration auf jedem PC. Wer einen PC hat, hat Zugriff auf die Datenbank. Das ist eine Sicherheitslücke, von der die meisten Geschäftsführer nichts wissen.
• Es wird immer schwieriger, Leute zu finden. Neue Entwickler bauen fürs Web, und immer weniger Leute pflegen Desktop-Anwendungen.

Drei Wege

Weg	Was das heißt	Risiko	Wann es sinnvoll ist
Auf dem Desktop bleiben	Umstieg auf .NET 10, sonst alles gleich	Gering	Wenn wenige Leute im Büro sie nutzen und niemand von außen zugreifen muss
Alles auf einmal neu schreiben	Neue Webanwendung, die alte wird am Stichtag abgeschaltet	Hoch	Selten: wenn die alte Anwendung klein und einfach ist
Schrittweise	Neue Technik Bildschirm für Bildschirm, neben der alten Anwendung	Gering	Fast immer, wenn die Anwendung groß und wichtig ist

Alles neu zu schreiben klingt sauber, heißt in der Praxis aber ein bis zwei Jahre, in denen die neue Anwendung entsteht und die alte stillsteht. Wenn die neue endlich kommt, funktioniert die Hälfte anders, als die Leute es gewohnt sind, und alles bricht auf einmal.

Der schrittweise Weg, den kaum jemand kennt

Microsoft hat eine Komponente namens BlazorWebView. Damit lassen sich Blazor-Bildschirme direkt in eine bestehende WinForms- oder WPF-Anwendung einbetten.

Neue Bildschirme werden also in Blazor geschrieben, aber innerhalb der alten Anwendung angezeigt. Die Anwender merken keine Migration, nur dass ein Bildschirm neu ist. Sind alle Bildschirme umgestellt, wandern dieselben Blazor-Komponenten in eine Webanwendung, ohne neu geschrieben zu werden.

So sieht ein neuer Blazor-Bildschirm in einer bestehenden WinForms-Anwendung aus:

var services = new ServiceCollection();
services.AddWindowsFormsBlazorWebView();

var ordersView = new BlazorWebView
{
    Dock = DockStyle.Fill,
    HostPage = @"wwwroot\index.html",
    Services = services.BuildServiceProvider(),
};
ordersView.RootComponents.Add<OrderList>("#app");

ordersTab.Controls.Add(ordersView);

Und später dieselbe Komponente in der Webanwendung:

@page "/orders"

<OrderList />

Für WPF funktioniert es genauso, mit AddWpfBlazorWebView. Die Komponenten liegen in einer gemeinsamen Bibliothek, die Desktop- und Webanwendung nutzen.

Wie das Schritt für Schritt aussieht

1. LogikGeschäftsregeln hinter einer API
2. Neue BildschirmeBlazor in der alten Anwendung
3. WebDieselben Komponenten im Browser
4. EndeDesktop weg, wenn ihn niemand braucht

1. Geschäftslogik hinter eine API. Regeln und Datenbankzugriff werden aus den Bildschirmen in einen gemeinsamen Teil hinter einer API verschoben. Dabei verschwindet auch das Datenbank-Passwort von den PCs der Anwender, denn nur noch die API spricht mit der Datenbank.
2. Neue Bildschirme in Blazor. Jeder neue oder überarbeitete Bildschirm wird in Blazor geschrieben und in der alten Anwendung angezeigt.
3. Webversion. Sind genug Bildschirme umgestellt, öffnen sie sich im Browser, am PC zu Hause, auf dem Tablet im Lager oder auf dem Handy im Außendienst.
4. Desktop abschalten. Die alte Anwendung verschwindet erst, wenn sie niemand mehr braucht, nicht an einem riskanten Stichtag.

Zu jedem Zeitpunkt haben Sie eine Anwendung, die funktioniert. Es gibt kein Jahr, in dem nur gewartet wird.

Läuft die Anwendung noch auf .NET Framework, ist der erste Schritt meist der Umstieg auf .NET 10, denn BlazorWebView läuft auf aktuellem .NET.

Was Sie diese Woche prüfen können

Öffnen Sie auf einem PC die Konfigurationsdatei der Desktop-Anwendung und suchen Sie den Connection String. Stehen darin Benutzername und Passwort der Datenbank, liegt dieses Passwort auf jedem PC im Unternehmen.

Zählen Sie dann: Wie viele Leute bräuchten die Anwendung außerhalb des Büros, auf dem Tablet oder im Außendienst, und können sie heute nicht nutzen?

Wie wir arbeiten

Genau das machen wir: Wir bringen alte .NET-Anwendungen schrittweise mit Blazor ins Web, Bildschirm für Bildschirm, ohne Ausfall und ohne ein Jahr Warten. Wir beginnen mit einer Durchsicht der Anwendung und der Entscheidung, welcher Bildschirm zuerst kommt, und den ersten neuen Blazor-Bildschirm in Ihrer bestehenden Anwendung sehen Sie meist schon nach wenigen Wochen. Der erste Schritt ist ein kostenloses 30-minütiges Gespräch.