Microsoft maakt .NET 5.0 beschikbaar

Microsoft heeft zijn .NET 5.0-ontwikkelplatform geïntroduceerd, samen met ASP.NET Core, EF Core, C# 9.0 en F# 5.0. Microsoft noemt de release belangrijk in zijn streven om de verschillende .NET-versies samen te voegen.

Microsoft heeft .NET 5.0, per direct beschikbaar gemaakt voor Windows, macOS en Linux, en voor x86, x64, ARM32 en ARM64. Het ontwikkelplatform bevat ondersteuning voor C# 9.0 en F# 5.0. ASP.NET Core 5.0.0 is aanwezig en de release valt samen met die van EF Core 5.0, oftewel Entity Framework Core 5.0. Visual Studio-gebruikers dienen versie 16.8 op Windows te draaien om .NET 5.0 te kunnen gebruiken. Voor macOS is de laatste versie van Visual Studio for Mac vereist.

Microsoft noemt versie 5.0 de eerste release op weg naar samenvoeging van de verschillende platformen. Versie 5.0 zou het makkelijker maken voor ontwikkelaars hun .NET Framework-code en -apps naar de nieuwe versie te migreren. Bovendien heeft Microsoft voorbereidingen getroffen zodat ontwikkelaars die van cross-platformsoftware Xamarin gebruikmaken vanaf .NET 6.0 van een samengevoegd .NET-platform gebruik kunnen maken.

Die release van .NET 6.0 moet volgend jaar november plaatsvinden. Microsoft kondigde .NET 5.0 vorig jaar mei aan en maakte toen al de strategie voor een samengevoegd platform voor desktop, het web, mobile en internet-of-things bekend. Het bedrijf zei destijds dat vanaf november dit jaar een jaarlijkse upgradecyclus toegepast zou worden.

Bij .NET 5.0 zijn diverse verbeteringen en wijzigingen aangebracht. Naast de ondersteuning voor C# 9.0 en F# 5.0 is er ondersteuning voor WebAssembly met de Mono-runtime en .NET Libraries. Ook zijn de prestaties bij de .NET Libraries, garbage collection en de jit verbeterd. Versie 5.0 is de opvolger van .NET Core 3. Een 4.0-versie verscheen nooit vanwege mogelijke verwarring met .NET Framework 4.

Reacties (99)

[labee]

Een hoop nieuwe dingen (Blazor en gRPC over http/2) die nog flink moeten landen in de enterprise wereld. Maar daar hebben we een heel jaar voor, voordat .NET 6 er is.
(.net6 = LTS (long time support))

.NET 5.
--> Geen WebForms meer (toch nog vaak gebruikt voor interne web applicaties)
--> Geen WCF
--> Max 128 bits encryptie ipv 256 in framework.


Straks weer verder met dag 2 van de dot NET Conference:
https://www.dotnetconf.net/
(gratis en digitaal)

[BugBoy]

Dat Blazor zie ik toch wel een beetje als de zoveelste (kansloze???) missie van Microsoft om een web-based framework neer te zetten. Ik begrijp best dat je graag dezelfde taal/omgeving wilt gebruiken, maar voorlopig durf ik het echt niet aan om Blazor in te zetten. Wij houden het gewoon bij Angular (en anders React) voor client-side webontwikkeling.

Ik ben wel blij dat WCF langzaam gaat verdwijnen. Voor het porteren van applicaties inderdaad lastig, maar WCF is in de praktijk toch vaak wel een beetje ellende. Theoretisch gezien allemaal mooi abstract, maar in de praktijk gebruikt vrijwel iedereen NET.TCP voor bi-directionele communicatie en dan is het wel een configuratie-hel. Voor een REST-based API gebruik ik al jaren geen WCF meer.

Als je nu nog applicaties hebt met WebForms, dan zijn die vaak al heel erg oud en eigenlijk aan vervanging toe. Maar voor interne applicaties ligt dat altijd wat lastig. Zo hebben wij nog ergens een applicatie draaien met ActiveX componenten voor onze productie-tooling.

Ik vind de conferentie overigens bijzonder rommelig en onoverzichtelijk. Ook mogen de presentaties wel iets professioneler. Geef die mensen i.i.g. een goede microfoon.

[Ablaze]

Blazor is een SPA frontend in wasm, met automatische data en event binding in SignalR.
Hoeveel concurrentie heeft dat? Ik denk niet dat het kansloos is.

Het is echt een verademing om front end dezelfde taal te gebruiken als in de backend, met volwaardige debugging van de frontend vanuit een IDE, en niet om dagen kwijt te zijn alleen om data van voor naar achter en terug te krijgen.

[BugBoy]

Daarom ook mijn kansloos met vele vraagtekens. Ik zie absoluut de voordelen van C# op de front-end tijdens het ontwikkelproces. Wil je full-stack (web, mobile en back-end) dan heb je anders Javascript (web), Swift (iOS), Kotlin (Android) en Java/C# (back-end). Door dat te consolideren naar één enkel framework heeft absoluut voordelen tijdens het ontwikkelproces.

Wij werken nu met Angular en ik zie hoe onze ontwikkelaars er mee worstelen. Data binding doen alle fatsoenlijke client-side frameworks en SignalR kan je in veel gevallen vervangen door SSE (server-side events). Het voordeel is dat je dan wel helemaal los bent van de grillen van Microsoft.

Voor mobile hebben we wel gekozen voor Xamarin, omdat we er anders nog weer meer talen bij zouden krijgen. Maar Xamarin heeft erg veel issues (vooral Xamarin Forms is een drama). Ook de ontwikkel-ervaring is matig (vanuit VS 2019). Werk je met Rider of VS for Mac op een Mac dan is het al wat beter. Bij elke update is niet de vraag of er wat omvalt, maar wat er omvalt.

Ik weet niet hoe stabiel Blazor is, maar als het net zo grillig is als Xamarin dan sla ik even over...

[Ablaze]

Blazor is stabiel, maar niet voor elke toepassing geschikt.

