Microsoft brengt .NET 7 uit met uniforme codebase

Microsoft heeft .NET 7 beschikbaar gemaakt. De nieuwe versie van het ontwikkelaarsplatform is de recentste poging van Microsoft om .NET universeler te maken met een enkele sdk en runtime.

Microsoft heeft de software publiek beschikbaar gemaakt nadat die eerst als bèta bestond. De nieuwe versie van .NET is 7.0 en heeft zowel betere prestaties als nieuwe features. Microsoft schrijft in een blogpost dat die nieuwe features onder andere ondersteuning voor C# 11 en F# 7 zijn. Microsoft heeft ook .NET MAUI in de software meegeleverd, en de meeste bestaande frameworks zoals Blazor en Forms zijn bijgewerkt. Ook is het mogelijk om .NET 7-projecten in containers te draaien en om workflows in GitHub-acties te implementeren. .NET 7 heeft ook native ondersteuning voor Arm64 en verbeterde ondersteuning voor Linux-systemen.

De nieuwe versie van de software is de derde keer dat Microsoft probeert om .NET 'unified' te maken. Dat probeerde het bedrijf al met .NET 5. Microsoft werkt al sinds 2014 aan de mogelijkheid om het oude framework, dat tot dan toe alleen op Windows werkte, open source beschikbaar te maken en het compatibel te maken met andere systemen. Met .NET 5 probeerde Microsoft al een enkele .NET-runtime en een enkel framework te maken op basis van een enkele codebase. Later zei Microsoft dat dat pas in .NET 6 zou gebeuren. Door de pandemie en de bijbehorende logistieke uitdagingen besloot Microsoft bepaalde componenten zoals het Multi-platform App UI niet mee te leveren in .NET. Dat gebeurt in versie 7.0 nu wel voor het eerst. Daarmee lijkt het erop alsof alle code van .NET die eerst in Core, Framework, Xamarin en Mono zat, definitief is overgeheveld naar de enkele codebase van .NET 7.0.

.NET 7 is een standard term support-release. Dat betekent dat de software 18 maanden ondersteuning krijgt, tot mei 2024. Dat is minder dan voorganger .NET 6, dat nog tot november 2024 wordt ondersteund als long term support-release.

Reacties (87)

[DJBnJack]

"de meest recente poging van Microsoft om .NET universeler te maken met een enkele sdk en runtime"

Ik snap dat het voor mensen die niet dagelijks met het .NET framework werken ingewikkeld lijkt (en daarom ook is), maar het zijn vooral incrementele stappen.
Als je deze Wiki-pagina er bij pakt, zie je dat het al veel meer iteraties heeft ondergaan dan "de derde keer" doet vermoeden: https://nl.wikipedia.org/wiki/.NET_Core

Er zullen altijd programma's zijn, geschreven tegen .NET, die alleen op Windows werken. Dat is ook niet aan Microsoft. Met de nieuwe weg waar Microsoft ingeslagen is (open source, linux-friendly), is het nu al geruime tijd mogelijk om software te ontwikkelen op het .NET platform wat werkt zowel binnen als buiten het Windows ecosysteem. Dit is gewoon weer een stapje breder.

[3raser]

Zo te zien zit WinForms (gelukkig) ook nog steeds in .NET 7. Dat zal vast niet op Linux gaan werken. Dan is er nu MAUI wat al meer GUI cross-platform compatibel is maar ook daar wordt Linux nog niet ondersteund zo te zien.

[Qws]

MAUI en React Native gebruiken native GUI componenten, maar Linux zelf heeft geen standaard GUI..

Persoonlijk zie ik liever MAUI (Xaml) voor web. De andere crossplatform tools (Uno, React Native, Flutter) hebben ook web support.

[Ablaze]

Dat is Blazor, denk ik? Je kunt Blazor embedden in een app via MAUI.

[Myri]

