Flytta en WinForms- eller WPF-applikation till webben utan en stor omskrivning

I många företag, särskilt inom tillverkning, logistik och grossisthandel, är det viktigaste programmet inte en webbapplikation. Det är en skrivbordsapplikation i WinForms eller WPF, byggd för tio eller femton år sedan, och hela verksamheten går på den.

Och den fungerar. Det är också problemet, för ingen vill röra något som fungerar. Men runt den samlas saker som kostar allt mer.

Först den ärliga sanningen: WinForms och WPF är inte döda

WinForms och WPF stöds i .NET 10. Om du flyttar applikationen från .NET Framework till aktuell .NET kan den fortsätta att köras i många år.

Problemet är alltså inte att den slutar fungera. Problemet är allt runt omkring.

Där en skrivbordsapplikation börjar kosta pengar

• Installation på varje dator. En ny version betyder en runda mellan datorerna, eller ett skript som misslyckas på hälften av dem. Och sedan arbetar fem personer i fem olika versioner.
• Arbete hemifrån och på resande fot. Åtkomst utifrån kräver Citrix eller fjärrskrivbord, med licenser och servrar som ska betalas.
• En surfplatta i lagret, en mobil ute på fältet. Skrivbordsapplikationen körs inte på dem.
• Ett databaslösenord på varje dator. De flesta gamla skrivbordsapplikationer ansluter direkt till databasen, så databasens användarnamn och lösenord ligger i konfigurationen på varje dator. Den som har en dator har åtkomst till databasen. Det är ett säkerhetshål som de flesta chefer inte känner till.
• Det blir allt svårare att hitta folk. Nya utvecklare bygger för webben, och allt färre underhåller skrivbordsapplikationer.

Tre vägar

Väg	Vad det innebär	Risk	När det är rimligt
Stanna på skrivbordet	Flytta till .NET 10, allt annat som förut	Låg	När några få personer använder den på kontoret och ingen behöver den utifrån
Skriva om allt på en gång	En ny webbapplikation, den gamla stängs av på bytesdagen	Hög	Sällan: när den gamla applikationen är liten och enkel
Steg för steg	Ny teknik skärm för skärm, parallellt med den gamla applikationen	Låg	Nästan alltid när applikationen är stor och viktig

En total omskrivning låter snyggt, men i praktiken betyder den ett eller två år där den nya applikationen byggs och den gamla står still. När den nya äntligen kommer fungerar hälften av den annorlunda än folk är vana vid, och allt går sönder på en gång.

Steg-för-steg-vägen som få känner till

Microsoft har en komponent som heter BlazorWebView. Den bäddar in Blazor-skärmar direkt i en befintlig WinForms- eller WPF-applikation.

Det betyder att nya skärmar skrivs i Blazor men visas inuti den gamla applikationen. Användarna märker ingen migrering, bara att en skärm är ny. När alla skärmar har flyttats går samma Blazor-komponenter in i en webbapplikation, utan att skrivas om.

Så här ser en ny Blazor-skärm ut inuti en befintlig WinForms-applikation:

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);

Och senare samma komponent i webbapplikationen:

@page "/orders"

<OrderList />

För WPF fungerar det på samma sätt, med AddWpfBlazorWebView. Komponenterna ligger i ett gemensamt bibliotek som används av både skrivbords- och webbapplikationen.

Hur det ser ut steg för steg

1. LogikAffärsregler bakom ett API
2. Nya skärmarBlazor inuti den gamla applikationen
3. WebbSamma komponenter i webbläsaren
4. KlartSkrivbordet avvecklas när ingen behöver det

1. Affärslogiken bakom ett API. Regler och databasåtkomst lyfts ut ur skärmarna till en gemensam del bakom ett API. På vägen försvinner databaslösenordet från användarnas datorer, eftersom det nu bara är API:et som pratar med databasen.
2. Nya skärmar i Blazor. Varje ny eller omarbetad skärm skrivs i Blazor och visas inuti den gamla applikationen.
3. Webbversion. När tillräckligt många skärmar har flyttats öppnas de i webbläsaren, på en dator hemma, en surfplatta i lagret eller en mobil ute på fältet.
4. Skrivbordet avvecklas. Den gamla applikationen försvinner först när ingen behöver den längre, inte på något riskabelt bytesdatum.

Du har hela tiden en applikation som fungerar. Det finns inget år av bara väntan.

Om applikationen fortfarande körs på .NET Framework är första steget oftast migrering till .NET 10, eftersom BlazorWebView körs på aktuell .NET.

Det här kan du kontrollera redan den här veckan

Öppna skrivbordsapplikationens konfigurationsfil på en dator och leta efter anslutningssträngen (connection string). Om den innehåller ett användarnamn och lösenord till databasen finns det lösenordet på varje dator i företaget.

Räkna sedan: hur många skulle behöva applikationen utanför kontoret, på en surfplatta eller ute på fältet, och kan inte använda den i dag?

Så arbetar vi

Det här är precis vad vi gör: vi flyttar gamla .NET-applikationer till webben med Blazor steg för steg, skärm för skärm, utan driftstopp och utan ett år av väntan. Vi börjar med att gå igenom applikationen och bestämma vilken skärm som går först, och oftast ser du den första nya Blazor-skärmen inuti din befintliga applikation inom några veckor. Det första steget är ett kostnadsfritt samtal på 30 minuter.