Server side Blazor is minder geschikt wanneer de server en gebruiker zich op grote afstand bevinden, wanneer de webapplicatie drukbezocht wordt (meer geheugengebruik doordat de UI states server side zijn), wanneer je grote datasets gaat oversturen en wanneer je een load balancer gebruikt die geen sticky sessions aankan. Server side Blazor kan niet offline werken.
Eigenlijk dus vooral geschikt voor businesstoepassingen en lokale websites.

Client side Blazor is minder geschikt voor trage internetverbindingen (de payload is relatief groot, hoewel deze elke versie kleiner wordt) en kan trager zijn dat JS toepassingen, afhankelijk van de gebruikte libraries en de wasm implementatie in je browser. Client side Blazor is pas officieel beschikbaar vanaf deze versie.

Client side Blazor is geschikt voor PWA's, maar als je ook direct naar een (Android/iOS/Windows/Linux) app wilt compileren op basis van dezelfde code, kun je wellicht beter Uno gebruiken.

Hier een verzamelsite voor Blazor: https://github.com/AdrienTorris/awesome-blazor

[Reactie gewijzigd door Ablaze op 23 juli 2024 03:01]

[Sander Roest]

Over Xamarin.Forms kan ik meepraten, dat is niet het meest developer friendly platform dat er is. Flutter is wat dat betreft een verademing. Wat een heerlijk platform om mee te werken. Uiteraard moet je durven te investeren in (weer) een nieuw platform, maar ik kijk niet meer achterom

[jimshatt]

Behalve SSE vs SignalR kun je ook 'gewoon' WebSockets gebruiken. SignalR is leuk als je all-in op Microsoft bent, maar WebSockets zijn ook redelijk simpel dus waarom zou je?

Persoonlijk scheid ik FE en BE zoveel mogelijk qua paradigma zodat het duidelijk is waar wat geïmplementeerd moet worden (separation of concerns en zo). Dus ik ben niet zo'n fan van alles doen in een platform to rule them all, en met een soort hybride blob te eindigen die half op de FE en half op de BE draait, maar niemand weet het echt meer (bij wijze van spreken). Misschien vind Microsoft het leuk om te roepen dat je je hoofdje daar niet over hoeft te breken maar daar ben ik teveel een control freak voor.

Microsoft mikt altijd op het platform, en dat is ook logisch vanuit een bedrijfsperspectief. Ik doe liever best-of-breed.

[Kewne]

"Max 128 bits encryptie ipv 256 in framework."

Nou nee, Rijndael ondersteunt geen 192/256-bit blocks meer, en dat was het dan ook. Rijndael hoor je al vele jaren niet meer op zichzelf te gebruiken, alleen als onderdeel van AES, welke altijd gebruik maakte van 128-bit block size Rijndael (ook AES-256). Genoeg info en workarounds in de issue, mocht je hier ooit last van hebben. Verder is het allemaal gewoon on-par.

Het is jammer dat het 1e antwoord voor encryptie op StackOverflow hier gebruik van heeft gemaakt, maar dit is al vele jaren lang iets dat niet in de meeste crypto libraries zit, welke .NET 5/Core nu gebruikt in plaats van het zelf te doen.

[Ablaze]

Waarom hoor je Rijndael niet op zichzelf te gebruiken?
Ik gebruik het regelmatig voor symmetrische encryptie van bestanden. Voor zover ik weet is het hetzelfde als AES, als je geen rare instellingen kiest.

[Kewne]

Rijndael met een bepaalde subset van parameters is inderdaad gewoon AES, maar het is al een jaar of 10 een rare keuze om het dan niet gewoon AES te noemen en de AES APIs te gebruiken. De parameters die ze met de definitieve AES spec eruit gehaald hebben zijn verder bijna nergens serieus bestudeerd of geïmplementeerd dus je voorkomt daarmee een boel verwarring. Ook is de kans een stuk groter dat ze Rijndael support er in de toekomst weer uithalen (was in .NET Core 1.0 al eruit, in 2.0 hebben ze de minimale wrapper rond AES terug gezet).

[MeMoRy]

En op YouTube, e.g. https://youtu.be/mS6ykjdOVRg

[amoi]

@BikkelZ Ik sluit me bij het andere commentaar aan, daarom ben ik al sinds mei 2019 enthousiast over waar microsoft dit naartoe brengt. Dus eigenlijk is je irritatie punt al sinds vorig jaar al weg genomen.

https://devblogs.microsoft.com/dotnet/introducing-net-5/
Dat artikel legt heel duidelijk jouw wens uit.

[Reactie gewijzigd door amoi op 23 juli 2024 03:01]

[Hoover]

Ben nog steeds benieuwd hoe Microsoft het ziet om WCF services te vervangen met asp.net Core icm gRPC. Zowel Azure als IIS ondersteunt dit niet door issues met http.sys.
Gaan ze met .NET 6, dan dit 1 op 1 overnemen uit .Net 4.0 of is het over en uit met WCF en moet men blijven hangen op .NET 4.0.

OA Biztalk server host zijn WCF/SOAP services via IIS en is toch wel een veel gebruikt product in de enterprise omgeving. Zal hier nog wel een nieuwe versie van uit komen of gaan ze daar WCF er compleet uit slopen en dumpen ze de oude interfaces compleet. Nu zullen veel mensen zeggen, stap over naar REST/Odata, maar veel bedrijven hebben de afgelopen jaren in SOAP geïnvesteerd met hun integraties en gaan echt niet weer alles ombouwen.

Ik werk nu bijna 10 jaar in de integratiewereld bij verschillende bedrijven en het gross van de integraties die gemaakt worden is oldschool filebased of WCF/SOAP als het om webservices gaat. Zeker bij de wat grotere en oudere bedrijven.

PS het gaat niet om het consumen van services maar het exposen ervan.

[Reactie gewijzigd door Hoover op 23 juli 2024 03:01]

[MneoreJ]

