Microsoft brengt .NET 9 en .NET Aspire 9 uit met efficiënter geheugengebruik

Microsoft heeft .NET 9 uitgebracht. In de nieuwe versie van het ontwikkelaarsframework zijn 'duizenden verbeteringen in prestaties, beveiliging en functionaliteit' doorgevoerd, aldus het bedrijf. Daarmee kan het framework meer requests afhandelen en is geheugengebruik efficiënter.

Microsoft kondigde .NET 9 aan tijdens de .NET Conf-ontwikkelaarsconferentie. Het framework komt tegelijk uit met een nieuwe update voor Visual Studio 2022, v17.12. Het bedrijf schreef in september al over de prestatieverbeteringen in .NET. Microsoft zegt 'duizenden' verbeteringen te hebben doorgevoerd waardoor programmeertalen efficiënter kunnen worden opgebouwd in Windows. .NET 9 krijgt achttien maanden ondersteuning als een standaardrelease.

Er zitten onder andere veel verbeteringen in de Server Garbage Collector-functionaliteit. Die is volgens Microsoft 'significant aangepast' zodat geheugeneisen beter worden afgestemd op de omgeving, zoals de lokale machine of een VM. Dat is voornamelijk interessant voor omgevingen waar veel processorkernen worden gebruikt, omdat geheugenbeheer in zulke omgevingen al snel complex wordt. In benchmarks zoals TechEmpower zou het geheugengebruik zelfs met tot wel 93 procent kunnen dalen. Verder kan het aantal api-requests via .NET 9 in sommige gevallen tot wel vijftien procent omhoog. Microsoft zegt dat dat bij in ieder geval een json-benchmark het geval was.

Microsoft heeft verder ook .NET Aspire 9 uitgebracht. Daarin zitten meerdere nieuwe features zoals de mogelijkheid om containers te wisselen tussen debugomgevingen en applicaties te starten en stoppen vanuit het dashboard. Ook heeft Aspire meer integraties voor niet alleen nieuwe api's, maar ook voor AI-modellen zoals die van OpenAI, LlamaIndex en uiteraard zijn eigen Azure-integratie.

Reacties (69)

[R4gnax]

Microsoft zegt 'duizenden' verbeteringen te hebben doorgevoerd waardoor programmeertalen efficiënter kunnen worden opgebouwd in Windows.

Gevalletje 'lost in translation'?
Wat ze schrijven is dat er meer dan duizend aan performance gerelateerde wijzigingen zijn gemaakt aan de .NET runtime, de workloads (zoals ASP.NET), en de ondersteunde talen, met betere algoritmiek om efficientere uitvoerbare code te genereren.

Er staat niet dat ze meerdere duizenden van dit soort wijzigingen hebben doorgevoerd.
Er staat ook niet dat hiermee programmeertalen efficienter worden opgebouwd - wel programma's.
En er staat ook niet dat dit enkel Windows betreft.

[Reactie gewijzigd door R4gnax op 14 november 2024 01:02]

[mduijvendijk]

Als je wil weten welke performancewijzigingen ze allemaal hebben gemaakt:
https://devblogs.microsof...ce-improvements-in-net-9/

[Powerblast]

Die 93% minder geheugengebruik is waarschijnlijk wel een verkoopspraatje met de maximum die ze er mee gehaald hebben, maar dan nog blijft het wel fantastisch hoe ze dat klaar spelen. Spijtig dat het geen lts versie, anders had ik direct overgeschakeld. Maar misschien toch eens wat mee spelen

[Reactie gewijzigd door Powerblast op 13 november 2024 20:20]

[xFeverr]

Niet overstappen "omdat het geen LTS is", is wat mij betreft een verkeerde reden. Er zitten geen verschillen in stabiliteit en kwaliteit tussen LTS-releases (de even-versienummers) en non-LTS-releases (de oneven-versienummers). Het enige verschil, zoals de naam al zegt, is dat de LTS-versies langere ondersteuning hebben.

Hoeveel langer? Nou, precies het dubbele van een standaard release. Een standaard release is 1 jaar (tot de eerstevolgende release) + 6 maanden overstaptijd. En een LTS is 2 jaar (je kunt dan één versie skippen) + 12 maanden overstaptijd. En dat is echt het enige verschil. Zowel .NET 8 als .NET 9 zullen over moeten stappen naar .NET 10.

