.webp)
To platformer, næsten samme navn, og en beslutning, der i stilhed former de næste par års ingeniørarbejde. Det er fælden ved .NET Core vs. .NET Framework. Vælger du forkert, ender du enten med at skulle genopbygge noget, der fungerede fint, eller også bliver du ved med at hælde penge i en platform, der holdt op med at udvikle sig for flere år siden.
Her er det beroligende: Valget er mere klart, end navngivningen antyder. Denne guide gennemgår, hvad hver platform er, hvordan .NET Framework og .NET Core rent faktisk adskiller sig fra hinanden, og hvornår hver af dem er det rette valg – inklusiv de budget- og risikomæssige aspekter, som en ikke-teknisk beslutningstager skal stå til ansvar for. Lad os sammenligne dem.
Korte definitioner
Kort fortalt: brug .NET til nye serverapplikationer, mikrotjenester og platformuafhængige builds. Behold .NET Framework, når en applikation er afhængig af Windows-specifikke teknologier som Web Forms, WCF eller Windows Workflow.
Kort sagt. Til det meste nye arbejde er moderne .NET det mest sikre valg. Det er platformuafhængigt, hurtigere i uafhængige benchmarks og den eneste gren, som Microsoft stadig tilføjer funktioner til. Det ældre .NET Framework er stadig relevant til stabile, Windows-specifikke systemer. Det sværeste spørgsmål er sjældent teknisk; det er forretningsmæssigt. En tvungen migrering indebærer budget- og leveringsrisiko, mens det at blive på et runtime-miljø uden support medfører sikkerheds- og rekrutteringsrisiko. For de fleste virksomheder er den mindst risikofyldte vej en faseopdelt migrering, der leverer værdi hvert kvartal frem for én stor, altomfattende omskrivning. Beslutningsmatricen, parathedsvurderingen og omkostningsrammen nedenfor giver dig det, du skal bruge for at præsentere dette for en bestyrelse.
Begge kommer fra Microsoft og deler navn, men det er ikke det samme produkt. Forestil dig .NET Framework som det oprindelige hus, Microsoft byggede til Windows. Det moderne .NET er genopbygningen, der kan stå på ethvert fundament, du ønsker – uanset om det er Windows, Linux eller macOS. Samme familie, men meget forskelligt aftryk.
Microsofts egen vejledning om valg mellem .NET og .NET Framework peger nye serverapplikationer mod .NET og fastholder .NET Framework til ældre systemer, der er afhængige af teknologier som Web Forms eller WCF.
Definition: .NET Framework
Definition: .NET
Væsentlige forskelle mellem .NET og .NET Framework
Denne sammenligning af ydeevne læner sig op ad to uafhængige kilder: TechEmpowers community-drevne Web Framework Benchmarks og Microsofts løbende publicerede ASP.NET-resultater. I TechEmpowers Round 23 ligger ASP.NET Core blandt de hurtigste mainstream-webframeworks, der er testet. Tjek de aktuelle tal direkte ved kilden frem for at stole på et enkelt citeret tal, da runderne opdateres løbende.
Opsummering
Til de fleste moderne, performance-kritiske applikationer er .NET det stærkeste valg. Det håndterer cross-platform workloads, cloud-native deployments og containerisering uden problemer. Så medmindre du er tvunget til at bruge .NET Framework af tekniske årsager, bør nyudvikling altid starte på .NET.
Illustrativt scenarie. En operatør inden for vedvarende energi bygger en platform til realtidsovervågning af aktiver baseret på .NET og SignalR, hostet på Azure Kubernetes Service (AKS), som er Microsofts administrerede tjeneste til container-orkestrering. Formålet er prædiktiv vedligeholdelse på tværs af lokationer spredt over hele landet. Scenarierne i denne guide er sammensatte eksempler baseret på almindelige mønstre frem for specifikke kunder. For verificerede resultater med navngivne referencer, se vores cases.
Vælg .NET når:
Workloads der er bedst egnet til .NET
Kort fortalt:
Den hurtigste måde at vælge på er at afveje dine tekniske krav, dine platformbegrænsninger og din fremtidige retning. For det store overblik, se vores guide til valg af tech-stack til softwareudvikling. Kør derefter din case gennem .NET Core vs. .NET Framework-matrixen herunder.
Beslutningsmatrix
Hurtige regler:
De fleste sammenligninger stopper ved en funktionstabel og lader dig selv om det svære arbejde. I vores migrationsarbejde bruger vi en kort, gentagelig vurdering til at forvandle den tabel til en konkret beslutning. Vi kalder den Imaginary Cloud .NET Readiness Check. Fire spørgsmål, én betegnelse. Den er skrevet til beslutningstagere, ikke kun teknikere.
De fire spørgsmål
De tre modenhedsbetegnelser
Hvorfor overhovedet give det et navn? Fordi konsistens er vigtig. Alle interessenter vurderer de samme fire spørgsmål, og betegnelsen fører direkte til en dialog om budget og tidsplan i stedet for tekniske skænderier. Dette er et Imaginary Cloud-framework, og du er velkommen til at tilpasse og citere det.
Migrering fra .NET Framework til .NET kræver en grundig og trinvis tilgang. Ikke alle applikationer kan flyttes, og det er heller ikke alle, der bør flyttes – i hvert fald ikke på én gang. Betragt tjeklisten herunder som et værktøj til risikostyring og budgetbeskyttelse frem for blot en teknisk huskeliste. Hver fase fungerer som et kontrolpunkt, hvor du kan måle fremskridt, dokumentere værdi og beslutte, om du vil fortsætte. Og hvis du foretrækker ikke at stå for det internt, er det netop den type opgaver, vores .NET-udviklingsteam arbejder med til daglig.
Migrerings-tjekliste (5 vigtige trin)
Værktøjer, der hjælper med migrering:
Kort sagt:
Du behøver sjældent at flytte alt på én gang. .NET Standard er en formel specifikation af API'er, som både .NET Framework og moderne .NET implementerer, så et bibliotek kompileret mod .NET Standard 2.0 kan refereres fra begge sider. I praksis giver det dig mulighed for at udskille delt forretningslogik i .NET Standard-biblioteker og genbruge den på tværs af en eksisterende .NET Framework-frontend og dine nye .NET-tjenester, mens migreringen stadig er i gang. Betragt det som en bro, du bygger, før du krydser floden.
Der er dog to forbehold. For det første dækker .NET Standard biblioteker, ikke applikationsmodeller, så det giver dig ikke mulighed for at køre Web Forms eller WCF-hosting på moderne .NET. For det andet er .NET Standard nu fastfrosset, da nye API'er kun udgives til .NET. Så betragt det som en bro, ikke en destination.
Valget af .NET-version handler dels om funktioner og dels om livscyklussupport. Microsoft skifter mellem Long Term Support (LTS) og Standard Term Support (STS), og den kadence bør forme din køreplan lige så meget som enhver funktionsliste.
Centrale definitioner
Oversigt over .NET-supporttidslinje
Bekræft altid de aktuelle datoer for supportophør i forhold til Microsofts officielle .NET-supportpolitik før du fastlægger en køreplan, da kadencen rykker sig hver november.
Anbefalinger til virksomheder
.NET er velegnet til cross-platform-udvikling, cloud-native workloads med behov for skalering og performance-kritiske apps, hvilket gør det til et naturligt valg til nedenstående scenarier.
Cloud-native mikrotjenester
Moderne webapplikationer
Cross-platform desktop- og mobilapplikationer
Illustrativt scenarie. Et sundhedsteam bygger en app til enhedsstyring med .NET MAUI og Blazor Hybrid for at synkronisere data fra medicinsk udstyr på tværs af tablets på klinikken og bærbare computere hos medarbejdere i felten – alt sammen fra en enkelt delt kodebase.
AI, data og analyse-workloads
Illustrativt scenarie. En finansiel virksomhed integrerer ML.NET og Azure AI-tjenester i en .NET-applikation for at understøtte kreditvurdering og svindeldetektering under onboarding af kunder.
IoT og edge computing
Vigtige fordele for virksomheder
At blive på .NET Framework er oftere den rigtige beslutning, end de leverandører, der sælger migreringer, vil indrømme. I vores eget moderniseringsarbejde er de dyreste fejl sjældent de forsinkede migreringer. Det er de migreringer, der aldrig burde have været planlagt som en fuld omskrivning til at begynde med. Der er tre tilfælde, hvor det er det disciplinerede valg at blive, hvor man er.
En hård afhængighed af Windows-specifikke app-modeller. Web Forms, WCF-serverhosting og Windows Workflow Foundation har ingen understøttede modstykker i moderne .NET. At porte dem er ikke bare en genkompilering. Det er en omskrivning af det lag, hvor man for eksempel udskifter WCF med gRPC eller REST. Hvis disse teknologier udgør kernen i applikationen, er migreringsomkostningerne reelle, og tilbagebetalingstiden kan ligge år ude i fremtiden.
Et stabilt legacy-system med få ændringer. Hvis en applikation er i vedligeholdelsestilstand, næsten ikke ændrer sig og kører på en understøttet Windows-infrastruktur, er argumentet for at flytte den svagt. Moderniseringsbudgettet giver ofte et bedre afkast, når du bruger det på systemer, der er i aktiv udvikling.
Stramme tredjeparts- eller compliance-krav. Nogle kommercielle komponenter, rapporteringsmotorer eller certificerede integrationer er kun målrettet .NET Framework. Indtil disse leverandører frigiver .NET-kompatible versioner, kan en flytning af værtsapplikationen ødelægge en understøttet konfiguration.
Læringen er den samme i alle tre tilfælde. Migrér ikke bare for migrerings skyld. Isolér den Windows-specifikke afhængighed bag en klar grænse, hold .NET Framework-applikationen på et understøttet vedligeholdelsesspor, og byg alt nyt ved siden af på .NET. Det holder muligheden for at migrere senere åben uden at skulle betale for en omskrivning i dag.
Mange ser valget mellem .NET Core og .NET Framework som en teknisk beslutning. De største konsekvenser er dog økonomiske. Der er tre omkostninger, som enhver budgetansvarlig bør kende til.
Budgetrisikoen ved en total udskiftning. At udskifte et legacy-system i ét stort projekt svarer til at satse alt på ét bræt. Et fastlagt omfang, lang ventetid på levering og en stor risiko for budgetoverskridelser.
To omfattende undersøgelser gør risikoen konkret. The Standish Groups CHAOS-forskning har længe vist, at små softwareprojekter lykkes i omkring 90 % af tilfældene, mens store projekter lykkes i under 10 % af tilfældene. Derudover har forskning fra McKinsey og University of Oxford vist, at store it-projekter i gennemsnit overskrider budgettet med 45 %, samtidig med at de leverer 56 % mindre værdi end forventet.
Det mindre risikable alternativ er gradvis modernisering ved hjælp af strangler-mønsteret. Det spreder omkostningerne over tid, leverer fungerende software løbende og giver dig mulighed for at stoppe eller justere omfanget ved hver faseovergang. Du holder dine muligheder åbne i stedet for at satse hele året på én leveringsdato.
Omkostningen ved at blive på en platform uden support. Det er sjældent gratis at køre på et runtime-miljø, der ikke længere understøttes. Det betyder typisk øget risiko for sikkerheds- og compliance-brud, sværere rekruttering til en forældet stack og en voksende bunke af midlertidige løsninger, der gør fremtidige ændringer langsommere.
Disse omkostninger er ofte skjulte. De optræder ikke som en post i budgettet, før en revision, en sikkerhedshændelse eller en forsinket funktion bringer dem frem i lyset. Betragt derfor supportperioden som en ufravigelig planlægningsmæssig begrænsning frem for en vejledende anbefaling.
Tid til værdiskabelse ved en faseopdelt migrering. En faseopdelt tilgang giver afkast tidligt og ofte. Nye tjenester på .NET kan tages i brug og skabe værdi, mens legacy-komponenter udfases løbende, så gevinsterne realiseres længe før den fulde migrering er afsluttet.
Når du sammenligner muligheder, så se på mere end blot de samlede omkostninger. Se på, hvornår fordelene indtræffer. En faseopdelt plan kan levere de første målbare resultater inden for et kvartal. En total udskiftning leverer intet før til allersidst.
Gevinsten ved hosting og licensering. Her er den omkostningspost, som de fleste tekniske sammenligninger overser. Da moderne .NET kører på Linux, kan du hoste det på Linux-containere og virtuelle maskiner og dermed spare Windows Server-licenser på disse workloads. Det løber ofte op for tjenester med høj volumen og stor skalering, hvor du kører mange instanser. .NET Framework giver dig ikke dette valg, da det er låst til Windows, og hver host kræver en Windows-licens. For en økonomidirektør ændrer det migreringen til delvist at handle om løbende infrastrukturudgifter frem for blot en engangsinvestering. Den præcise besparelse afhænger af din cloud-udbyders prissætning for Windows kontra Linux, så lav en model baseret på dit eget antal instanser.
I praksis er dette i lige så høj grad et spørgsmål om risiko og timing som om teknologi, og for de fleste virksomheder er den faseopdelte vej den, der indebærer mindst af begge dele.
Skal du bygge noget nyt? .NET er det stærkeste valg. Det er platformuafhængigt, klarer sig fremragende i uafhængige benchmarks, og det er her, Microsoft lancerer alle nye funktioner. Er du stadig bundet til Web Forms eller WCF? Så er .NET Framework det rigtige valg, indtil de afhængigheder er håndteret.
Kort sagt: .NET Core vs. .NET Framework. Byg nyt på moderne .NET, behold kun .NET Framework, hvis du er reelt låst til Windows-specifikke funktioner, og migrer i faser frem for at satse hele året på en total omskrivning.
Kort fortalt:
Er .NET og .NET Framework det samme?
Nej. .NET er den moderne platform, der fungerer på tværs af styresystemer. .NET Framework er den ældre version, der kun virker til Windows. De deler navn, men har forskellige funktioner og udgivelsesmodeller.
Er .NET 4.8 det samme som .NET 8?
Nej. .NET 4.8 er den nyeste version af .NET Framework, og den fungerer kun til Windows. .NET 8 tilhører den samlede, platformuafhængige .NET -platform. De kan ikke bruges i flæng.
Skal jeg bruge .NET Core eller .NET Framework?
Brug .NET Core (nu blot .NET) til moderne apps, der skal køre på tværs af platforme. Vælg kun .NET Framework , hvis din app er afhængig af Web Forms, WCF eller andre teknologier, der kun findes til Windows.
Hvad er forskellen på .NET Standard og .NET Framework?.NET Standard er en specifikation, der definerer fælles API'er på tværs af .NET-implementeringer. .NET Framework er én specifik implementering. .NET Standard er det, der gør det muligt at dele kode mellem .NET Framework, .NET Core og Xamarin.
Er .NET Framework stadig understøttet af Microsoft?Ja. .NET Framework 4.8.1 er fuldt understøttet på Windows. Den modtager sikkerheds- og vedligeholdelsesopdateringer, men ingen nye funktioner.
Skal jeg bruge .NET 8 eller .NET 9?
Brug .NET 8 til produktion, da det er en Long Term Support (LTS)-udgivelse. Gem .NET 9 til kortvarig brug eller test, da det er en Standard Term Support (STS)-udgivelse. Tjek altid de aktuelle supportdatoer i Microsofts supportpolitik.
Kan jeg køre .NET og .NET Framework side om side?
Ja. Begge kan ligge på den samme maskine, hvilket gør gradvis migrering og hybridmodeller mulige.
Understøtter .NET WPF og Windows Forms?
Ja, i .NET 6, 7, 8 og 9. Men kun på Windows. De er ikke cross-platform.
Hvad hvis min applikation bruger Web Forms eller WCF?
Moderne .NET understøtter dem ikke. Du kan blive på .NET Framework eller migrere ved hjælp af alternativer som gRPC eller REST.
Hvordan ved jeg, om min app er klar til migrering?
Kør .NET Upgrade Assistant og Portability Analyzer for at finde API-kompatibilitet og hindringer for migrering. Kør derefter Imaginary Cloud .NET Readiness Check ovenfor for at omsætte resultatet til en beslutning.
Er .NET Core hurtigere end .NET Framework?
For de fleste server- og web-workloads, ja. Moderne .NET kører på CoreCLR-runtime og slår konsekvent .NET Framework i uafhængige benchmarks som TechEmpower Round 23. Forskellen er størst ved API'er med høj gennemstrømning og samtidige workloads. Til et lille internt skrivebordsværktøj vil du sandsynligvis ikke bemærke det.
Kan jeg bruge .NET Framework på Linux?
Nej. .NET Framework er kun til Windows. Hvis du har brug for Linux, skal du bruge moderne .NET (eller historisk set Mono til visse workloads). Dette er en af de mest almindelige årsager til, at teams vælger at migrere.
Hvad skal jeg bruge til et nyt .NET-projekt i 2026?
Til næsten alt nyt arbejde bør du bruge moderne .NET på den aktuelle LTS-version. Start kun på .NET Framework, hvis du har en fast afhængighed af Web Forms, WCF-hosting eller en anden Windows-specifik teknologi, som du ikke kan erstatte. Bekræft hvilken version der er den aktive LTS i henhold til Microsofts supportpolitik, da kadencen opdateres hver november.
Kan det betale sig at migrere fra .NET Framework nu?
Det afhænger af, om appen stadig er under udvikling. Hvis du aktivt investerer i nye funktioner, reducerer migrering den langsigtede risiko og giver adgang til bedre ydeevne og Linux-hosting. Hvis appen er stabil og sjældent ændres, er argumentet svagere. Isoler den, hold den på et understøttet vedligeholdelsesspor, og læg dit nye arbejde på .NET i stedet.
Hvad er 'strangler-mønsteret' inden for modernisering af applikationer?
En metode til gradvis modernisering af et legacy-system, hvor man udskifter enkelte komponenter eller tjenester frem for at omskrive hele applikationen på én gang.
Overvejer du denne beslutning for et specifikt system? Det hurtigste næste skridt er at køre det gennem vores Readiness Check ovenfor og derefter kvalitetsteste resultatet med en ekspert, der har erfaring med migrering af lignende workloads.
→ Se hvordan vi bygger og moderniserer .NET-systemer: .NET-udvikling.
→ Planlægger du en faseopdelt migrering? Kontakt vores team. Vi gennemgår dine afhængigheder og skitserer en sekvensplan – helt uforpligtende.
.webp)
Alexandra Mendes er Senior Growth Specialist hos Imaginary Cloud med 3+ års erfaring med at skrive om softwareudvikling, AI og digital transformation. Efter at have gennemført et frontend-udviklingskursus fik Alexandra nogle praktiske kodningsevner og arbejder nu tæt sammen med tekniske teams. Alexandra brænder for, hvordan nye teknologier former erhvervslivet og samfundet, og hun nyder at omdanne komplekse emner til klart og nyttigt indhold for beslutningstagere.
Inês Silva er projektleder med mere end fire års erfaring med at skrive om softwarelevering, agile metoder og tech-ledelse. Da hun startede sin karriere som udvikler, bidrager Inês med en ægte, dybdegående teknisk forståelse til ledelsessiden. Hun elsker at bygge bro mellem den overordnede forretningsstrategi og den daglige tekniske udførelse, og hun brænder for at dele praktiske tips, der hjælper teams med at samarbejde bedre og levere fremragende produkter.
People who read this post, also found these interesting:
.webp)
