Microsoft waarschuwt dat .NET 7-ondersteuning op 14 mei stopt

Microsoft stopt op 14 mei van dit jaar met ondersteuning voor .NET 7. Het bedrijf raadt gebruikers aan naar .NET 8 te upgraden. Gebruikers zouden ook .NET 6 kunnen gebruiken, wat net als versie 8 een lts-release is. Voor Visual Studio is minimaal .NET 8 nodig.

Microsoft schrijft in een supportdocument dat het per 14 mei stopt met de officiële ondersteuning van het ontwikkelaarsplatform. Dat kwam in 2022 uit als een standard term support-release met achttien maanden ondersteuning. Op 14 mei, een Patch Tuesday, krijgt het framework nog een laatste keer beveiligingsupdates, maar daarna stoppen die. Applicaties die .NET 7 gebruiken, blijven nog werken, maar Microsoft waarschuwt dat technische ondersteuning voor die software mogelijk niet meer beschikbaar is.

Ontwikkelaars kunnen volgens Microsoft het beste overstappen op .NET 8. Dat verscheen in november vorig jaar en is een long term support-release die nog tot november 2026 upgrades krijgt. Het is in theorie ook mogelijk om over te stappen naar .NET 6, dat ook een lts-release was en nog tot november van dit jaar met beveiligingsupdates wordt ondersteund.

Microsoft zegt dat Visual Studio-gebruikers ook het best kunnen upgraden. Vanaf de juni-update voor versies 17.4 en 17.6 wordt de .NET 7-component niet meer ondersteund. Bestaande applicaties blijven wel werken, zegt het bedrijf. Voor zowel .NET 6- als .NET 8-software is het vanaf dan nodig de .NET 8-sdk te gebruiken.

Reacties (52)

[henk717]

Leuk maar die .net versies zijn niet backwards compatible toch? Ik heb er meerdere naast elkaar draaien omdat anders een willekeurige app niet start.

[Ventieldopje]

Ik meen dat je met een .NET 8 runtime ook .NET 7 applicaties kan draaien, maar zeker weet ik het niet.

Hoe dan ook, applicaties kunnen er ook voor kiezen om de gebruikte .NET libraries mee te bakken in de executable, waardoor je dus niet los een runtime hoeft te installeren.

[turbojet80s]

Ik meen dat je met een .NET 8 runtime ook .NET 7 applicaties kan draaien, maar zeker weet ik het niet.

Helaas klopt dat niet

Hoe dan ook, applicaties kunnen er ook voor kiezen om de gebruikte .NET libraries mee te bakken in de executable, waardoor je dus niet los een runtime hoeft te installeren.

Wat veranderd dat aan het feit dat de ondersteuning stopt?

De beste oplossing is upgraden van .NET7 naar .NET8. Dat zal in de meeste gevallen niet veel voorstellen.

[Crysania]

Dit is het belangrijkste: het upgraden is bijna altijd redelijk simpel.(in ieder geval van 7 naar 8. Van 4.7 naar 8 is wat anders 😅)

En mensen die zeggen dat dit lastig is dat je je app moet upgraden zijn sowieso slecht bezig want waarschijnlijk heb je veel meer packages (bijv externe open source) die vol met security issues zitten en ook regelmatig updates nodig hebben.

Regel dus een goed proces in dat dit soort upgrades snel en makkelijk kan.

[turbojet80s]

Helemaal mee eens!

[DdeM]

Dit zal voor de meeste mensen geen probleem zijn, codebase updaten van 7.0 naar 8.0 gaat meestal wel goed. Let er alleen wel op als je nog in-process azure functions gebruikt, dit in .Net 8.0 niet meer ondersteund wordt en je naar isolated worker functions zal moeten gaan, wat is sommige gevallen niet zo makkelijk is.

[crazyx]

.net 7 ondersteunde ook al geen in process azure functions meer. .net 6 was de laatste versie.

https://learn.microsoft.c...rocess-guide?tabs=windows

[Arjan321]

Ondersteuning voor in-process voor dotnet 8 is nog wel geplanned.

[DdeM]

Ah nice, dat wist ik niet

[DdeM]

Ah dan liepen degene die mij over hun migratie pad hadden verteld verder achter dan ik dacht