Nu .NET 9 uit is, is het verschil tussen .NET 8 en .NET 9 dus minimaal qua support. Dus daar hoef je het niet voor te doen. Voor een nieuw project kun je dus altijd latest pakken. Voor iedereen op .NET 8 is het eigenlijk alleen de vraag: willen we de tussenrelease met de bijbehorende prestatieverbeteringen oppakken of skippen we 1 versie en doen we het upgraden volgend jaar, omdat we er nu geen tijd/zin/whatever voor hebben.

Wij pakken de tussenreleases gewoon mee. Gratis performanceverbeteringen terwijl je er heel weinig voor inlevert. Wij upgraden meestal binnen een maand of 2, dus die 12 maanden overstaptijd hebben wij zeker niet nodig.

[Reactie gewijzigd door xFeverr op 14 november 2024 07:53]

[DrDelete]

Bij LTS zou je wellicht bij overstap na 2mnd dan nog tegen C# syntax aanlopen die paar maanden later er uit gaat ? Ik heb het zelf nog niet meegemaakt, maar wellicht anderen wel ?

[increddibelly]

nee, dat is niet hoe het werkt. Bij elke major versie kunnen breaking changes zijn, maar dat is maar zelden. oook dingen waar de community relatief veel last van heeft, zoals ConfigureAwait(false), kappen ze niet zomaar even eruit. Er gaat een zeer zeer grondig proces aan vooraf om nieuwe features te bepalen, dat wordt veelal publiek toegelicht op github en ik vind het erg interessant om de keuzevorming te volgen.

[Tjidde]

In mijn applicaties die ik nog op de test versie van 9 had getest. Heb ik buiten de versies verhogen niets aangepast en de applicaties werkte nog volledig.

[morrowyn]

Lijkt me eerder een investerings vraagstuk en welke kosten met een upgrade gemoeid zijn, zowel in capaciteit als geld.

[Bigs]

Dit is inderdaad wel een specifieke use case met een vrij barebones applicatie, maar toch is het gaaf dat .NET in die arena gewoon de concurrentie met bijvoorbeeld Go aankan. En onze zware traditionele enterprise applicaties hebben vast ook profijt van deze verbeteringen

[BugBoy]

Als je hoort wat de prestatiewinst elke keer is bij een nieuwe major .NET Core versie, dan zou je bijna denken dat .NET Core v3 onbruikbaar traag was. Maar het valt allemaal best mee en in de praktijk merk je niet heel erg veel van die veranderingen. Ik heb .NET vanaf .NET Framework v1.0 gebruikt t/m .NET Core v8. De overgang naar .NET Core is een goede stap geweest, omdat je op Linux kan draaien.

Wel vind ik .NET Core gewoon te zware voor lichte apparaten. Het is een JIT taal en je hebt een runtime nodig om het te makkelijk te draaien. Je hebt wel AOT opties, maar de taal is daar eigenlijk niet lekker geschikt voor. Met workaround (lees: hacks) hebben ze het toch een beetje mogelijk gemaakt, maar doordat bijv. reflectie diep in de taal zit is het best tricky. Die binaries zijn vaak lomp groot en starten relatief langzaam op.

Je merkt echt dat C# en .NET uit begin 21-ste eeuw komt. C# was innovatief met async/await, maar ook dat is een beetje knullig. Het is een olievlek, want een functie die een async functie moet aanroepen moet ook weer async zijn. Dat werkt weer niet lekker met events en sommige callbacks. Dat heeft Go veel fraaier gedaan, waar elke functie async is (maar dat merk je niet). Ook go-routines werken weer prettiger dan in C#, waar je overal aan merkt dat "async" en multi-threading er later ingebouwd is.

Ook non-nullability is zo'n hack die opgelost is met annotaties en daardoor kan een non-nullable toch aangeroepen worden met "null" door externe componenten.