Misschien de moeite om ook eens te kijken naar Uno als Linux je/jullie vereiste is (https://platform.uno/)

[Vishari Beduk]

WinForms zit al langer in .NET core en is voor de windows desktop. MAUI is voor mobiel + web.
In theorie kan je een MAUI desktop app voor Linux ontwikkelen maar daar gaat niemand vrolijk van worden.

[Jim80]

Klopt, ik maak al jaren Linux applicaties in .NET Core. Die vereisen geen install of extra dependencies, dus volledig self contained (copy & run). Met 1 druk op de knop compileer je even goed voor windows of mac.

Je mag enkel geen natieve os calls doen buiten .net om, maar dat geldt even goed voor c++ als je cross-platform wil.

Die compatibiliteit zat dus al lang goed!

[3raser]

Die vereisen geen install of extra dependencies

Behalve dan de .NET runtime neem ik aan? Op een standaard Debian installatie kun je je .NET applicatie niet draaien voor zover ik weet.

[DJBnJack]

Je kan een self-contained executable maken sinds uit m'n hoofd .NET 6.
...al vrij lang blijkt!

[Reactie gewijzigd door DJBnJack op 22 juli 2024 14:14]

[BugBoy]

Dat kan inderdaad, maar start-up tijden, binary-size, geheugengebruik, ... zijn allemaal vrij dramatisch vergeleken met programma's die je maakt met C/C++, Go of Rust. Voor server-applicaties is het allemaal prima te doen, maar Microsoft target het ook voor IOT devices en daar is het toch echt wel worstelen vind ik.

.NET leent zich gewoon niet goed voor trimming, door keuzes uit het verleden (bijv. reflection). Het dynamisch kunnen laden van assemblies, dynamisch aanroepen van functies (bijv. ASP.NET controllers) maken dit erg lastig. Ondanks vele beloftes is het nog altijd vrij dramatisch gesteld en ik verwacht ook niet dat dit echt goed gaat komen, tenzij MS wil breken met het verleden.

De leeftijd van .NET begint ondertussen toch wat pijnlijk te worden. Kijk hoe non-nullable types zijn geïmplementeerd. In plaats van een native type is het gekunsteld gedaan met type annotaties (attributen). Dat geeft allemaal ellende. Alle calls van buiten je assembly met een non-nullable type moet je alsnog controleren op null.

Ik werk met .NET sinds versie 1.0 (denk zo'n 20 jaar terug), maar sinds een paar jaar programmeer ik ook met Go en Rust. Dan ga je ineens veel beter de tekortkomingen van .NET zien. Ik kan het iedere progammeur aanraden om zijn horizon te verbreden. Niet alles in .NET blijven doen (deed ik vroeger ook), maar kijk ook eens verder.

[R4gnax]

Kijk hoe non-nullable types zijn geïmplementeerd. In plaats van een native type is het gekunsteld gedaan met type annotaties (attributen). Dat geeft allemaal ellende. Alle calls van buiten je assembly met een non-nullable type moet je alsnog controleren op null.

Ik kijk en zie dat het realistisch niet anders had gekund. Er is niet zoiets als 'een native type' wat dit zou kunnen. De nullability van een reference type is een eigenschap van elk invidiueel reference type; over alle reference types die er zijn. Als je dit direct via types op zou willen lossen, moet je overal nieuwe types introduceren met backwards compatible breaking changes en mol je het hele ecosysteem.

In plaats daarvan heeft Microsoft het via type annotaties gedaan die enkel compile-time bestaan.
Dit geeft je compile-time safety en static code analysis tooling; zonder dat je de bestaande runtime aan hoeft te passen op een manier die niet langer binary compatible is.

[Reactie gewijzigd door R4gnax op 22 juli 2024 14:14]

[BugBoy]

Dat bedoelde ik nu juist met "waarin de leeftijd van .NET pijnlijk zichtbaar wordt". Bij Go bestaat het concept van binary compatbility niet eens, omdat je altijd alle sources hebt en alles van scratch compileert. Dat scheelt al een hele hoop ellende. Maar vanuit de oude closed-source gedacht (ten tijde van .NET Framework) was dit absoluut ondenkbaar.

[R4gnax]

Dat heeft niets te maken met 'de leeftijd die pijnlijk zichtbaar wordt' maar met het soort runtime. De .NET CLR draait bytecode die uiteindelijk weliswaar JIT gecompileerd wordt, maar dus al wel een transformatie-stap van source naar bytecode is ondergaan.

Alles in source downloaden en dan zelf moeten compilen is overigens ook niet zaligmakend.

[BugBoy]

Het is dat ze binary backwards-compatibility niet op willen geven. Dat kan je een tijdje volhouden, maar op een gegeven moment gaan keuzes in het verleden nawerken in het nu. De implementatie van non-nullable types is daar een voorbeeld van. Overigens is binary compatible ook lang niet altijd mogelijk in .NET, want zelfs in de runtime zijn er bij elke major versies breaking changes (zowel source als binary).

Als je altijd vanuit source compileert, dan breekt je soms code bij een major upgrade. Maar het concept binary compatible ben je wel kwijt. Compilatietijden bij Go zijn veel beter dan C# en de compiler compileert natuurlijk ook niet elke keer alles opnieuw. Alleen je eerste build is wat trager. Het enige nadeel is dat je code altijd openbaar is (vind ik een voordeel). Bij .NET moet je teruggrijpen op lastige obfuscation technieken als je het "geheim" wilt houden.

[Jim80]

Ik zit met hetzelfde dilemma.... .NET developer van het eerste uur (inderdaad zo'n 20 jaar). Type safety vind ik enorm belangrijk... liever compile errors/warnings dan runtime errors waar je uren op zit te zoeken.

Runtime snelheid valt goed mee, maar er is inderdaad een enorme overhead.... en het draait niet op een Raspberry pi zero (gelukkig wel op de grotere Rpi's).

Maar ik ben verslaafd aan features zoals "edit & continue (of hot reload)", generics, extension methods, uitgebreide libraries, .... Je hebt veel controle over Threads en andere OS functies waar een implementatie van is voor alle platformen. Ik heb een overdreven "Fear of other frameworks". Ik gebruik bijna nooit 3th party libraries zoals bijvoorbeeld Log4net. Het geeft extra afhankelijkheid als een library er ineens andere ideeën op nahoudt en vroeg of laat stuit je tegen een muur van dingen die niet kunnen. Bij elke nieuwe versie is het dan bidden dat alles nog werkt en er geen breaking changes zijn.

Zou ook graag overstappen naar iets lichtgewicht, ik ga in ieder geval Go en Rust nog eens nader bekijken. Maar dat je in .Net tijdens het debuggen code kan aanpassen terwijl je step into / step over aan het doen bent, is een feature die ik niet graag zou opgeven. Dit scheelt zoveel productiviteit in vergelijking met telkens een recompile/restart.

[BugBoy]

Log4NET zou ik sowieso al niet meer gebruiken in .NET Core. De logging extensions zijn heel wat beter. Juist zaken als logging, dependency injection, ... die in .NET Core zo ongeveer standaard zijn maken het een veel prettigere omgeving vergeleken met het traditionele .NET Framework.

Afhankelijkheid van 3rd party libraries is inderdaad altijd een ding. Ik heb een oplossing draaiend op Identity Server 4 en dit was end-of-life nog voordat onze software live ging. Zelf bouwen van zoiets is ook geen doen (deze is redelijk battle-tested), maar we moeten straks toch over naar iets anders. Overigens vind ik package management in .NET een drama als je redelijk wat projecten in je solution hebt. Wij gebruiken Paket en dat werkt heel aardig. Helaas lijkt dat onderhand ook dood te zijn (alhoewel het nog prima lijkt te werken met .NET 7). Wel dieptriest dat MS daar zelf geen fatsoenlijke oplossing voor heeft.

Aan de ene kant is VS 2022 een fijne programmeeromgeving, maar het is ook ontzettend bloated. Ontwikkelen in Go met VS Code is zoveel makkelijker. In Go zijn dingen lekker simpel opgelost en dat is een verademing. Zaken als JSON serialisatie is zo heerlijk in Go. Kom daar maar eens mee aan in .NET Core waar je moet strijden tussen Newtonsoft.JSON versus System.Text.Json. Zelfs MS zelf is niet altijd consistent daarin.

Kijk echt eens verder en dan zal je zien dat (delen van het) gras bij de buren echt groener zijn :-)

[StefanJanssen]

Aan de ene kant is VS 2022 een fijne programmeeromgeving,

Dat is echt iets wat ik nog geen enkele .NET developer heb horen zeggen. Ik heb game development, web development, en applicatie development gedaan binnen verschillende teams en keer op keer wordt Visual Studio aangegeven als een minpunt.
Jetbrains Rider is daar in tegen een geweldige IDE voor C#.

Zelf heb ik kort Go geprobeerd en dat viel bij mij niet in de smaak. Rust is wel iets wat ik graag zou willen leren, maar ik ben wel echt verwend door het .NET ecosysteem. Source Generators, alle debug tools en de vele type development waar C# toch een hoge plaats krijgt.

[Niemand_Anders]

Rider heeft alleen geen persistent multi-monitor support. Meerdere feature requests op Jetbrains forum staan al meer dan 10 jaar open...

Echter omdat VS2022 nu 64 bits is, heb ik geen crashes meer gehad met VS (met Reshaper plugin). Voorheen zat deze continue tegen de 3GB aan de schurken en bij een te grote background (re)build action heeft Roslyn teveel geheugen nodig en klapt gewoon VisualStudio...

VS2022 met mijn huidige solution is nu 7173.9MB groot. Snap wel dat VS hier in een 32 bits omgeving veel moeite mee had. Omdat VS2022 als nu als een zonnetje draait op mijn systeem, zal ik niet snel meer overstappen op een andere IDE zelfs niet als Rider nu wel ineens goede multi-monitor support zou krijgen.

[BugBoy]

Smaken verschillen, maar ik vind VS 2022 een prima IDE. Wellicht wat bloated, maar met een dikke PC is het prima te gebruiken. En Jetbrains Rider is inderdaad voor velen een prima alternatief. Wel bizar dat een Java oplossing sneller is dan wat MS zelf kan maken.

.NET source generators vind ik juist bijzonder onprettig werken. Vooral het feit dat source generators een netstandard2.0 moeten zijn (nog steeds?) is een draak als je de rest target op net6.0. Ik heb al de nodige uren verstookt om source-generators te debuggen (lastig) en weer werkend te maken. Go doet dat zoveel simpeler met "go generate" die eigenlijk gewoon een applicatie aanschopt. Voordeel is ook dat je code-generatie geen C# code hoeft te zijn. De eerste paar maanden vond ik Go ook niets, maar als je eenmaal de idiologie begint door te krijgen (KISS principe) dan ga je het meer waarderen. Waarbij ik echt niet wil zeggen dat Go geen flaws heeft. Sterker nog, de taal heeft er best veel.

Rust is een veel cleanere taal, maar door zijn memory-model vereist het een behoorlijk andere denkwijze. Ik heb er niet genoeg mee gedaan om er echt een oordeel over te kunnen vellen. Ik wil best geloven dat het voor mission-critical werk de beste taal is. Maar de productiviteit ligt wel lager dan bij C# of Go denk ik.

[StefanJanssen]

Wat ik van go generate begrijp is dat dit altijd een aparte stap is? Waar Source Generators als analyzer geladen wordt, wat er dus voor zorgt dat de code op de achtergrond incrementeel wordt gegenereerd.

[BugBoy]

Een "go build" doet inderdaad geen code-generatie. Daarvoor draai je eerst "go generate" en feitelijk trap je gewoon een executable af die de code voor je genereert. Lekker simpel en dat zou je theoretisch ook in een MSBuild stap kunnen doen. Nu is MSBuild niet het meest vriendelijke product, maar sinds .NET Core is het een stuk werkbaarder geworden.

Waar .NET source-generators tot hun recht komen vind ik als ze afhankelijk van je code, andere code moeten genereren. Daarom ook de sterke verbinding met code-analysis en zodoende kunnen zo zaken als JSON serialization, regular expressions, type mappers, ... versnellen. Maar voor eenvoudige zaken is het vaak nogal overkill en is het nodeloos complex.

Ik heb in het verleden ook nog die T4-templates gebruikt. Dat was pas echt een drama

[Reactie gewijzigd door BugBoy op 22 juli 2024 14:14]

[Rutix]

Ik hoor juist weer veel andersom dat juist Rider net niet is en dat VS2022 gewoon prima is . Ik zit zelf eerlijk gezegd ook in dat kamp. Ja soms is VS2022 wat bloated maar het word wel steeds modulairder.

[Yoshi]

bij deze dan de eerste keer, ik vind het ook een fijne programmeeromgeving

[mrbullet]

Maar dat je in .Net tijdens het debuggen code kan aanpassen terwijl je step into / step over aan het doen bent, is een feature die ik niet graag zou opgeven. Dit scheelt zoveel productiviteit in vergelijking met telkens een recompile/restart.

Als je dit idd eenmaal gewend bent, lijkt alles die dit niet kan een stap terug.

[DJBnJack]

Zeker waar, lijkt me ook niet de beste match om .NET of andere high-level talen te gebruiken voor IoT en low-power devices.

Ik schrijf nagenoeg alleen server applicaties en daar is het een goede match. Al het andere doe ik natuurlijk in Javascript

[Nark0tiX]

Ik ben al jaren .NET developer. Maar gebruik ook regelmatig, GO, rust of c++.

Maar voor web/enterprise apps gaat er echt niks boven .NET.

Go / rust zijn leuk voor wat meer lowlevel zaken. Zoals een audiomixer.

Met AOT wordt het compile al een heel ander verhaal, al zitten er nu nog beperkingen in qua reflection en werkt het nog alleen voor console apps dacht ik?

[Reactie gewijzigd door Nark0tiX op 22 juli 2024 14:14]

[Caelorum]

Sinds 2.1

[GrooV]

Zeker wel, met self contained publish dan zit de benodigde runtime er bij, zie https://learn.microsoft.c...g/#publish-self-contained

[Reactie gewijzigd door GrooV op 22 juli 2024 14:14]

[3raser]

Dat wist ik niet. Bedankt!
Dit heeft uiteraard zo zijn voor- en nadelen maar het klinkt als een prima manier om zonder gezeur met .NET versies/installaties een applicatie uit te geven.

[xFeverr]

Je installaties worden groter want je sjouwt de runtime natuurlijk mee. Dus daar is het vooral om te doen. Als je weet dat je target machine de runtime heeft, zijn de installaties een stuk kleiner.

[Mellow Jack]

Zeker z'n nadelen maar in feite doen ze het allemaal, python, java en javascript. Vanuit de IT operatie vreselijk irritant, vooral tijdens het patchen van kwetsbaarheden. Voor IT devs wel fijn dat je geen klanten hebt die op Orable java runtime draaien terwijl jij zelf die van Amazon gebruikt

[wiseger]

Amazon Java? Ik denk dat je gewoon OpenJDK bedoelt. Dat is open source.

[Mellow Jack]

https://en.m.wikipedia.org/wiki/OpenJDK

Een OpenJDK distributie is niet perse gewoon OpenJDK. Ze (de grote) doen dit natuurlijk niet zomaar.

In dit lijstje is d'r maar 1 met een unmodified build

[Reactie gewijzigd door Mellow Jack op 22 juli 2024 14:14]

[Saven]

Dat gehannes met name changing helpt ook niet echt mee... .NET Framework, .NET Core, en .NET. Zelfs developers zijn de laatste jaren een beetje het spoor bijster geraakt. Probeer maar eens een oplossing te googelen voor jouw versie, lekker inconsistent allemaal

[Reactie gewijzigd door Saven op 22 juli 2024 14:14]

[StefanJanssen]

Als je een .NET developer bent is het allemaal best duidelijk. Het is altijd .NET Framework geweest, toen heeft MS een roadmap uitgebracht waarin stond dat de eerste paar jaar .NET Framework en .NET Core naast elkaar zouden bestaan maar uiteindelijk samengevoegd zou worden tot één .NET.
Daarnaast zijn de versie nummers bewust zo gekozen dat ze niet tot verwarring zouden kunnen leiden.
Framework 4.x is in 2010 uitgekomen. Projecten met versies lager dan 4.0 kom je eigenlijk nergens meer tegen.
.NET Core heeft versies 1.x, 2.x en 3.x gekregen
.NET heeft versie 5.x, 6.x, 7.x, 8.x, 9.x etc gekregen.

Oftewel:
versie < 4 => .NET Core
versie = 4 => .NET Framework
versie > 4 => .NET

[farlane]

Uhuh, behalve dan als je ook de verschillende UI kits er bij pakt. Oh en .NET standard, wat was dat ook alweer... oh en .NET op Azure...

Nee, zo overzichtelijk is het echt niet wat mij betreft.

[Sito]

Inderdaad. Door de woordkeuze ("Microsoft probeert..") lijkt het erop alsof cross-playform applicaties nog niet kunnen. Maar dat is al geruime tijd mogelijk.

[jorisvergeerTBA]

En zo zie je toch de mening van de auteur over Microsoft terugkomen in het artikel.

Je kon ook schrijven dat met net 7.0 weer meer platformen geïntegreerd zijn.

[rko4u]

Het is inderdaad gewoon het voortzetten van netcore en .NET 5.0. jammer dat tweakers geen kenner beschikbaar had om een serieus artikel te plaatsen.

[TechSupreme]

Niet te spreken over mono (en later uno) waarmee het al langer mogelijk is om .NET project te ontwikkelen voor Linux/Mac en MonoTouch voor iOS en Android.

[Reactie gewijzigd door TechSupreme op 22 juli 2024 14:14]

[novasurp]

Wat is nou het voordeel hiervan vergelijken met de JVM, die meer vendors dan alleen Microsoft heeft en ook op BSD en zo werkt?

[Ryen]

Beetje kort door de bocht gezegd:
.Net genereert native code. JVM is een interpreter voor intermediate code.

[breezie]

.NET genereert toch net zoals Java intermediate code? Waarvoor dient de runtime anders?

[ariadeno]

Sorry hoor, maar dit klopt dus niet. Het .NET equivalent van de JVM (Java Virtual Machine) is CLR (Common Language Runtime). C#, F# en dergelijke worden gecompileerd naar IL (Intermediate Language, dus inderdaad het .NET equivalent van Java bytecode) en dat is NIET native. Er zitten hier en daar wel wat slimme trucjes om IL beter te interpreteren middels JIT maar dat betekent niet dat dit niet geïnterpreteerd is.

Met NativeAOT kun je in .NET 7 trouwens wel native code compileren maar dan kun je niet gebruik maken van alle features die je gewend bent van .NET zoals dynamic loading en runtime generation.

[breezie]

Zo dacht ik dus ook dat het zat maar jouw antwoord is in ieder geval beter beter geformuleerd met de correcte termen...

[Caelorum]

f# is wat vreemd in deze overigens, want die kan je ook naar javascript en python laten "compileren".

[beany]

Je kan C# ook naar javascript of python laten compileren. Sterker nog, alle .Net talen (die uiteindelijk naar 1 IL gecompileerd worden) kan je, via de IL dus, naar JS of PY laten compileren.

[Caelorum]

Fable compileert niet eerst naar IL. Ze pakken de AST die de f# compiler genereert en zetten die om in een formaat die Babel snapt. Calls die naar de BCL gaan worden ook omgezet in calls die "kloppen" in de target. Via die weg kan Fable dus ook f# omzetten in js, dart, php, python of rust.
Dat is mede waarom je bijv. ook rechtstreeks javascript libraries kan aanroepen in F# en andersom.

[Reactie gewijzigd door Caelorum op 22 juli 2024 14:14]

[beany]

Er zijn ook nog andere tools dan Fable, die op basis van IL naar javascript of iets anders compileren.

Fable kende ik overigens nog niet...

[Caelorum]

Oh zeker, maar mijn initiële reactie was juist met fabel in het achterhoofd

[ariadeno]

Waar heb je het over? F# is helemaal niet "vreemd" bij deze. F# is een first class citizen in de wereld van .NET. Dat is een CLI taal bedacht en onderhouden door Microsoft zelf (net zoals C# en Visual Basic) met als primaire doel het .NET framework te voorzien van een functionele programmeertaal. Het "compileren naar JavaScript" is een speciaaltje, niet andersom.

[Caelorum]

Vreemd in de zin dat het dus niet op een virtual machine hoeft te draaien. Er is namelijk een prima compiler die f# code naar rust, js, python of nog een aantal andere omgevingen kan compileren.
Het compileren naar Javascript is in het geval van f# zeker niet een "speciaaltje". Het is wat F# van de ondergang heeft gered en was een lange tijd zowat het enige waarvoor mensen het nog gebruikten. Dat het nu weer is aangetrokken en er nu eindelijk sinds een maand of twee weer een team van 7 FTE aan f# werkt vanuit Microsoft is een unicum, want lange tijd was het de community zelf die het onderhield en niet Microsoft.

[Reactie gewijzigd door Caelorum op 22 juli 2024 14:14]

[R4gnax]

Er zitten hier en daar wel wat slimme trucjes om IL beter te interpreteren middels JIT maar dat betekent niet dat dit niet geïnterpreteerd is.

De .NET runtime compileert IL just-in-time naar native code en voert dat uit. Het is geen interpreter.
De IL wordt daarnaast gebruikt om iteratief te hercompileren en er wordt runtime sample analyse gedaan om te bepalen welke optimalisaties wel/niet toegepast moeten blijven.
En de IL wordt gebruikt om zaken zoals type reflection te faciliteren, uiteraard.

Ahead-of-time native compileren vervroegt die JIT compilatie en maakt deze eenmalig, zodat er een daadwerkelijk native binary geproduceerd wordt. Maar die kan dan inderdaad geen gebruik meer maken van features zoals dynamic type loading; en er kan geen runtime sampling toegepast worden om te kijken welke optimalisaties in welke gevallen beter werken dan anderen. Dus het betekent niet dat per definitie je code ineens beter performt.

[Reactie gewijzigd door R4gnax op 22 juli 2024 14:14]

[breezie]

Dit snap ik toch niet helemaal hoor.
.NET genereert binaries in een intemediate language. Daarom dat je ze ook kan decompileren met tools zoals dotPeek en dnSpy.
Dat de runtime zelf native is lijkt me vanzelfsprekend. De java runtime is dat ook.

[air2]

Uhm, nee de compiler genereerd geen native code, maar het framework kan dat wel. Dus de intermediate code kan alvast van te voren omgezet worden in native code door het framework. Maar je blijft het framework nodig hebben voor de native code.

[Stukfruit]

.NET is het framework, de compiler genereert inderdaad Intermediate Language. Maar dat is tegenwoordig ook een grijze middenweg, gezien de introductie van de AOT (Ahead of Time) compiler en trimming, wat sinds 6 en 7 steeds beter en breder inzetbaar begint te worden:

https://learn.microsoft.c...ore/deploying/native-aot/

[air2]

Inderdaad

[n00bje]

Zowel .NET als Java worden gecompileerd naar een tussentaal (CIL en Java Bytecode) die heel erg op assembly lijkt en vervolgens gecompileerd wordt door de runtime naar native code.
Voor .NET bestaat er wel Native AOT om van te voren te compileren naar native code, maar dat is met héél veel limitaties.

[geoffrey.vl]

Dat kon Mono heel wat jaren terug ook al. MS heeft dit framework mooi overgenomen en langs de kant geparkeerd. Heel het .Net Core/Mono gedoe... Ik begrijp dat ontwikkelaars hier wild van worden want je kan ineens echt andere platformen benaderen (zoals elke andere hippe taal al een decennium kan), maar als je echt gaat graven in de historiek heeft dit toch allemaal een wrang gevoel. Voor een taal die 20 jaar bestaat is het best wel teleurstellend om te zien dat ze (de inkomsten van) cross-platform in zekere mate sinds enkele jaren pas serieus nemen. Als ontwikkelaar ben je met handen en voeten gebonden bent aan hoe MS het ziet, wat voor hen de goed is.

[psychicist]

Eigenlijk niets, zeker nu je via GraalVM ook native binaries kunt compileren. Er zitten juist meer nadelen aan, zoals het weigeren van ondersteuning van Linux op hetzelfde niveau als Windows. Daarom laten veel ontwikkelaars het links liggen ten faveure van echte multiplatform oplossingen.

[EraYaN]

zoals het weigeren van ondersteuning van Linux op hetzelfde niveau als Windows.

Ik denk dat je een aantal jaar achterloopt. Het hele idee is sinds .NET Core dat alles in de frameworks cross platform is.

[psychicist]

Er is een groot verschil tussen denken en weten.

[EraYaN]

Dat is dan wel gewoon alleen over MAUI wat voor de meeste (server-side) .NET code niet belangrijk is. En de C# code is gaming gebruikt een andere runtime dus is ook een non-issue. De framework en CLR zelf (waar MAUI dus niet echt een onderdeel van uit maakt net zoals WinForms ook een los onderdeel was in de oude framework versies) is perfect cross-platform tussen een stuk meer dan alleen Windows en Linux.

MAUI was nog geen eens echt bruikbaar dus het is niet alsof er veel beslissingen voor de tech stack gemaakt zijn voor desktop applicaties in de laatste paar dagen.

[psychicist]

Voor degenen die wel gebruik willen maken van MAUI, is het wel een probeem. En het is zelfs zo'n ernstig probleem dat ze op zoek gaan naar andere stacks en zelfs afscheid nemen van .NET, vooral omdat het muisstil blijft vanuit Microsoft.

Op zo'n bedrijf zou ik niet willen vertrouwen voor echte cross-platform ontwikkeling, wat inderdaad meer inhoudt dan alleen ondersteuning voor Windows en slechts basale ondersteuning voor Linux, omdat dat tegenwoordig moet.

[Reactie gewijzigd door psychicist op 22 juli 2024 14:14]

[EraYaN]

Ik denk dat het gewoon geen echte prioriteit krijgt omdat het zo'n kleine groep is. Ik bedoel desktop Linux is wel een subset van een subset tegenwoordig. En UI werkend krijgen is erg veel werk. Dus ik vrees dat het niet eens perse aan "Microsoft bad" ligt maar gewoon puur een afweging geweest is van ROI. Het zal vast een keer komen (en iemand mag het natuurlijk bijdragen als ze willen, OSS enzo) maar het kan even duren.

[marcmiddendorp]

Ik denk in eerste instantie de snelheid...

[Luuk2015]

Heel vroeger was Java een stuk langzamer, tegenwoordig is dat vergeleken met C# toch verwaarloosbaar?

[StefanJanssen]

Met hoeveel sneller C# is geworden in de afgelopen 3 jaar heb ik het idee dat het tegenwoordig niet meer te verwaarlozen is. Ik heb hier geen cijfers voor, maar als ik puur naar de performance ten opzichte van de vorige versie ga kijken zijn die verschillen aan de .NET kant toch significanter, al weet ik niet wat de baseline was.

[SibboNL]

Vnl: Het is geen virtuele machine. Het is native code. Hierdoor is het een stuk lichter en dus sneller. Ook hoef je dus minder troep te installeren als eindgebruiker.

Daarnaast is de ontwikkelomgeving en de programmeertaal een stuk verder ontwikkeld.

[Stukfruit]

Van een link uit de release notes:
https://devblogs.microsof...pport-for-the-dotnet-sdk/

"We have focused on the Linux-x64 image deployment scenario for this initial release. Windows images and other architectures are key scenarios we plan to support for the full release, so watch out for new developments there."

Wel leuk om te zien dat men nu eindelijk vaker ontwikkelt op basis van hoe logisch en nuttig het is ipv alles geforceerd en voornamelijk te baseren op producten van Microsoft zelf.

Ze zijn ver gekomen sinds de uitspraak "Linux is a cancer that attaches itself in an intellectual property sense to everything it touches" van Steve Ballmer in 2001. Ik durf nu eindelijk zonder schaamte te zeggen dat .NET en alles eromheen (de taal, de losse projecten, enz) echt een heel mooi framework vind.

Het mag best wel eens gezegd worden dat ze tegenwoordig, op wat kleine valkuilen van managers met rare ideeën na, goed bezig zijn

[machiel]

Balmer was echt een man van voorbije glorie van Microsoft. Windows zo groot mogelijk maken en op basis daarvan andere diensten en producten slijten was extreem succesvol maar uiteindelijk toch niet houdbaar. De totale omslag van het omarmen van open source en (cloud)-diensten aanbieden die helemaal geen Windows nodig hebben is iets dat MS nu goed doet.

[Slashdotter]

https://www.dotnetconf.net/
NET Conf is our annual virtual developer event co-organized by the .NET community and Microsoft and sponsored by the .NET Foundation and ecosystem partners. It is a chance to learn and get inspired for your next software project. You will learn to build for web, mobile, cloud, desktop, games, services, libraries and more for a variety of platforms and devices all with .NET. We have sessions for everyone, no matter if you are just beginning or are a seasoned engineer. We’ll have presentations on .NET 7, C# 11, Azure, Visual Studio, and much more.

Youtube: .NET Conf 2022 - Day 1

[xFeverr]

Mooi, wij hebben .NET 7 vanmorgen op de backlog gezet en verwachten dat we dit jaar nog productie gaan draaien met .NET 7. Er zijn weer flinke performanceverbeteringen te vinden in deze nieuwe release voor .NET, ASP.NET Core en Entity Framework en daar willen we natuurlijk zo snel mogelijk van kunnen genieten.

En natuurlijk C# 11. Stiekem vind ik de Raw string literals toch wel de leukste nieuwe feature. Het is zo simpel en klein, maar het gaat in onze codebase wel helpen met sommige zaken.

[R4gnax]

En natuurlijk C# 11. Stiekem vind ik de Raw string literals toch wel de leukste nieuwe feature. Het is zo simpel en klein, maar het gaat in onze codebase wel helpen met sommige zaken.

Het is inderdaad een fijnere manier om bijv. lange exception messages mee vorm te geven in code. Alleen jammer dat je in zo'n geval de carriage returns ook meteen er in hebt zitten, wat je dan eigenlijk weer niet wilt. Over dat soort scenario's is dan weer net niet goed genoeg nagedacht.

Feature waar ik persoonlijk echt naar uitkeek is static interface members; waarmee je kunt kijken of een type aan een interface voldoet ipv of instances van een type aan een interface voldoen. Kun je leuk spul mee doen zoals bijv. een JsonConverter<T> where T:IParseable<T> die automatisch de TryParse static method kan aanroepen op elk type wat deze implementeert.

Benieuwd of die het gehaald heeft, of nog steeds in preview zit...

[xFeverr]

Ik wordt bijvoorbeeld gek van SQL statements waarbij de dubbele quote ge-escaped moet worden. In een verbatim string met dubbele dubbele quotes (ja, lees je goed) of met een \". Ziet er niet uit.

Nu kun je eindelijk zoveel dubbele quotes achter elkaar gebruiken als je wil, als je string maar begint en eindigt met het aantal dubbele quotes achter elkaar gebruikt + 1.

var string = """""""Dus zelfs """"""dit"""""" gaat gewoon goed"""""""
Tuurlijk, een belachelijk voorbeeld. Maar het is wel grappig gedaan.

(waarom werken [code] tags nog niet op de frontpage )

[Reactie gewijzigd door xFeverr op 22 juli 2024 14:14]

[R4gnax]

Inderdaad; voor embedded language snippits zijn raw literals wel verdomd handig.
En ja; dat met die code tags is irritant. Was er zelf ook bijna (weer) ingetrapt.

[Reactie gewijzigd door R4gnax op 22 juli 2024 14:14]

[Jogai]

Ik heb twee weken geleden een beta uitgerold van mijn 'sideproject'. Daar zit nog een onhandigheid in ivm relaties (dit maakt het makkelijk denk ik), dus ik heb hem ook op de backlog gezet, maar ik denk dat ik hem vanavond oppak ;-)

[SuperDre]

.NET 7 is dan eindelijk zover dat je fatsoenlijk multiplatform kunt gaan zonder dat je nog rekening hoeft te houden met bepaalde onderdelen. Keek hier al heel lang naar uit.

[Mushroomician]

"3e poging", "proberen", "eerder niet gelukt".
Het artikel staat vol met implicaties naar falen, maar in werkelijkheid is de transitie een proces wat in fasen gebeurd. En dat is niet gek, integendeel, zeer knap gedaan. Maar dat besef je waarschijnlijk alleen als je zelf developer bent over al deze versies.

[DnJealt]

Daarmee lijkt het erop alsof alle code van .NET die eerst in Core, Framework, Xamarin en Mono zat, definitief is overgeheveld naar de enkele codebase van .NET 7.0

Betekend dit dat we nu éindelijk WCF op een fatsoenlijke manier kunnen gebruiken in netcore?

[boxit]

WCF client side werd al ondersteund door .NET Core, maar voor de service side blijf je afhankelijk van CoreWCF.

[YGDRASSIL]

WCF is al lang officieel afgeschreven. Microsofts opvolger is gRPC support. Zie ook https://learn.microsoft.c...r-wcf-developers/why-grpc en andere artikelen.

Alleen is dat flinke overkill voor RPC calls op dezelfde machine (waar ik WCF voornamelijk voor gebruikte). Overgestapt op nuget package ServiceWire voor RPC calls....

Zie dat CoreWCF sinds kort eindelijk 1.0 heeft bereikt, maar wel paar jaar te laat voor mij ;-)

[Skating_vince]

Hopelijk hebben ze in deze versie ook weer voor alles een ModelFactory. De nieuwe ARM Nuget is op dit moment onmogelijk te mocken (doorspekt met delegates, extention methods en properties zonder setter). Staat al ruim een jaar een ticket voor open, maar er gebeurt weinig...

[TheNooz]

Is de huidige implementatie van MAUI wel gebaseerd op de huidige .NET runtime? Ik meende dat tijdens een livestream nog door het MAUI team benoemd werd dat ze voor nu nog MAUI draaien op de Mono runtime omdat historisch gezien Xamarin dat ook deed.

[Mayonaise]

Ja, dat vraag ik me ook af.

Laatste keer dat ik MAUI bekeek, leek het wel heel fel op Xamarin.
Hoe fel is de architectuur verandert? Want ik was absoluut geen fan de MVVM van Xamarin.

[Reactie gewijzigd door Mayonaise op 22 juli 2024 14:14]