[bantoo]

Mensen die kiezen voor een oneven release in plaats van de meest recente even release zullen vast wel weten dat ze een versiebump moeten doen.

[Remzi1993]

Inderdaad en zouden er ook rekening mee moeten houden.

[kars noordhuis]

Of die mensen zijn net als mij en klikken gewoon op download latest onder het mom "het zal, ik beun er toch maar wat tooltjes voor op het werk mee". Voor mij is dit een mooie wake up call dat ik maar eens moet kijken of die oude meuk libraries die ik nodig heb nog werken met .net 8

[xFeverr]

En mensen die op een even versie zitten weten dat ze naar de volgende even versie moeten upgraden. Ze krijgen wel dubbel zoveel de tijd dan de oneven-versie. Maar ook .NET 6 gaat er voor het einde van het jaar uit.

[jos707]

Ligt misschien aan mij maar ik vind elk jaar een major release nogal snel gaan. Vroeger had je met .net 4 nog minor releases en de versies hadden ook langer support. Je hoefde zo nodig niet elk jaar te upgraden maar sinds .net core krijgen de devs elk jaar opnieuw een upgrade voor hun kiezen.

Meestal is dit midden in een project waardoor je telkens maar het geluk moet hebben dat er geen bugs in de nieuwe versie zijn gekropen. En spreek ik nog niet van alle regressie testen die weer opnieuw moeten worden afgemaald.

Kost een hoop tijd en energie en vraag mij af of het allemaal waard is, want het is nu niet dat ze in elke release met baanbrekende nieuwe features komen.

[sam45]

Je kan er natuurlijk ook gewoon voor kiezen om enkel de LTS releases te gebruiken, dan moet je maar om de 3 jaar upgraden.

[SiErRa]

Dit kan je toch zien aankomen, en dus voor plannen?
Je released toch een regelmatig, en dan zijn je regressietests toch wel geautomatiseerd mag ik hopen?

[Thejman1989]

Zelf vind ik de release strategie altijd wat raar. Wij hebben bijvoorbeeld bewust net 7 overgeslagen omdat net 6 langer support had. Als ze net 7 in ieder geval net zo lang als 6 support hadden gegeven, waren er meer mensen eerder overgestapt naar 7. Wie weet veranderd het in de toekomst nog.

[Ablaze]

Er is niet echt een reden om de oneven releases over te slaan. Ze zijn net zo stabiel en upgraden is makkelijk en meestal zorgeloos.
Maar je kunt van 6 ook rechtstreeks naar 8 zonder issues. Het is dus maar net wat je prefereert.

[Thejman1989]

Niet echt want als je dus naar 7 gaat ben je eerder uit de support fase en moet je dus eerder je componenten upgraden. Netto komt dat neer op meer tijd besteed aan upgrade werk, zonder echte nieuwe functionaliteit (als je het zoals ons niet nodig hebt). Geen probleem misschien als je 1 component onderhoud, maar als je meerdere kleine services onderhoud telt het wel mee in de beslissing.

[Robin94]

Voor hetzelfde geld ben je in 6 dingen aan het bouwen die in 7 niet meer ondersteund worden. Ben je nog veel meer tijd kwijt aan upgraden.

[xFeverr]

Het verschil tussen LTS en non-LTS is dat je bij LTS één versie kan overslaan. En bij release van de volgende versie krijg je dubbel zoveel tijd om over te stappen: 12 maanden ipv 6 maanden. Iedereen zou dus naar .NET 8 moeten. Als .NET 9 uit komt kun je kiezen om te upgraden. Zowel de upgraders als de niet-upgraders zullen weer naar .NET 10 moeten.

Mijn advies is om niet vooraf vast te hangen aan LTS ‘omdat het een LTS is’. Kijk bij de release van .NET 9 of er de tijd is om te upgraden. Je mag hem overslaan, maar je mist wel nieuwe features en een hoop performanceverbeteringen. Als je de tijd hebt, waarom niet doen dan? Voor die 6 maandjes extra?

Een LTS-versie is niet van hogere kwaliteit of stabieler ofzo. Het is slechts wat langer ondersteund dan een standard release.

[SuperDre]