De taal wordt steeds uitgebreider en dat is soms comfortabel, maar je kan een switch/case tegenwoordig op veel manieren schrijven. Dat maakt coding-conventions lastig. Go kan niet veel en dat is soms irritant of veel tikwerk. Voordeel is wel dat je meestal maar 1 manier hebt om het te doen. Ook formatting is in Go vastgelegd, dus nooit meer discussie daarover.

Ik werk nu met C#, Go en Rust en alle talen hebben zo hun kwaliteiten en tekortkomingen. Rust vind ik eigenlijk het mooiste, maar ik vind het traag om in te ontwikkelen. Leercurve is flink, weinig gestandaardiseerde libraries en traag code/compile/debug cycle (compilatie duurt relatief lang t.o.v. Go). Go is weer lekker vlot, maar wel erg basic en de taal heeft wat onhandigheden waardoor je snel fouten kan maken (bijv. nil exceptions). C# is best een aardige tussenweg, maar ik vind het hebben van een runtime erg onhandig. Waar ik met Rust en Go vaak gebruik kan maken van een "scratch" base image, wil dat voor .NET vrijwel niet.

[Powerblast]

Go ken ik eerlijk gezegd helemaal niet, maar ik ben dan zelf wel eens benieuwd hoe het zich na deze verbeteringen verhoudt tegenover bijvoorbeeld Rust. 93% minder memory usage is echt wel een heel pak en één van de sellings points van Rust is bijvoorbeeld low memory usage. Dat verschil lijkt hiermee zo goed als helemaal weggewerkt.

[cricque]

Ik moet hier denken, wij van wc eend zeggen dat ... Op sommige gebieden zal het vast wel zo zijn, maar overall 93% minder, dat lijkt me wel heel sterk. Het kan uiteraard zo zijn. Maar ik neem beweringen altijd met een korreltje zout.

[BugBoy]

In .NET 5 was gRPC al bijna net zo snel als in Rust (artikel). Hele pakkende benchmarks, maar het geheugengebruik was veel hoger. Dit soort statements moet je altijd met een korreltje zout nemen. 30% minder geheugengebruik is echt fors en dat zal wellicht in edge-cases haalbaar zijn, maar in de praktijk ga je het waarschijnlijk niet zien. Je kan natuurlijk de GC veel agressiever maken en dat zal het geheugengebruik doen dalen, maar dat kost weer extra CPU cycles.

[BugBoy]

Ik heb ook eens een benchmark van .NET gezien waarin ze lieten zien dat de gRPC performance van .NET Core op hetzelfde niveau zat als van Rust. Ze konden dus beiden ongeveer dezelfde load aan. Wat er niet bij vermeld werd was dat het geheugengebruik van de .NET versie vele malen hoger was dan die van Rust.

Rust is ook een veel veiligere taal, omdat de taal bepaalde safety constructies heeft. Je kan in C# een object aan 5 threads geven en dus synchronisatie issues krijgen. In Rust wordt dat netjes al tijdens het compileren afgevangen door een specifiek "owner" model. Heel veilig, maar vereist soms wel een wat andere manier van denken. Daardoor is de leercurve best stevig.

.NET Core is gewoon een runtime gebaseerde taal met een garbage-collector. Je maakt mij niet wijs dat dit veel sneller/efficiënter gaat zijn dan een taal als Rust. Als je MS moet geloven is elke versie van .NET Core weer 10-30% zuiniger met geheugen. In de praktijk zie ik dat helaas niet terug.

[THETCR]

.NET is een framework, Go is een programmeertaal. Dat is appels en peren vergelijken.
Dan moet je C# tegenover Go zetten of .NET tegenover Fiber of Kit.

[84hannes]

Spijtig dat het geen lts versie, anders had ik direct overgeschakeld.

Laten ze dit soort technologieën vooral als experiment in een non-LTS introduceren, als het goed werkt zal het over een jaar al in .net 10 zitten.

[Reactie gewijzigd door 84hannes op 13 november 2024 23:35]

[System]

Komt toch op hetzelfde neer? Net9 zal waarschijnlijk even lang ondersteund worden als net8, dus op zich geen reden om niet over te gaan.
Op ons werk kiezen we wel altijd de LTS, maar dat is om andere reden.

[BugBoy]