.NET Framework gaat gewoon nog jaren ondersteund worden, en voor dit soort enterprisey dingen waarschijnlijk net zolang als er nog een significante user base is. Er is ook absoluut geen dwingende reden om te upgraden, aangezien .NET 5+ de oudere versies niet vervangt.

Dit is op zich natuurlijk ook gewoon een (klein) gaatje in de markt waar MS niet per se zelf op hoeft in te springen. Die WCF/SOAP spullen kunnen gewoon een nieuwe implementatie krijgen die op .NET 5 draait, MS hoeft dat niet zelf te bouwen. Eigenlijk is het enige scenario dat ik daarvoor kan bedenken profiteren van de perf verbeteringen in de nieuwe .NET of ontwikkelaars die klagen dat ze niet meer het nieuwste van het nieuwste kunnen gebruiken op taal/libraryniveau -- als je daar al een probleem mee hebt kun je waarschijnlijk ook wel iets geheel nieuws (laten) bouwen, en zo niet blijf je gewoon bij het oude.

[Hoover]

Dat is het punt. Microsoft zelf heeft aangegeven dit niet te porten naar hogere versies. Dus zal het het waarschijnlijk blijven hangenop .NET 4.0. Dat .NET 4.0 framework langer ondersteunt word snap ik, maar dit heeft uiteindelijk concequenties voor de lifecycle van BizTalk zelf.

Gaan ze nog hetwel upgraden of bloed het dood en draaien de enterprises over 15 jaar nog steeds op oude meuk. Voor een product met vrijwel alleen een enterprise userbase waar bedragen vaak in de miljoenen lopen, is dit nogal een rare keuze. De kracht van dit product is namelijk dat je alles met alles kunt laten praten, hoe oud of nieuw het protocol ook is. Juist zodat oude systemen gevoed en uitgelezen kunnen worden door nieuwe systemen, ongeacht het protocol.
Wellicht dat iemand het port of op een andere manier implementeert , maar ik zie dat niet gebeuren.

[MneoreJ]

Kijk als de markt hard genoeg schreeuwt en er genoeg geld in gepompt wordt komt er echt ook wel weer een divisie binnen MS zelf die de spullen alsnog port/opnieuw implementeert. De focus ligt nu op de open source/multiplatform development, maar dat zijn natuurlijk niet alle devs binnen MS. Als het core team zegt "gaan wij niet porten, geen zin in" is dat absoluut geen harde stelling waar ze niet meer op terug kunnen. Zou niet de eerste keer zijn dat ze teruggekomen zijn op een strategische beslissing die initieel in steen gebeiteld leek maar plotseling toch onderhandelbaar was ("we doen geen OLE DB meer en gaan alleen nog maar ODBC doen").

En voor WCF worden nu ook de stukken opnieuw geport voor in ieder geval consumptie van services, los van de core libs zelf, dus ik zie niet in waarom dat niet ook kan voor de tooling aan de producerende kant. Heb je dit in een middagje gedaan, nee natuurlijk, maar zie de eerdere opmerking over genoeg geld.

[Hoover]

Die tooling is er in de vorm van gRPC. Staat ook bij de aankondiging, maar die worden in Microsofts eigen azure en IIS platformen niet ondersteunt waardoor dat eigenlijk geen oplossing is.

Wellicht dat ze gRPC goed werkend krijgen in IIS/Azure. Er zijn al wat projectjes daar mee bezig.
Maar of dat ondersteuning gaat krijgen vanuit het BizTalk development team zelf... betwijfel het.
Die hebben ooit de fout gemaakt om de Newtonsoft JSON package te forken om JSON berichten in BizTalk te kunnen verwerken en tot op heden is de implementatie ervan nog steeds niet goed.

[MneoreJ]

Ik heb het specifiek niet over een gRPC implementatie maar over iets dat gewoon ouderwets SOAP over HTTP(s) (blijft) spreken, in combinatie met IIS (dat voor zover ik weet nog niet afgeschreven is), m.a.w. iets dat zo drop-in compatibel mogelijk is maar wel het gebruik van .NET 5+ mogelijk maakt voor andere doeleinden. Dit is iets wat de core devs expliciet niet willen bouwen (en ik geef ze absoluut geen ongelijk ) maar wel iets waar een markt in kan zitten, al is het geen grote.

En "enterprisey" producten als BizTalk nemen wel vaker rare beslissingen waar je niet blij van wordt als ontwikkelaar/integrator, maar daar doe je niks aan en dat is op zich ook niet het probleem van de frameworkontwikkelaars. Wat je omgekeerd ook niet kan verwachten is dat die frameworkontwikkelaars even BizTalk geschikt gaan maken voor een toekomst op Linux. Zoiets moet toch echt vanuit de rest van MS komen, als ze er al een markt in zien. Ik denk dat het gewoon zo lang mogelijk pappen en nathouden gaat blijven voor de voorzienbare toekomst.

[Hoover]

Wellicht dat zo iets gebeurd. Tot op heden is het officieel antwoord : er komt geen port van WCF, gebruik gRPC. Zolang er geen werkend alternatief is vanuit MS of de community, is het afwachten wat ze gaan doen. De push naar Azure met Logic Apps is groot in ieder geval. Maar dat product is verre van compleet als je het vergelijkt met BizTalk of andere oplossingen.

[boxit]

De WCF client kant zit nog steeds in .NET 5. Ze hebben het WCF gedeelte voor web service implementaties eruit gelaten. Daarvoor moet je gebruik blijven maken van .NET Framework 4.8, wat nog vele jaren als onderdeel van het Windows OS zal blijven bestaan (.NET 3.5 zit er ook nog steeds in), maar geen nieuwe features meer krijgt (wel bugfixes en security patches). WCF is volwassen genoeg om zonder nieuwe features nog lang bruikbaar te blijven (ook voor toekomstige versies van BizTalk).
Of wachten op een stabiele release van https://github.com/CoreWCF/CoreWCF

[Reactie gewijzigd door boxit op 23 juli 2024 03:01]

[CornéM]