Juist, dat is waar ik nu aan denk als ik zie dat wij aan een nieuw systeem gaan werken, welke mogelijk opgedeelt wordt in een heleboel losse services al voor 1 module, terwijl het systeem uit tich modules zal bestaan die in de loop van de tijd gebouwd gaan worden. Dan zie ik het bijna als een hel om al die losse services te moeten upgraden, ipv enkele grotere 'monoliete' modules.
Of zie ik dat verkeerd? Kom zelf nog vooral van 'legacy' monoliet development ofwel 1 project waar heeeeel veel in zit, maar wel 1 codebase, en dus 'weinig' tijd kost om te upgraden naar bv een hogere .NET versie.

[_soh]

Mijn ervaring is juist andersom. Hoe kleiner de service, hoe makkelijker is het om een service upgrade in de sprint te krijgen en ben je ook zo klaar. Je geüpgraded service werkt dan gewoon samen met andere services die niet geüpgraded zijn. De monoliet upgraden (zeker als deze veel dependencies heeft en al ouder is) zie ik telkens weer uitgesteld worden totdat het echt een project op zichzelf wordt.

[SuperDre]

Maarja, die service zelf heeft ook zo zn dependecies, dus als je heeel veel services hebt dan kost het ook heel veel tijd om ze allemaal te upgraden omdat je ze allemaal 1 voor 1 moet aflopen.

[_soh]

Je mist net m’n punt. Het verschil zit hem in de planbaarheid. De grote items zijn lastig ingepland te krijgen als je een product owner hebt met andere prioriteiten. Een kleine service updaten is een filler die altijd wel past in de sprint.

[SuperDre]

Ik begrijp je wel hoor, maar vele kleintjes maken ook een grote.

[MeMoRy]

Nou nee, dat ligt geheel aan je work load. Zoals bijna elke keer blijkt, heeft Microsoft namelijk weinig focus op desktop frameworks.
WinAppSDK de laatste versie en ook MAUI hebben nog steeds problemen met .net 8. Ik ben een paar dagen kwijt geweest om alles goed te krijgen en daarna zijn we nog een paar nieuwe bugs tegengekomen waarvoor issues bij MS lopen (en maar weinig aandacht van hun kant krijgen)

Webservers zijn wel makkelijk, maar de rest niet.

[Ablaze]

Ik denk dat die platforms gewoon nog wat aan de jonge kant zijn. Ik heb nooit problemen met het upgraden van WinForms of WPF apps. Zelfs van Framework rechtstreeks naar 8 gaat zo goed als zorgeloos.

[diedie2]

Het is in theorie ook mogelijk om over te stappen naar .NET 6, dat ook een lts-release was en nog tot november van dit jaar met beveiligingsupdates wordt ondersteund.

Dan verlies je toch (mogelijks) functionaliteit? Het feit dat je er als dev ooit voor gekozen hebt om over te schakelen naar .NET 7 wil toch zeggen dat je iets wilde doen die in vorige versies niet kon, nee?

[MneoreJ]

Nou nee dus, althans niet per se. Genoeg devs die gewoon de nieuwe versie gebruiken "want nieuwer". En dat is niet eens een slecht idee, want je krijgt met nieuwe versies van .NET meestal ook "gratis" performance bumps van de betere runtime/compiler. Inderdaad, maak je gebruik van API's die net in .NET 7 toegevoegd zijn dan kan dit niet, en dan merk je het ook wel.

Dat er "in theorie" staat lijkt me dan ook terecht: bijna niemand zal van .NET 7 naar 6 gaan puur omdat er geen support meer is. Dan ga je dus gewoon naar .NET 8, want dan heb je nog betere performance, en een stuk langer support dan die paar extra maandjes van .NET 6. Het is zelfs zo theoretisch dat het wat mij betreft helemaal weggelaten had mogen worden...

[xFeverr]

Terug gaan naar .NET 6 is echt een slecht plan. Dan stel je de upgrade naar .NET 8 met een half jaartje uit en daarna ben je alsnog aan de beurt. Niet slim dus

[uiltje]

Ik zou ze de kost moeten geven...

[dasiro]

ik heb er geen ervaring mee, maar is 1.5 jaar niet héél kort? Sommige dingen zijn langer in ontwikkeling dit, laat staan dat het in productie ook nog ondersteund moet worden