Wat is dan die reden? Ben altijd wel benieuwd waarom sommige bedrijven persé LTS willen.

[SiErRa]

Afhankelijk hoe groot je codebase is (honderden repo's), is een upgrade duur. Verdien je dat terug door de nieuwe features?
Soms heb je afhankelijkheden die niet zo snel zijn met het supporten van nieuwe versies, waardoor je heel weinig tijd hebt om de upgrade te doen.

Ontwikkelaars willen graag werken met "the latest and greatest" (ik ook ) maar puur vanuit een zakelijk perspectief zijn het alleen kosten. En zit je liever langer op een LTS versie.

[jimshatt]

In de praktijk merk ik dat de upgrade van LTS naar LTS ongeveer net zo duur is als de losse upgrades bijelkaar. Misschien is het makkelijker uit te leggen aan het management, dat zou kunnen.
Persoonlijk vind ik meerdere kleine updates een stuk minder frustrerend.

[System]

Elke upgrade bevat risico's op vlak van stabiliteit en bugs.
Dus kiezen wij om dat risico slechts om de 2 jaar te nemen.
Zo was ons traject FW3.5, FW4.0, FW4.5.2, FW4.6.2, FW4.8, CORE3.1, NET5(uitzonderlijk), NET6, NET8, en later waarschijjnlijk NET10.

[System]

Omdat we niet ieder jaar 10tallen repo's willen updaten.
Dus elke 2 jaar. En dan kies je logischerwijs LTS.

Als je elk jaar kan/wil schakelen heeft het geen reden om te wachten.

[increddibelly]

Nee, beide krijgen support tot .NET 10 er is (en dan nog een beetje) typisch volgend jaar ergens rond deze tijd. Dan krijgt .NET 10 LTS weer 2 jaar LTS tot .NET 12 er is, en .Net 11 ook reguliere ondersteuning tot .NET 12 er is.

Bij LTS kun je 1 versie skippen, dat is fijn voor oomgevingen waar onderhoud kwetsbaar of duur is. Bij een regular release krijg je de laatste jaren flinke performance en andere optimalisaties, en die winst kun je vrij makkelijk aan je klant verkopen binnenhalen door, in dit geval, een 8 in een 9 te veranderen in je project file en opnieuw te deployen.

[Jolijter]

Ik heb in mijn jaren dat ik dotnet core applicaties ontwikkel nog nooit last gehad van het feit dat een versie STS en niet LTS was. Upgraden is sinds dotnet core 3 in mijn ervaring een pijnloze ervaring geworden waar ik nog geen uur mee bezig ben. Het gaat daarbij om monorepo met een leuke verzameling micro services.

[BugBoy]

Dat ligt er wel een beetje aan welke packages je gebruikt. Echt upgraden doe je ook om bijvoorbeeld de "nieuwe" JSON packages te gebruiken i.p.v. NewtonSoft. Dat kost meestal echt wel wat meer tijd. Ook zijn een aantal packages niet meer officieel supported. IdentityServer4, Swashbuckle, ... zijn voorbeelden die erg populair waren, maar niet meer ondersteund worden op nieuwere .NET versies. Ook dat moet je meenemen. Om die reden ging ik vaak pas na 1-2 maanden na release over. Dan waren de meeste packages wel aangepast en er meer duidelijkheid over deprecated packages.

[JapyDooge]

Ja dit beloofd wel goeds voor .NET 10 (die wel LTS is) en over ongeveer een jaar uit komt.

[rko4u]

Wij hebben sinds 13 september een onverklaarbaar geheugenprobleem op een web service die rond die tijd niet veranderd is. Misschien hebben ze wel de bug opgelost die dat veroorzaakte. Een sneller json verwerking kan inderdaad ook geen kwaad. Al meerdere keren heb ik mij afgevraagd waarom dat zo enorm traag was. Maar inderdaad moeten we nog een jaar wachten op de LTS.

[BugBoy]

Geen code-changes en geen packages aangepast? Bugs die spontaan verdwijnen komen ook vaak spontaan weer terug.

[rko4u]

Op de machine waar het draait is op .Net niveau niets veranderd en ook de code van de services niet. We hebben de machine moeten stutten met een 6gb geheugen maximum op deze service, gezien zelfs een verdubbeling van het geheugen het probleem niet verhielp.
Ik heb dus meer last van geheugen bugs die ineens uit het niets ontstaan, dan dat ze spontaan verdwijnen.

[BugBoy]

Ik heb 20 jaar veel troubleshooting gedaan. Het kwam maar heel weinig voor dat problemen voortkwamen uit Windows of .NET. In 99% van de gevallen was het gewoon code-fouten. Ga eens aan de slag met JetBrains dotMemory en ga maar eens profilen. Grote kans dat het gewoon code-fouten zijn.

Geheugen verdubbelen zonder te weten waarom je dat nodig hebt is als olie blijven bijvullen zonder te onderzoeken waar het olieverbruik vandaan komt. Daar komt gegarandeerd ellende van...

[rko4u]

Want door code fouten groeit het geheugengebruik zonder reden van in korte tijd van een paar honderd kb naar 60GB? Dat zou niet moeten kunnen met asp.net zonder statics en de garbage collector van .Net.

Daarnaast misschien iets minder hoog van de toren blazen als je iets niet begrijpt?
De geheugenaanpassingen zijn stut acties geweest om de machine in de lucht te kunnen houden, gezien het probleem de server onderuit trekt, en de trigger van het probleem niet makkelijk te localiseren is. Soms is er wat tijd nodig om de trigger te vinden. Het merendeel van de tijd draait alles namelijk prima en ineens is de server uit het geheugen. Dit alles om van een prio 1 naar een lagere prio situatie te komen. En nee, het is niet op de testomgeving te reproduceren.

[BugBoy]

Ik blaas niet hoog van de toren. Het is gewoon een stuk aannemelijker dat een fout in jullie code dit veroorzaakt dan dat dit aan .NET ligt. Je code mag wellicht niet aangepast zijn, maar de data waarmee het werkt wel. Dat kan bugs triggeren. Vraag maar aan CrowdStrike...

[Zenomyscus]

Persoonlijk stap ik over naar 9 omdat de stap naar 10 waarschijnlijk niet zo groot is en je dat vrij snel kunt doen nadat het uit is.

[jeroen3]

Toch niet nog meer varianten .net, het is a zo onduidelijk…

Twee versies visual studio, 4 versies .net.
Hoe ga je ooit iets vinden in de docs, google of stackoverflow als ze alles hetzelfde noemen?

[robertpNL]

Er zijn twee .NET implementaties voor het bouwen van apps: .NET en .NET Framework. De nieuwste is .NET 9 en is de opvolger van .NET 8. Deze reeks is de voorkeur als je gaat bouwen. Het is ook platform overschrijdend, dus je web, app of services kan uitgevoerd worden op meerdere platformen (Windows, Linux en MacOS). Je bouwt .NET projecten met VS Code (dat ook beschikbaar is voor Linux en MacOS).

De andere variant, .NET Framework, is voor Windows alleen. De laatste versie is 4.8 en al geruime tijd beschikbaar (en wordt ook niet meer doorontwikkeld). .Soms kan .NET Framework nog wel een optie zijn als de app nog gebruik maakt van .NET Framework. Bijvoorbeeld (oude) Windows Forms applicaties, ASp.NET Web Forms. Je bouwt dan voornamelijk met Visual Studio (community editie).

[Reactie gewijzigd door robertpNL op 13 november 2024 21:13]

[Jolijter]

.NET projecten bouwen kan met VS Code. Visual Studio en Jetbrains Rider zijn echter een veel comfortabelere ervaring en hebben allebei een gratis variant (met voorwaarden).

[84hannes]

Visual Studio en Jetbrains Rider zijn echter een veel comfortabelere ervaring

Dan wil ik wel eens weten welke versie van VS jij gebruikt, want elke versie die ik start is een trage klont die van alles lijkt te willen maar niets echt goed kan, anders dan het consumeren van system resources. Ik houd het lekker op een snelle text-editor (op dit moment Helix maar VSCode heb ik ook gebruikt) en een goede Language Server (ik denk dat ik Omnisharp voor alles gebruik, in elk geval formatting).

Dat ik Linux gebruik is hier niet de beperking, ik heb beschikking tot Windows, maar het maakt de ervaring voor mij wel veel gemakkelijker: ik ben niet gewend op knopjes te klikken om iets te compileren.

[Jolijter]

Ik moet je eerlijk bekennen dat ik Visual Studio zelf niet meer gebruik en al een tijdje ben overgestapt naar Jetbrains Rider (welke ook prima op Linux draait in mijn ervaring). Het zal niet minder resources gebruiken, ik gebruik het vooral voor de refactormogelijkheden en andere hulpmiddelen die ik nog niet met een LSP werkbaar heb gezien.

Editors als Helix met een LSP erachter vind ik altijd wel interessant, mogelijk dat ik daar een keer mee ga experimenteren om te kijken hoe dotnet ontwikkeling daarmee gaat. NeoVim met Omnisharp een paar jaar geleden was... niet erg behulpzaam.

[84hannes]

ik gebruik het vooral voor de refactormogelijkheden

Ja, die zijn teleurstellend bij VS, al is Helix met Omnisharp niet beter.

[jimshatt]

Welke refactorings? Voornamelijk benieuwd omdat ik best tevreden ben met VS en JetBrains voor mij niet echt lekker aanvoelde.
VSCode werkt voor mij goed als ik een project met front- en backend heb (React + .Net microservices bijvoorbeeld)

[Jolijter]

Een aantal die ik met keybindings in mijn vingertoppen heb zijn bijvoorbeeld:
- Extract methods
- Inline variable
- Extract variable
- Introduce parameter
- Remove parameter

Verdere hulpmiddelen tijdens het ontwikkelen:
Wanneer je een class/record/enum wilt aanmaken begin ik de classname te typen waar ik hem wil gebruiken en Rider geeft me dan de optie om een class/record/enum met die naam aan te maken in het huidige bestand. Met een andere refactor verplaats ik die class dan naar het project/map/bestand waar ik hem eigenlijk wil hebben waarbij optioneel de namespaces automatisch worden bijgewerkt. Wanneer ik weet dat ik een bepaalde methode wil gaan aanmaken begin ik dat te typen op de plaats waar ik het wil gebruiken met de parameters die ik erin wil stoppen, dan geeft Rider me de optie om die methode aan te maken en neemt gelijk alle gebruikte parameters met het juiste type mee.

Het zijn allemaal handelingen die mij in staat stellen om dat wat in mijn hoofd zit op mijn scherm te krijgen in zo min mogelijk stappen. Zonder kun je precies dezelfde software maken, maar daar wordt ik minder gelukkig van.

[jimshatt]

Duidelijk, bedankt. Een aantal ervan zitten ook in VS (code) maar waarschijnlijk niet allemaal.

[KeesAlderlieste]

.Net projecten bouw je ook met Visual Studio

[gslance]

Je kan .NET projecten ook gewoon in Visual Studio bouwen, hoor. En daarvoor maakt het niet uit of je nou Enterprise of Community edition gebruikt.

[rko4u]

Het klassieke .Net framework bestaat alleen nog omdat het in Windows ingebouwd zit. Voor nieuwe ontwikkelingen moet je het in principe niet meer gebruiken.

[Powerblast]

Dit is gewoon een nieuwe versie van een reeds bestaande variant hoor. Geen nieuwe variant maar de opvolger van .net 8.

[84hannes]

Dit is gewoon een nieuwe versie van een reeds bestaande variant hoor. Geen nieuwe variant maar de opvolger van .net 8.

Het lijkt mij dat @jeroen3 het over .NET 9 Aspire heeft. Bestaat er zoiets als .NET 8 Aspire?

En eerlijk gezegd heb ik nog steeds geen idee wat het is. Teksten als

.NET Aspire is a set of powerful tools, templates, and packages for building observable, production ready apps.

en

.NET Aspire is designed to improve the experience of building .NET cloud-native apps. It provides a consistent, opinionated set of tools and patterns that help you build and run distributed apps.

maken het ook niet echt concreet.

[R4gnax]

Aspire is voornamelijk een set formalismen om een applicatie en afhankelijkheden van services, waaronder third-party services, makkelijk out-of-the-box te managen middels een reeks automatisch beheerde en deployende Docker/OCI containers - ook tijdens lokaal ontwikkelen.
Een soort van solution orchestrator, dus.

Hier is een bult tooling, prefab templates, en APIs tegen aan gegooid om het allemaal te stroomlijnen en verder werkbaar te maken en houden.

[Caelorum]

Het is een toolset. Geen framework. Een beetje vergelijkbaar met Entity Framework wat ook een set van libraries + tools is.

[Loller1]

4 versies van .NET? Hoe tel je dat dan? Mogen ze van jou gewoon geen updates meer uitbrengen?

[84hannes]

Het was natuurlijk een vergissing om .net Core bij 1.0 te beginnen, net zoals de compiler voor C# volgens mij twee 1.0 versies heeft gehad (de oude en Roslyn). Dus als je het over .Net 2.0 hebt is niet duidelijk of het over Core of Framework gaat, terwijl beide in zekere zin voorlopers van .net 9.0 zijn. Dat gezegd hebbende gaat het nu de goede kant op met consistentie.

[jeroen3]

.NET Framework
.NET Core
.NET
.NET Aspire

[LOTG]

Ik tel maar 2 versies. .NET en .NET Core zijn niet verschillende versies. Alleen de Core is gedropped van de naam en ze hebben versie 4 geskipped als een soort van overgang tussen .NET Core en .NET Framework (v4.8) welke niet meer ontwikkeld word.

Aspire is geen versie van .NET, net zoals ASP.NET (Core) ook geen versie van .NET is. Of Entity Framework (Core). Het is een toolset voor cloud applicaties boven op .NET.

Dus er is alleen .NET en .NET Framework, waarvan .NET is wat actief ontwikkeld word. Framework is end of life op wat security fixes af en toe na.

[YGDRASSIL]

Het is heel simpel. Je hebt .NET 9 nu en dat is alles. Ergens in de laatste 10 jaar was het tijd om over te gaan van Framework48 op .NETx. .NETx is ondertussen heeel veeel verder en beter.

[Vrietje]

Eens kijken of we er bij ons wat mee kunnen. Vast niet want veel draait nog op 4.5.2 en gaat kapot bij een upgrade naar 4.8. Maar goed het programma wordt toch uitgefaseerd.

[BugBoy]

Als een upgrade van .NET Framework v4.5.2 naar v4.8 een probleem gaat zijn, dan is .NET Core helemaal ondenkbaar. Overigens is v4.5.2 al ruim 2 jaar EOL, dus bizar dat jullie een Framework gebruiken voor een product dat geen security patches meer krijgt. Er is eigenlijk geen reden om niet te kunnen upgraden naar .NET v4.8, tenzij je heel oude Windows versies (die nog langer EOL zijn) wilt ondersteunen.

Een "upgrade" naar .NET Core is eigenlijk een rewrite van je code. Het hosting model, logging, dependency injection, ... is totaal anders. Ik zou een bestaand product dan ook niet gauw porteren naar .NET Core. Beter lekker op 4.8.2 blijven zitten en die kosten in een nieuw product stoppen...

[LOTG]

Wij hebben ook nog een paar dingen op .NET Framework 4.8 zitten. Mooi aangegrepen om dat allemaal eens van de grond af aan opnieuw te bouwen in .NET, scheelt een hoop als je niet vast zit aan keuzes die andere voor jou tijd gemaakt hebben en niet zo mooi en handig waren.

Upgraden tussen .NET versies is meestal ook bijna geen werk, vooral niet als je een beetje bij blijft met packages (wat je sowieso wil i.v.m. security). Een project laten verloederen en achteraf dan maar eens upgraden is waar het ineens 3x zo veel tijd kost.

Afhankelijk van hoe complex een framework project is kan het trouwens best snel om te bouwen zijn naar .NET. Veel basis zaken zijn echt veel simpeler in .NET dan in Framework. Vooral als je een 4.5 project hebt wat waarschijnlijk ook nog assembly redirecting gebruikt en zo.

[kiddingguy]

Op mijn W11 machine is .Net (runtime) 6.0.36 geinstalleerd.
Heeft het nut deze te verwijderen en deze v9 te installeren?

[Franckey]

Op mijn W11 machine is .Net (runtime) 6.0.36 geinstalleerd.
Heeft het nut deze te verwijderen en deze v9 te installeren?

Nee. Je hebt die runtime waarschijnlijk omdat je een programma gebruik wat dat nodig heeft. Zolang je geen update van dat programma hebt, heb je de oude runtime nog nodig.

[R4gnax]

Als dat zo is zou je dat programma zsm moeten lozen, want .NET 6 is niet meer ondersteund en krijgt sinds 12 Nov jl. geen beveiligingsupdates meer.

[FerronN]

Het lager memory gebruik is echt heel fijn! Vooral bij een micro service architectuur. Wij hebben een boel microservices en dat vreet onnodig veel memory als je naar de load kijkt. Ben heel benieuwd met hoeveel dat afneemt na de overstap op .Net 9.

[Reactie gewijzigd door FerronN op 13 november 2024 22:02]

[Jolijter]

Het zijn leuke getallen die iedereen ten goede komen. Ik ben wel sceptisch over het verschil dat het gaat maken in het dagelijks gebruik. Zodra een applicatie wat meer dan CRUD operaties doet ben ik bang dat het een verwaarloosbaar verschil gaat opleveren, maar ik wordt daat graag op terecht gewezen.

[Jim80]

Ook Rider (Visual Studio concurrent) heeft een gelijktijdige release gedaan. Knap dat ze dat op dezelfde dag doen zodat je meteen alles up to date hebt.

Net m'n eigen codebase geswitched naar .Net 9 en meteen een geslaagde build.
De "raw" performance is er wat op vooruit gegaan. Ik heb hiervoor een eigen tooltje met 10 eenvoudige operaties in een loop, zoals lezen en schrijven in array, + - * / bewerkingen en if/then. Die code gebruik ik dan om voor verschillende programmeertalen een indicatie te krijgen van hoeveel van deze bewerkingen per seconde uitgevoerd worden. (ik noem het Mops: million operations per sec.) Eerste cijfer is singe thread, gevolgd door een multiplier van hoeveel extra er valt te halen bij maximale multithreading.

Dit zijn de resultaten op mijn AMD 5800X 8 core:

• c++: 3983 Mops x7.50
• .Net 8:3984 Mops x7.06
• .Net 9: 3982 Mops x8.11

Het is in de eerste plaats al opmerkelijk dat single thread .Net 8 en 9 het even goed doen als c++. Bij multithread gaf .net 8 echter iets minder performance dan c++. Tot mijn verrassing is dit in .Net 9 een volledige multiplier hoger (een extra thread dus gewonnen) en hierdoor zelfs sneller dan c++.

[BugBoy]

Zonder te weten welke optimalisaties zijn ingesteld zegt dit eigenlijk niet zo gek veel. Ruwe operaties zoals jij beschrijft kunnen redelijk 1:1 naar assembler worden omgezet. Zaken als efficient thread-switching, asynchrone code, GC overhead, memory usage, ... zijn veel belangrijker in de praktijk.

[Jim80]

100% akkoord.
Voor die andere zaken heb ik ook allerlei benchmarks, maar dan zou mijn post veel te lang worden.
Die raw performance is een basisvereiste

[Blacklight447]

Developers! developers! developers!

[Chills]

Voor wie het een beetje ontgaat, Steve Ballmer die wat enthousiast is: https://youtu.be/8fcSviC7cRM?si=IUiuwSM8_MQRYKXU

[SuperDre]

Ben benieuwd wat voor verbeteringen er voor Blazor weer in zitten.

[HerrPino]

Allemaal mooi maar wij blijven bij .NET 8, met name LTS. Door te blijven bij LTS versies hoeven we minder vaak onze code base om te zetten. Hoewel het code technisch allemaal zo gedaan is betekent het wel regressietests.

We willen ook onze code base niet op meerdere versies van het framework hebben en ondersteunen. In de loop van 2026 zullen we ergens overstappen op .NET 10.

[Reactie gewijzigd door HerrPino op 14 november 2024 10:27]