Je kunt (tot het wel volledig werkt) gebruik maken van gRPC-Web, wat al wel werkt op Azure App Service en IIS.

[EraYaN]

Ze verwachten gewon dat je een andere HTTP server dan IIS gebruikt, Kestrel met waar nodig een reverse proxy of Application Gateway ervoor. Dat is ook beter voor je portemonnee ook. Dus uiteindelijk moet het gewoon vervangen worden.

[Hoover]

Dat is leuk met BizTalk. Het webservices gedeelte is daarmee geïntegreerd en essentieel onderdeel van het platform.
Dat ga je niet zomaar omhangen of ombouwen.
Daarnaast zijn de kosten van een Windows Licentie peanuts vergeleken met de licenties die je voor BizTalk zelf neerlegt. Die paar duizend euro is een druppel op een hete plaat.

[BasieP]

Volgens mij klok-klepel je hier iemand/iets na.
In de praktijk kan je kestrel niet inzetten voor het bovenstaande. Probeer het anders zelf een keer. Dat is een leuke uitdaging.
Ik snap dat MS van de integratie af wil, en kestrel 'clean' wil houden, maar nu valt er idd functionaliteit tussen wal en schip.

Voor wcf wordt verwezen naar 'libraries van derden' maar die zijn slecht of incompleet.
Nu moet ik zeggen dat 15 jaar MS technologie mij geleerd heeft dat elke microsoft standaard een beperkte levensduur heeft. Ik had net mijn wcf certificering en toen kregen we wcf 2.0.compleet anders.
Lessons learned voor mij zijn o.a. dat ik eerst wil zien of het gaat vliegen (ook buiten ms) en dan ga ik er pas mee bezig.

[EraYaN]

Er is echt helemaal niets mis met gRPC en Kestrel combinatie, en als je daar dan vervolgens nginx of traefik voor zet heb je echt een prima stack. As we speak ben ik dat "aan het proberen", zelfs communicatie met oude WCF services gaat prima. Je moet alleen geen nieuwe WCF services willen bouwen. gRPC doet het verder prima op .NET 4.8 (je kunt zelfs redelijk makkelijk beide supporten in een nuget package voor je client files) dus er is eigenlijk geen enkel ECHT probleem als je echt wil.

[BikkelZ]

Ik hoop dat ze bij Microsoft ook eens flink de bezem gaan halen door alle verschillende naamgevingen voor dingen. Ik vraag me af of zelfs binnen Microsoft er nog mensen rondlopen die echt uit hun blote hoofd weten wat de juiste versie voor wat is voor welke frameworks.

[StefanJanssen]

Zelfs buiten MS zijn die mensen er, het is niet zo heel ingewikkeld, en met .NET 5 en verder wordt het makkelijker gemaakt. MS is al een aantal jaar bezig met het zorgen dat het overstappen naar .NET 5 relatief makkelijk zou worden. De communicatie hierover vanuit MS is altijd erg goed geweest.

Voor gisteren was het:
.NET Framework => Alleen voor Windows (Server) development.
.NET Core => Voor nieuwe applicaties het aanbevolen framework
.NET Standard => Een overeenkomende subset van .NET Framework en .NET Core. Handig voor libraries die zowel voor Framework als Core gebruikt moeten worden.

Nu is hier .NET 5 bij gekomen, dit is zodat de drie bovenstaande frameworks samen komen.
Als je nu je project wilt porten van .NET Framework naar .NET 5 wordt er aangeraden om eerst al je Class Libraries om te zetten naar .NET Standard (In mijn ervaring is dit vaak puur een kwestie van de target framework aan te passen). Dit zorgt er dus voor dat je .NET Framework applicatie gewoon nog blijft bouwen terwijl je het naar .NET 5 omzet. Op deze manier kun je bijvoorbeeld je CLI tool al op .NET 5 draait terwijl je applicatie met UI die werkt met .NET Framework onveranderd blijft tot deze ook omgezet kan worden naar .NET 5.

[phYzar]

Enige nadeel van de tussenstap via .NET Standard is dat die niet echt up to date is, en er komt geen versie van .NET Standard meer die de lat hoger legt. 2.1 blijft de laatste, en .NET Framework gaat zelfs niet verder dan .NET Standard 2.0

[StefanJanssen]

.NET Standard is ook nooit iets geweest om het lang in leven te houden. Het is puur bedoeld voor de overgangsperiode.

[robertpNL]

Is dat zo? .NET Standard is ook bedoeld voor multi-platform ondersteuning. Als een specifieke library/framework voor een platform voldoet aan .NET Standard, dan draait het ook op andere platformen.

[StefanJanssen]

Op termijn zal alles .NET 5/6/7 worden en zou .NET Standard dus uitgefaseerd raken. .NET Standard is nu echt een overbrugging voor .NET Framework naar .NET Core.

Aangezien iedere partij die .NET gebruikt inspraak heeft over .NET 5 en hoger is een shared gedeelte niet meer nodig. Hieronder vallen onder andere MS (.NET Framework, .NET Core en Mono (Xamarin)) en Unity.

[robertpNL]

Ja, Ik lees het . Per platform is er een target name.

net5.0 is code dat draait op alle platformen. Met een target name op specifieke platform. Bv net5.0-windows, net5.0-ios etc.

[Reactie gewijzigd door robertpNL op 23 juli 2024 03:01]

[Earry]