[PdeBie]

Dan is het ook gebruikelijk om een LTS versie te gebruiken. Maar als het een klein project is wat tijdelijk draait kan je prima dit soort versies gebruiken. Kan je vaak alvast wat snoepen van nieuwe features die later alleen maar beter worden.

[xFeverr]

Waarom is dat gebruikelijk? Het verschil is 2x 1,5 jaar support vs 1x 3 jaar support. Is dat dan echt zo heilig? Als je de upgrade naar een standard versie qua tijd even niet uitkomt, sure. Maar als dat prima kan in de planning, gewoon lekker doen. Een LTS gebruiken alleen maar omdat het een LTS is vind ik persoonlijk een slechte reden.

Onze projecten, en dat zijn er best wel wat, doen ook de tussenversies. Liever elk jaar wat nieuwe features en verbeteringen dan elke twee jaar dubbel zoveel nieuwe features.

[PdeBie]

Waarom is dat gebruikelijk?

Gebruikelijk is wellicht wat overdreven inderdaad, maar ik weet dat er bedrijven zijn die juist vanwege die langere support periode de LTS versie prefereren.

Dat komt dan vooral vanuit management en niet de technici. De technici zien graag de tussentijdse updates, maar management ziet dat als een keer extra updaten wat kosten (tijd) met zich meebrengt en weinig directe waarde (lees: geld) oplevert.

[LOTG]

Waarom aanraden naar 6 over te stappen? Dat slaat nergens op, aangezien de kans is dat je een nieuwe feature gebruikt hebt groter is dan dat je naar de volgende LTS gaat. 8 is al een paar maanden uit en is waarschijnlijk naar te upgraden door alleen de versie in je csproj aan te passen.

En overstappen naar 6 betekend dat je eind dit jaar alsnog naar 8 of 9 moet.

[jaenster]

Waarom is dit een nieuwsbericht? Het is niet eens een LTS versie, zoals .net6 die wel nog een half jaar support heeft, staat niet voor niks in die image. Dit lijkt mij verder geen nieuws waarde te hebben. We krijgen toch ook niet elk half jaar een nieuwsbericht dat nodejs 14/16 niet meer supported is?

[michaelkamen]

Ik wordt eerlijk gezegd een beetje moedeloos van alle "waarom is dit een nieuwsbericht" posts.
Waarom niet?
Dit artikel is informatief en technologie-gerelateerd. Ik wist het niet, en nu wel, dus kan er bij m'n volgende project in Visual Studio rekening mee houden.

Het fijne van Tweakers vind ik juist dat er een mix van nieuws voorbij komt. Consumenten-elektronica, PC hardware, software, software-diensten, AI.
Wat je interessant vindt is volledig persoonlijk, dus je kunt er voor kiezen om zo'n artikel dan niet te openen.

[Mushroomician]

Tip: voordat je een project begint kijk je ff welke versie tot wanneer ondersteund wordt. En kies dan altijd voor de meest recente LTS versie tenzij je écht een hele goede specifieke reden hebt om daarvan af te wijken. De LTS-versies hebben altijd overlap met elkaar.

[Marve79]

Ik vind dit ook geen nieuws. Als je dit gebruikt als developer weet je dit allang. Voor niet programmeurs is het compleet irrelevant.

[tedades]

Het gros van de mensen weet ook dat ze een belasting aangifte moeten doen of dat zomertijd dit weekend weer in gaat. Maar het kleinere clubje mensen die een herinnering kon gebruiken heeft hier mogelijk wel baat bij. Je zou dan misschien een label op zo'n post willen zien zodat je het bericht over kunt slaan of weg kunt filteren maar blijkbaar is er nu de keuze gemaakt om wat extra content te posten.

[jaenster]

Vaak ben ik het met je beredenatie eens maar dit gaat niet om een niet LTS release, niet een vervroegde stop van support (dit was bij release al bekend) en elke zelfrespecterende dev slaat de oneven versies over.

Dus dit vind ik daadwerkelijke een "waarom is dit nieuws?" waardige post.

[jmvdkolk]

Wat een korte support voor zelfs de LTS versies. .Net 8 heeft maar support tot november 2026, voor een totaal van 3 jaar support? .Net 4.8.1 heeft indefinite support, maar .Net 8 maar 3 jaar vanaf introductie? Vanwaar dat verschil?

[SiErRa]

Microsoft wilde een nieuwe kant op met .Net (toen nog core) en om snel features te kunnen toevoegen is het wel handig om een korte cyclus te hebben.

.Net 4.8.1 is .Net Framework, de 20 jaar oude originele variant van .Net. Daar wordt eigenlijk niets meer op gedaan behalve security en bug fixes.

Het valt eigenlijk best mee om bij te blijven, als je software ontwikkelt ben je toch continue aan het releasen en ook al werk je niet actief aan iets qua functionaliteit, moet het alsnog vanwege dependencies met security fixes.

[jmvdkolk]

Dank je wel.

In mijn zakelijke wereld (grote multinationals) wordt gewerkt met minimaal 3+2 jaar onderhoud op software. Dit betekent 3 jaar actief onderhoud op iedere versie, en twee jaar alleen nog hotfixes. Deze methodologie van Microsoft betekent dat we gedwongen worden om net voor het verlopen van de eerste 3 jaar over te stappen naar de nieuwste .Net versie. Anders kunnen we die 2 jaar niet overbruggen. Afhankelijk van de upgrade complexiteit van toekomstige .Net versies, zou dat wel eens te veel werk kunnen zijn om financieel uit te kunnen. Voor mij betekent dit dat we moeten overwegen om van .Net af te stappen.

[Alex]

En dit is dus exact waarom Microsoft dit doet. In de groot zakelijke wereld, een wereld waar zij ook erg bekend zijn, is er massa’s aan achterstallig onderhoud, lekker systemen, etc. Microsoft wilde hiermee breken toen ze .NET gingen herontwerpen.
In een wereld waar iets vandaag een feature is, morgen een bug, de dag erna een privacy issue en volgende week een major security issue, zul je actief maintenance moeten opnemen in je software. En waar .NET Framework vrijwel voor altijd backwards compatibility ondersteunde, geeft Microsoft hier een nieuw voorbeeld , beter aligned op de huidige wereld. Elk jaar een flinke release en geregeld breaking changes met goede redeneringen. Hierdoor forceren ze Softare vendors in vergelijkbare modellen te gaan werken. En hun klanten dus ook.
Ik ken inmiddels een hoop vendors die vereisen van hun klanten dat ze minimaal elk jaar een updaten. Duur? Onrealistisch? Etc? Misschien. Het zorgt er wel voor dat software gebruik veiliger wordt en soms zelfs zaken als CO2 uitstoot verminderd worden doordat runtimes geupdate worden.
En laten we wel zijn… met een enigzinds moderne SDLC kun je dit ook simpelweg elke nacht even testen… Tools als dependabot kunnen het bijblijven geheel voor je automatiseren. Dan is het enkel nog reageren op het moment dat de upgrade de code breekt…

[jmvdkolk]

Don't get me wrong. 3+2 betekent niet dat er geen onderhoud gedaan wordt. 3+2 betekent dat er 3 jaar onderhoud inclusief features is (vanuit de vendor), en twee jaar onderhoud alleen voor security en bugs. In die 2 jaar zijn klanten bezig met migratie naar de volgende major versie, die ook 3+2 heeft. 3+2 staat dus niet gelijk aan achterstallig onderhoud. De security en bugfixes worden parallel ontwikkeld met features en worden geinstalleerd wanneer ze beschikbaar zijn, binnen maintenance windows. Daarnaast wordt er 1x per jaar geupgrade naar eventuele nieuwe feature releases. De feature releases hebben geen (zware) migratie trajecten.

De overgang naar de volgende major versie is vaak wel een overgang met een zware migratie. Je ziet dat sommige organisaties proberen om extra onderhoud aan te schaffen om de +2 op te rekken. Dit omdat er nooit een compromis kan zijn op security.

Achterstallig onderhoud is er zeker. Dat is vooral in de in-house gemaakte componenten. Maar vast niet exclusief.

[Xenan]

Een upgrade naar een hogere .Net versie is over het algemeen weinig werk. De terugwaartse compatibiliteit is over het algemeen erg goed (maar niet 100%).