.NET Standard is juist wel iets geweest om lang in leven te houden. Voortschrijdend inzicht (en de beschikbaarheid van bijna alle API's die in .NET Framework beschikbaar waren) heeft er toe geleid dat men hier vanaf is gestapt. Het hielp ook niet mee dat er veel verwarring was over de namen/versies, vandaar: https://devblogs.microsoft.com/dotnet/introducing-net-5/

[BasieP]

Hoezo niet? Je kan daarin toch exact hetzelfde?
Wellicht moet je langversion even op 'latest' zetten

[P1nGu1n]

Dat hebben ze nu toch gedaan? .NET 5.0 volgt .NET Framework 4.x en .NET Core 3.x op, waarmee ze het aantal namen reduceren.

[D-Raven]

Nee, want er zijn nog steeds meerdere UI frameworks / platforms voor het ontwikkelen van UI apps op windows.
Die gaan niet weg. Want het windows development platform team zijn een stel idioten die nooit publiekelijk toe willen geven dat ze weer een van hun UI platforms ge-deprecate hebben.

De nieuwste kansloze iteratie heet het Windows MAUI framework. Waarom kansloos? Omdat ik er 100% van overtuigd ben dat het gewoon een kwestie van tijd is voordat er weer een paar mensen daar weg gaan, en de nieuwe mensen vinden dat ze weer iets niet moeten bouwen.

Dus ik zit in het kamp: "eerst zien, dan geloven".

Ondertussen heb je vrij veel opties:
- Winforms
- WPF
- UWP
- MAUI
- en wat ik nog meer vergeet

Dus ja, binnen het .NET framework gaan er een hoop dingen vervallen. (Netstandard bv) Maar daar om heen blijft het verwarrend, vooral als je native windows development wilt doen.

[Reactie gewijzigd door D-Raven op 23 juli 2024 03:01]

[Gomez12]

Nee, want er zijn nog steeds meerdere UI frameworks / platforms voor het ontwikkelen van UI apps op windows.
Die gaan niet weg.

De reden dat die voornamelijk niet weg gaan is omdat ze simpelweg de meest volwassen UI frameworks / platforms zijn.

Ga je buiten de windows Frameworks kijken, dan kom je helemaal in een buggy landschap wat heel slecht supported is.

[D-Raven]

Volwassen frameworks welke officieus gearchiveerd zijn door microsoft. Maar wat niet als dusdanig wordt uitgedragen. Wat het dus erg verwarrend maakt voor beginnende ontwikkelaars.

[Gomez12]

De pest is dan eerder dat MS officieus niets archiveerd en alles maar backwards compatible laat zijn.

Waardoor niets echt fout is, maar je ondertussen wel 5 plekken hebt waar je user-data voor een programma op kan slaan.
Zo zou Silverlight WinForms vervangen, alleen Silverlight is dood en WinForms is nog steeds toegestaan.

Zo verbaas ik me in elke iteratie van win10 er weer over waarom ik 2 configuratieschermen heb, waar soms het in het ene staat en soms in het andere.

[LaTiNo156]

Toegestaan? Keihard noodzakelijk aangezien er nog honderden duizenden legacy Winforms applicaties bestaan.

[84hannes]

Ga je buiten de windows Frameworks kijken, dan kom je helemaal in een buggy landschap wat heel slecht supported is.

Weet jij heel zeker dat je ooit een product hebt gebruikt waarvan de naam niet met ‘Microsoft’ begint?
Wil je beweren dat er voor Gnome/KDE geen GUI frameworks bestaan?

Ik heb te vaak gesprekken gevoerd met mensen die alle Microsoft-technologieën fantastisch vinden (Powershell, RDP, Visual Studio, C#, TFS/Azure DevOps etc.) maar bij nader inzien nog nooit iets anders hebben geprobeerd, dus vergeef me dat ik bij posts als deze automatisch denk met een fanboy met oogkleppen te maken heb.

edit:
Laat ik een voorspelling doen

Mijn opa's kelder was een puinhoop. Hij kon niets weggooien, dus niemand kon er iets vinden. Maar hij wel, dus hij vond het een overzichtelijk gebeuren.

Mensen die op dit artikel reageren, zitten zover in het MS ecosysteem dat ze denken dat het logisch is dat een IDE ook gebruikt wordt voor versiebeheer, of dat refactoring in een (dure) plugin moet zitten. Dat als je een programmeertaal kiest, dat je je daarmee vast legt wat betreft zowel IDE als compiler. Ik ben de rare eend in de bijt. Ik gebruik Visual Studio alleen als het echt moet, dus ik snap niet waarom de C# compiler na versie 6.0 opeens weer begon bij 1.0 (iets met Roslyn?). Ik begrijp het verschil tussen .Net, .Net Framework en .Net core niet goed genoeg. Dus ik wordt waarschijnlijk weggemod omdat ik iets een puinhoop vindt, terwijl julliezoveel tijd hebben geïnvesteerd in het begrijpen van die puinhoop dat jullie een overzichtelijke kelder zien..

[Reactie gewijzigd door 84hannes op 23 juli 2024 03:01]

[Gomez12]

[...]
Weet jij heel zeker dat je ooit een product hebt gebruikt waarvan de naam niet met ‘Microsoft’ begint?

Yep.

Wil je beweren dat er voor Gnome/KDE geen GUI frameworks bestaan?

Volwassen en gedocumenteerde en door fatsoenlijke tools gesupport, dan ja...

Er bestaan zat andere frameworks, alleen noem er eens 2 die voldoen aan volwassen, gedocumenteerd en met fatsoenlijke tools behalve html en cocoa

[84hannes]

alleen noem er eens 2 die voldoen aan volwassen, gedocumenteerd en met fatsoenlijke tools

Android UI
Qt

[EraYaN]

MAUI is gewoon een evolutie van Xamarin.Forms, dat gaat ook al weer even mee. En dat kan de evolutie goed gebruiken. (Ook moet er gezegd worden dat dat gewoon 1 van de andere frameworks gebruikt voor het Windows platform) en WPF en UWP (XAML) werken vanuit de developer gezien grotendeels hetzelfde.

[JorisNoordweg]

Maar wat moet ik nu kiezen als ik op dit moment een nieuwe native Windows app moet ontwikkelen? Het moet snel, licht en er moet veel handmatig op canvas getekend worden. Toch maar semi-ouderwets WPF?

[Gomez12]

Niet echt, .Net 5.0 volgt .Net 3.x op en het Framework 4.x dat laten ze gewoon afsterven.

Dat ga je ook duidelijk zien als je in .Net 3.x en in Framework 4.x een project hebt en je wilt dat overzetten naar .Net 5.0, .Net 3.x doet dat vrij pijnloos, Framework gaat pijnlijk worden.

[Estel]

Eh, nee. P1nGu1n heeft gelijk. Overzetten kan lastig zijn, met name voor wat meer GUI gerelateerde zaken maar over het algemeen gaat het goed. Het is wel degelijk een samenvoeging van .Net 3.x en Framework 4.x.

[Gomez12]

Het zijn niet enkel de GUI zaken.
.Net Framework heeft altijd zijn roots altijd heel dicht tegen windows aangeschuurd en daar is men pas van los aan het gaan met .Net Core.
Oftewel heb je een project wat jarenlang al draait en wat bijv werkt op WCF (an dan al helemaal de geavanceerdere functies) dan ben je de sjaak.

Of laat ik het anders zeggen, heb jij een project wat begonnen is in Framework 1 en wat de hele tijd meegegroeid is met de best practices binnen .Net Framework dan heb je nu een shitload aan breaking changes.
Begin je nu een project in .Net Framework 4.8 ja dan is het nog wel te overzien.

[Estel]

Ik zei dan ook met name GUI, niet exclusief. Uiteraard als je een oud project heb, zal het een (stuk) lastiger zijn. Logisch, want dan moest je ook vaak om dingen heen werken en 'creatief' worden en soms ook ongedocumenteerde windows API's gebruiken. Ja, die zaken worden langzaam maar zeker uitgefaseerd. Echter, als je je project elke keer hebt meegenomen naar het nieuwe framework en daarbij ook de code geoptimaliseerd had, zijn die zaken bijna allemaal weg.
Ik weet dat geld en tijd belangrijk zijn, maar naar een nieuw framework gaan zonder die optimalisaties is naar mijn mening vrij zinloos.
In het verleden heb ik verschillende libraries getracht over te zetten naar .Net Core/Standard. Soms lukte dat, maar niet altijd omdat die functionaliteit nog niet beschikbaar was. Dat zou nu een stuk beter moeten zijn.

[RobNL]

Ik citeer: "Microsoft noemt versie 5.0 de eerste release op weg naar samenvoeging van de verschillende platformen."

Je wens is volgens mij precies doorgevoerd.

[BikkelZ]

Ja dat snap ik, maar er zijn nog zoveel meer dingen vaag. Mensen pakken vaak maar gewoon de oude Win32 libraries omdat ze niet meer weten of ze nog WPF kunnen gebruiken of niet of toch maar met JavaScript maar werkt het dan op Windows 7 of.... Je wordt er echt gek van als je "even" iets voor een Microsoft wil doen!

[Reactie gewijzigd door BikkelZ op 23 juli 2024 03:01]

[StefanJanssen]

Nee? MS geeft al jaren aan dat WPF en WinForms voorlopig niet weggaan en dat het ook zal werken met .NET Core en .NET 5.
Als je ook maar enige interesse hebt in het .NET ecosysteem weet je precies waar je aan toe bent. De roadmap tot 2024 is al 1 of 2 jaar bekend.

[BikkelZ]

Als je ook maar enige interesse hebt in het .NET ecosysteem

Nogal een laatdunkende opmerking. Ik ben redelijk wat tijd kwijt aan onderzoek wat ik precies wel en niet kan en moet gebruiken bij Microsoft voordat ik iets begin te bouwen, dat overkomt me veel minder bij andere stacks. Je weet best dat ze ontzettend lang WPF maar een beetje hebben laten bungelen. En is het op dit moment nog echt een framework waarbij alle grafische functies van Windows 10 goed werken?

Ik werk ongeveer één keer per jaar aan een project met Microsoft frameworks en tot nu toe liep ik constant tegen het zelfde aan. Maar goed misschien zijn mijn klanten ook gewoon gek dat ze een "ongeïnteresseerde" developer geld betalen.

[StefanJanssen]

Het is totaal niet laagdunkend bedoeld. Ik bedoel dat de hele communicatie van MS helemaal op orde is geweest de afgelopen 4 jaar (over daarvoor kan ik niet veel zeggen, toen was mijn C# kennis alleen binnen Unity).
En wat bedoel je met "WPF laten bungelen"? Ze hebben gewoon nog volledige ondersteuning en ook .NET Core krijgt (of heeft?) deze ondersteuning.

[jozuf]

Ik denk dat @BikkelZ bv op zoiets duit;
https://visualstudiomagaz...020/09/30/wpf-survey.aspx

WPF lijkt mij ook niet echt de prio meer te krijgen.
Maar verder kan ik me niet helemaal in de statements vinden. Het word juist veel beter, zeker nu met de ontwikkelingen in Core. Vind het zelf wel fijn dat alle bloat in .NET Framework is word aangepakt, en het veel leaner en cleaner word opgezet.

[R4gnax]

Als je ook maar enige interesse hebt in het .NET ecosysteem weet je precies waar je aan toe bent. De roadmap tot 2024 is al 1 of 2 jaar bekend.

En toch hebben ze nog steeds aardig de neiging om het kleed onder je uit te trekken.
Neem bijv. het euvel met NodeServices waar zonder veel ruchtbaarheid vooraf, gewoon keihard de stekker uit getrokken werd.

[Reactie gewijzigd door R4gnax op 23 juli 2024 03:01]

[Eonfge]

Vanuit de ogen van een ontwikkelaar in Java, Scala en dergelijke, zie ik .NET altijd met gemengde gevoelens:

Het is super goed dat Java meer concurrentie heeft en je ziet ook dat bedrijven zoals een IBM, Red Hat, Eclipse, Lightbend, Jetbeans meer onder druk worden gezet om het Java ecosysteem te verbeteren. OpenJ9, sbt, Akka, AdoptOpenJDK, SDKman en dergelijke hebben het ecosysteem aanzienlijk verbeterd en dat is ook mede dankzij concurrentie.

Anderzijds zie ik hoe .NET bijna exclusief door Microsoft wordt ontwikkeld, hoe bijna alle tooling ook van Microsoft is, en hoe Microsoft exclusief bepaalt in welke richting .NET wordt doorontwikkeld. Dat is een risico voor de toekomst, omdat Microsoft in de toekomst de deal altijd kan aanpassen.

Dat Microsoft de voorwaarden in de toekomst gaat aanpassen, is niet een puur hypothetisch probleem. Dit gebeurde in de Java wereld ook met Oracle. Gelukkig, door de meer dwingende licentie van Java (de GPL 2.0), konden bedrijven zoald Red Hat en IBM de handen in een slaan en Oracle buitenspel zetten. Nu werken ze allemaal gedwongen samen, en heeft er geen 1 bedrijf een absolute meerderheid in de ontwikkeling van het Java ecosysteem.

Waar ik wel heel blij om ben met .NET? Ik heb er een certificaat in behaald dus elke recruiter die nu mijn CV leest en denk dat ik een senior .NET ontwikkelaar is, staat meteen 1 punt achter

[MneoreJ]

.NET is inmiddels al een tijdje open source. MS kan de deal aanpassen, maar niet zonder dat mensen kunnen forken en doorgaan. Dat was vroeger dan misschien niet heel realistisch omdat je dan nog steeds afhankelijk was van de MS installatie van .NET, maar tegenwoordig net wel omdat je je app geheel los van het framework kan bouwen en je Core/.NET 5 libs erbij kunt doen.

MS heeft trouwens ook absoluut geen belang met het ecosysteem op die manier versplinteren, want dan raken ze heel snel het draagvlak voor .NET kwijt.

[Eonfge]

Open source is niet per definitie decentraal.

Als je kijkt wie er voornamelijk aan .NET werkt, dan zie je dat Microsoft de controle houdt. Al zou de volgende versie opeens niet meer open source zijn, dan zal het bedrijven zoals IBM jaren duren voor ze los van Microsoft een concurrerende implementatie van .NET kunnen aanleveren.

Wat ik al zei, dit is ook bij Java gebeurd en dat is ook open-source. Al is het bij Java mogelijk om Oracle juridisch te dwingen om hun eigen toevoegingen openbaar te maken.

[MneoreJ]

Tja, Mono was en is ook nog steeds een ding, en inmiddels werken de devs daarvan ook gewoon vrolijk mee aan .NET zelf. Ik denk dat dat "jaren" echt aanzienlijk meevalt. Ik heb zelf al een keer heel .NET gecompileerd om even een aanpassinkje in de core libraries te doen voor een feature die ik graag alvast wilde

Trekt MS de kar van .NET, dat wel natuurlijk, maar voor ieder OSS project geldt wel dat er iemand of iemanden zijn die feitelijk bepalen welke kant het opgaat. Vind je het niet leuk? Dan zul je moeten forken. Je moet het wel bont maken voor mensen die stap willen nemen, maar het is altijd een stok achter de deur.

Feit is dat je op dit moment met 100% open source software .NET applicaties kunt maken en distribueren, dus zelfs als zou MS morgen besluiten dat heel dat open source maar onzin was en ze gaan weer proprietary verder, dan is dat nog geen stop voor ontwikkelaars. Ben je afhankelijk van technologie die nog niet open source is (zijn nog tools/libs die puur proprietary zijn en ook geen OSS alternatief hebben), dan is het misschien een ander verhaal. Ook daar is het MS van nu niet te vergelijken met Oracle in de zin dat MS actief OSS nastreeft (VS Code in het leven roepen omdat VS niet op Linux kan draaien, dat soort dingen).

[LaTiNo156]

Leuk dat forken, op een gegeven ogenblik heb je talloze forks, de helft is alweer in de steek gelaten, in de 1 zit feature A, de ander heeft feature B, welke moet je dan hebben?

[MneoreJ]

Degene die aan je eisen voldoet, en als die niet bestaat mag je A en/of B ervan overtuigen dat er iets gemerged moet worden.

TANSTAAFL. Dat is dan ook de reden dat de meeste projecten zeer terughoudend zijn met forks, want alleen de fork(s) waar de community achter zit heeft in de praktijk succes. Ergo: stok achter de deur; een fork van .NET zou er in de praktijk pas komen als MS echt helemaal niet meer naar de community luistert en dingen doet waar niemand het mee eens is. Zo heet zal de soep niet snel gegeten worden.

[BasieP]

Ik ken weinig opensource producten die niet de regie bij een kleine club 'internen' houden. Dit is logisch en snap ik volledig.
als je kijkt hoe veel 'wildgroei' er in bijvoorbeeld linux zit (en daar pogen ze ook regie te houden) ben ik persoonlijk blij dat MS het roer wat steviger in handen heeft.

Over de tooling: de compiler is open source, je kan je eigen tools schrijven. De tools van MS zijn de meegeleverde set, maar je zit zeker niet vast aan die set.

[Earry]

.NET (Core) is onder de .NET Foundation ondergebracht. Als jij richting wil geven dan kun je lid worden van die foundation. Als jij mee wilt ontwikkelen aan .NET inclusief designbeslissingen, dan kun je deelnemen aan de open GitHub discussies die daarover gaan. Uit ervaring weet ik dat ze ook goed open staan voor goede ideeën en dat mensen als (bijvoorbeeld) Immo Landwerth ook gerust open staan om een inhoudelijk gesprek met je te voeren.

[418O2]

Dat er 1 partij is die de richting bepaalt kan ook een voordeel zijn natuurlijk. OSS overleg is niet altijd even vruchtbaar of dynamisch.

[Eonfge]

Het mes snijd aan twee kanten...

Centralisatie van macht en autoriteit heeft natuurlijk het voordeel dat zo'n organisatie snel kan sturen en noodzakelijke wijzigingen kan doorvoeren, ook al hebben veel gebruikers misschien bezwaren. Anderzijds is er natuurlijk het probleem dat je het dan wel eens moet zijn met de macht- en autoriteitshebbers, en dat je nu, en in de toekomst, altijd kunt blijven vertrouwen in de gezonde verstandshouding...

Ik verkies een systeem waarbij macht en autoriteit decentraal is, omdat ik mij mijzelf graag voorbereid op de (in mijn ogen onvermijdelijke) corruptie van macht.

O, en dit is natuurlijk ook van toepassing op software ecosystemen.

[Ablaze]

MS heeft er meer baat bij dat je Azure gebruikt.
Het populair maken van .NET is gewoon een methode om meer bedrijven richting het Azure ecosysteem te krijgen.

[DDX]

Zou mooi zijn als updates hiervoor ook weer via windows update (en wsus) beschikbaar komen.
Huidige .net core (2.x en 3.x) moet je steeds handmatig de update downloaden/installeren.

[Jogai]

Je kan de benodigde binaries bij een applicatie meeleveren, zodat er op het systeem niets van hoeft geinstalleerd te staan.

[DDX]

Werkt niet voor website/iis, dan moet je de module installeren, kan je daarna natuurlijk wel in de web applicatie de juiste versie zetten.

[thof]

Of geen IIS meer gebruiken maar Kestrel

[biglia]

Is Kestrel dan al zo volwassen dat het IIS kan vervangen?

[Robbaman]

Volgens mij kan Kestrel sowieso geen SNI ondersteunen, dus als je van TLS gebruik maakt met meerdere sites achter dezelfde poort, dan zul je als ik het goed begrepen heb altijd een reverse proxy moeten toepassen die dit voor je kan afhandelen.

Dit hoeft overigens geen IIS te zijn natuurlijk, ik meen dat een beetje firewall/load balancer dit ook al voor je kan regelen.

[Lakerfield]

Kestrel heeft ondersteuning voor SNI vanaf ASP.Net Core 2.1
https://devblogs.microsof...-the-kestrel-http-server/

Geheel is ook goed te aan te passen door een eigen implementatie van de ServerCertificateSelector te maken. Hier draait het vanaf zomer 2018 in productie met lets encrypt integratie.

Microsoft heeft nu zelf een open source reverse proxy server uitgebracht bovenop kestrel.
https://devblogs.microsof...troducing-yarp-preview-1/

[Robbaman]

Ja, maar aangezien er maar één process op een poort kan luisteren moet je dan wel al je web applicaties als een dotnet core process draaien nietwaar?

[BasieP]

Zeker, wij (groot bedrijf) draaien al ruim 2 jaar op kestrel.

[SiErRa]

Kestrel is wel een webserver, maar ook echt iets anders dan IIS.

Kestrel is onderdeel van je applicatie, een library. Waar IIS een losstaand product is waar je applicatie en websites in configureerd.

Kestrel wordt veel in microservice omgevingen gebruikt, waar een service in een Docker container draait, en het effectief een console applicatie is die Kestrel draait en zo een webapi aanbiedt.
Waar voor dan een reverse proxy en/of load balancer staat die het verkeer naar de services stuurt.

[qless]

Zowel kestrel als IIS gooi ik altijd achter een reverse proxy

[MrMonkE]

En dan alleen SSL-certificates op je proxy?

[qless]

Ja, intern op andere poort die niet bereikbaar is van buiten. Zeker met nginx/apache werkt letsencrypt ook een stuk makkelijker.

[MrMonkE]

Precies. Ik liep altijd te klooien als ik mijn docker (prive) de lucht in gooi om er de meest recente letsencrypt op te krijgen. Ik heb alle data voor letsencrypt nu op 'mounts' en hoef alleen even te runnen maar zou netter zijn als het via reversed proxy zou gaan. Misschien toch eens uitzoeken.

[Melones]

OPNSense bakkie er voor? Doe je proxy en letsencrypt in 1 tool/device/vm/gui?

[Phyxion]

"We are working on a plan to make updates for .NET 5.0 available on Microsoft Update (MU) in the future. Windows Update (WU) is for updates to the OS, while Microsoft Update is for updates to other Microsoft products including .NET 5.0. For Windows client users this will require opting in to “Receive updates for other Microsoft products when you update Windows” i.e. opt-in to receive updates via. For IT administrators using WSUS and/or SCCM, this will require opting in to a new product category for .NET 5.0. We will be publishing more details around this in the coming weeks."

[kiddingguy]

Heeft het zin om als "gewone" Windows gebruiker deze v5.0 te installeren, of is dit meer voor programmeurs en ontwikkelaars?

Ofwel, maken er al applicaties gebruik van deze nieuwe engine of komt dan t.zt. bij de applicatie dat deze .NET 5.0 automatisch wordt meegeïnstalleerd?

[hdullink]

Heeft geen zin. De nodige bestanden (met juiste versies) komen mee met de installatie.

[kiddingguy]

thx!

[downtime]

Wanneer gaat .NET 5 weer standaard aan Windows toegevoegd worden? Je moet .NET Core nu apart downloaden.

[KoalaBear84]

"in the future", meer info "in the coming weeks".

Via comment van andere Tweaker de bron gevonden:
https://devblogs.microsof...ing-net-5-0/#comment-7831

[Reactie gewijzigd door KoalaBear84 op 23 juli 2024 03:01]

[Jogai]

.NET 5 is geen LTS release. .NET core 3.1 is nog supported tot december 2022, en .NET 6 (dus wel een LTS) staat op de planning voor november 2021.

[Ablaze]

Wat verder niet uitmaakt als je gebruik wilt maken van alle nieuwe functies en verbeteringen in deze versie.

.NET 5 is net zo goed getest als een LTS release. Je kunt 'm dus gewoon in productie gebruiken.
Zodra .NET 6 uit is kun je met relatief kleine aanpassingen over. Die stap is kleiner dan gaan van .NET Core 1/2/3(.1) naar .NET 6.

[Reactie gewijzigd door Ablaze op 23 juli 2024 03:01]

[JDamn]

Er staat X# 9.0 maar dit moet zijn C# 9.0

[-ION-]

Spel- en tikfoutjes - en dus *geen* andere foutjes - deel 45

[JDamn]

Ah tnx