Microsoft maakt hot-reloadfunctie toch breder beschikbaar in .Net 6 na kritiek

Microsoft heeft de beslissing teruggedraaid om de hot-reloadfunctie te beperken tot de betaalde Windows-versie van zijn .Net-ontwikkeltools. De opensourcegemeenschap, die de functie graag ziet in de opensource-multiplatformvariant Visual Studio Code, gaf daar veel kritiek op.

Hot reload is een functie waarbij programmeurs aanpassingen in hun code direct kunnen zien functioneren in een ander venster, in plaats van dat ze de te ontwikkelen applicatie volledig opnieuw moeten starten. De functie wordt gewaardeerd onder programmeurs omdat het ze veel tijd bespaart, zeker in situaties waarbij ze alleen een kleine wijziging in de code willen uitvoeren.

Microsoft besloot van de week om hot reload te beperken tot Visual Studio, de freemium Windows-versie van zijn integrated development environment. Dit schoot ontwikkelaars die de opensourcevariant van de tools, Visual Studio Code, die op bijvoorbeeld Linux kan draaien, in het verkeerde keelgat. Niet alleen omdat ze de functie ook graag gebruiken, maar omdat deze al crossplatform werkt in een release candidate van het aankomende .Net 6. Microsoft besloot dus niet alleen om de functie voorrang te geven in Visual Studio, maar haalde de mogelijkheid om hem te gebruiken in Visual Studio Code, die er al was, weg.

De pull request om de functie uit dotnet watch te halen en te beperken tot Visual Studio 2022, kreeg ook een slotje, waardoor alleen mensen die echt werken aan de code kunnen reageren. In reactie daarop kwam de gemeenschap met zijn eigen pull request, om de eerste pull request terug te draaien.

Volgens bronnen van The Verge was de beslissing er een 'van een zakelijke aard', gemaakt door Julia Liuson, hoofd van de ontwikkelaarsdivisie van Microsoft. Daarnaast schrijft de site dat de beslissing ook geleid had tot onvrede bij Microsofts eigen werknemers. Op die berichtgeving wilde Microsoft verder niet reageren tegenover de site. In de blogpost waarin de beslissing teruggedraaid wordt, stelt het bedrijf alleen dat de code 'onbedoeld verwijderd werd vanuit een poging tot scoping' en dat het de bedoeling was om 'dat codepad gewoon niet te gebruiken'. Microsoft Visual Studio 2022 komt op 8 november uit.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (50)

Het lijkt gewoon een inschattingsfout van Julia Liuson. Winst willen maken en maar zien waar het schip strand. Komt vaker voor.

Ook ik zie dit vooral als een inschattingsfout en vind het zeer spijtig dat sommige mensen dit al direct zien als het opblazen van alles wat er de afgelopen 7 jaar gebeurd is. Als dat zo eenvoudig zou zijn, dan moeten veel mensen zich eens achter de oren krabben en zichzelf afvragen waarom ze zo blind zijn geweest.

Ja, dit schaad het vertrouwen, maar tenzij er een patroon opduikt waarin ze dit soort dingen vaker doen is het slechts een kleine deuk en zal het op termijn een voetnoot worden. Wat ik wel al direct zie gebeuren is dat tegenstanders van MS dit voorval weer gaan aangrijpen als een toonbeeld van de minachting van MS foor de FOSS wereld telkens als er nog maar een hint is naar iets dat mogelijks gaat veranderen om dan te zeggen: zie je wel, MS heeft een geschiedenis van en doet het weer.

Het is ergens ook spijtig dat een bedrijf als MS aan hogere standaarden gehouden wordt dan de FOSS gemeenschap zelf.

Nah, het riekt naar wel de lusten maar niet de lasten.

Wel mensen hun vrije tijd willen gebruiken voor input, maar er toch nog weer geld uit willen halen.
Vertrouwen komt te voet en gaat te paard.

Laatst was er ook al een akkefietje omtrent .Net. en open source: https://www.theregister.c...ndation_community_issues/

Maar veel van de kritiekpunten zijn alles behalve uniek aan dit project en zie je wel vaker terugkomen in de FOSS wereld wanneer een community in 2 kampen verdeeld geraakt. En natuurlijk heeft MS een zeer groot belang bij de ontwikkeling van. Net, een platform waar ze al meer dan 20 jaar aan werken en wat belangrijk is en blijft voor Microsoft. Het mag dan niet verbazen dat zij de controle daarover niet volledig uit handen geven.

Je kan moeilijk zeggen wel de lusten maar niet de lasten. MS heeft een enorm waardevol stuk technologie vrijgegeven onder FOSS licenties met als doel een nog groter publiek aan te trekken. Maar dat betekend ook dat je sowieso een deel controle verliest. En het is ook niet alsof de ontwikkeling nu ineens helemaal op de schouders van die community is gevallen.

Inderdaad, als je dan kijkt wat ze met de teams client voor linux doen, geen één update is er geweest (althans niet met features) sinds de release. Zo zie je maar hoe hard ze hun wel niet inzetten

Compleet ongerelateerd. Microsoft is zo gigantisch groot en verspreid dat dit soort producten bijna een eigen bedrijf zijn. De mensen achter .NET doen geen fuck met Teams. Andere devs, product managers, marketing en sales.

Dat klop niet. Zelfs binnen grote bedrijven is er sprake van een algemene aanpak. Als het bedrijf het belangrijk vind dat al zijn producten op alle platformen werken en daarbij systematisch worden geupdate, zal dat ook zo gebeuren. Dat gebeurd hier niet, maar nog het gaat over de gemeenschappelijke deler waar je kan van afleiden wat een bedijf belangrijk vind en wat niet. Dat men de bal wel is misslaat kan heus, maar wanneer er op systematische basis gebeurd spreken we van het "dna van het bedrijf".

Idd, ik zie het ook als een accident de parcours en op zich niet de beste zet.

Maar de reacties erop zeggen ook heel veel en zijn mijn insziens ook zeer kort door de bocht, ze ruiken zelfs een beetje naar entitlement.

MS is nog altijd niets verplicht tegenover de open source community.

Er is wel een patroon aan het opduiken waarbij ze de open source community steeds tegen de benen schoppen. Ik ben al ruim 15 jaar .net developer, en zal dat zeker nog een tijd blijven, maar dit zijn wel bedenkelijke acties. Aaron Stannard kan het beter verwoorden: https://aaronstannard.com/new-rules-dotnet-oss/ (en zie ook recentere blogs van hem die over meer recente issues gaan).

Nouja, winst willen maken, Microsoft is geen sociale instelling, en het ontwikkelen van het .Net framework kost nu ook niet niks. Het is echt een fantastisch (multi)platform.

Voor de goede orde: ik ben een MS fan. Winst willen maken... daarmee bedoel ik uiteraard dat je kunt verwachten dat de winstmarge wordt gezocht. Ze zijn inderdaad geen sociale instelling. En daar hoort bij dat er soms een verkeerde inschatting wordt gemaakt over waar je dan meer winst mee kunt maken. Wat mij betreft all-in-the-game (en niks bijzonders aan)

Tja, jammer dat Tweakers niet opmerkt dat er iets mis is met de kwaliteit van de programmeurs als die überhaupt een hot-reload debugger nodig hebben. Als je onvoldoende inzicht hebt in wat code doet, moet je tijd investeren in het schrijven van unit- en integratietesten en niet trial-and-error testen in een debugger, hot-reloading of niet.

Een hot-reload debugger kan daarbij geen onderdeel zijn van het testplan omdat een productieomgeving ook geen hot-reload functionaliteit zal hebben. Dat zou immers een veiligheidsrisico zijn. Testservers wordt zoveel mogelijk productiegelijkend ingericht.

Dat een hot-reload functionaliteit om performance redenen gebruikt moet worden is ook onzin. De meeste dingen die langzaam starten kun je mocken of ondervangen door gewoon snellere hardware in te zetten.

Het een sluit het ander niet uit.

- Het kan ook handig zijn als je je unit tests kan fixen door gebruik te maken van de hot reload functie.
- Je beschrijft ook de ideale wereld waarbij nieuwe software geschreven wordt. Maar je zegt niks over het onderhoud van bestaande software, die niet solid genoeg geschreven is, en dus moeilijk te unit testen is. Daar gaat je unit testen verhaal niet op.
- Soms wil je gewoon iets vlug ontwikkelen in het kader van een R&D project.
- Tijdens een piloot snel een blokkerende fout fixen zodat je gebruikers weer verder kunnen testen en geen tijd verliezen.

Ik vind het nogal kort door de bocht om mensen onbekwaam te noemen omdat ze gebruik maken van een bepaalde functionaliteit.

[Reactie gewijzigd door DonCortizone op 24 oktober 2021 17:56]

Wat een onzin, je gebruikt het ook bij front end design en ook bijvoorbeeld bij het communiceren met externe apparatuur (in mijn geval industrieële robots). Dat valt helaas niet allemaal netjes vooraf uit te schrijven, of het uitschrijven kost net zoveel moeite als de implementatie zelf. Leuk als je space shuttles of hartbewaking programmeert, totale overkill in veel andere scenario's.

Jeetje miena, wat een uit de hoogte oordeel.
Het één sluit het ander niet uit. Het zijn verschillende werktuigen die je kan benutten om te werk goed te kunnen doen. En daarin kunnen ze elkaar zelfs aanvullen. Bijv hot reload gebruiken tijdens een TDD traject, om nog snellere iteraties te doen: testen draaien elke keer dat je saved.

Wat een onzinnig statement. M.i. is hot reload vooral handig als je resultaat afhangt van een bepaalde state (bijvoobeeld ui), en dan is het gewoon handig en snel als je deze functie hebt. Dat is gewoon een andere manier van ontwikkelen die niet beter of slechter te noemen is (tenzij je echt de complete context weet waarin de programmeur werkt, en dan nog kan het persoonlijke voorkeur zijn).

Ik snap de ophef niet. Ik gebruik .net core dagelijks en Microsoft heeft heel veel werk hooi op de vork genomen met alles dat ze in .net6 wilde stoppen.

Dat sommige features het niet redden bij de release omdat ze te onaf zijn of teveel capaciteit kosten die elders nodig is om een release af te krijgen. Dan moeten er keuzes gemaakt worden.

Ik zou van Microsoft verwacht hebben dat deze feature doorgeschoven zou worden naar .net7.

Zelf hoop ik dat MAUI een keer goed begint te werken.

[Reactie gewijzigd door jorisvergeerTBA op 24 oktober 2021 12:19]

Als de feature daadwerkelijk niet af had geweest, dan hadden ze hem volledig doorgeschoven, zodat deze dus ook niet in VS zou zitten.

In plaats daarvan lijkt het alsof een feature die gewoon compleet is (zie: VS) kunstmatig afgeknepen wordt.

Nou, mijn ervaring is helaas dat hot reload useless is en een hoop ellende geeft. Leuk voor hello world, en zelfs daar werkt het niet vlekkeloos, maar onbruikbaar in de dagelijkse praktijk.

Wat een onzin. Ik gebruik het dagelijks in grote solutions. Ik ben nog steeds zwaar onder de indruk. Laatst heb ik zelfs runtime properties toegevoegd en gebind aan mijn view zonder te hoeven herstarten. Sommige dingen werken ook niet zoals renames, maar al met al is het een indrukwekkende feature die nergens anders te vinden is voor zover ik weet.

maar al met al is het een indrukwekkende feature die nergens anders te vinden is voor zover ik weet.

Hangt er van af... weet dat in de java hoek er in ieder geval ook dergelijke features (commercieel) als plugin beschikbaar zijn om development code te hot-reloaden (JRebel). Functioneert ook daar niet voor alles, maar wel voor veel (volgens mij, afgeleid van het observeerbaar gedrag, door tijdens classloading de class te vervangen door een wrapping-proxy die bij iedere access checkt of de on-disk class gewijzigd is en zoja het object achter de proxy te vervangen door een instantie van nieuwere class)

Visual Basic, al sinds voor ICQ bestond.

Nee, dat was/is "continue and edit" "edit and continue", dat is niet hetzelfde als hot reload.

[Reactie gewijzigd door RobIII op 24 oktober 2021 16:30]

Granted, maar ze waren een heel eind op weg, in 1996.

Erlang. Sinds decennia.

[Reactie gewijzigd door Sandor_Clegane op 24 oktober 2021 15:33]

Ligt er misschien aan wat je ermee doet, maar ik ontwikkel mee aan blazor en Mobile Blazor bindings (nu onderdeel .net 6) en ik heb issues gehad met de razor compiler, source generators, de linker (die tree shaking doet voor client side blazor) etc. Daar krijg je echt de gekste effecten. En dat is nou juist één van de platformen waar het voor gemaakt is.

.NET 6 is nog niet officieel uit. Ik verwacht dat ze dat in komende releases en met VS2022 in aantocht wel zullen fixen.

En dit gaat over hot reload, niet over edit and continue. Het is onderdeel van .NET 6, en nergens anders onderdeel van. Tenzij je ontwikkeld hebt aan .NET 6 of alfa / beta builds hebt gedraaid, heb je er nog geen ervaring mee.

feature die nergens anders te vinden is voor zover ik weet.

*Every other JS framework wants a word with you

Zo'n comment vraagt om voorbeelden, die je niet geeft.

Zelf gebruik ik hot reload vrij regelmatig in een .NET Framework 4.8 met MVC5.2 applicatie, waarbij ik best tevreden ben. Sure, some moet je toch restarten, omdat je te veel aan een klasse hebt veranderd en de state niet te herstellen is. Maar ja, vroeger moest je altijd restarten.

Hot reload is juist een feature van vs2022 die het wel goed doet bij mij. Andere dingen als de nieuwe intellisense en bepaalde debugging features crashen regelmatig bij mij of worden super laggy over tijd. Ik moet vs22 wel een paar keer per dag opnieuw opstarten.

[Reactie gewijzigd door MeMoRy op 25 oktober 2021 04:06]

Dat is dus geen hot reload, maar edit and continue.

In VS zit waarschijnlijk een andere implementatie van hot reload dan de implementatie in dotnet watch.

Dit was niet een "niet redden", maar een commerciële beslissing om er een betaalde feature van te maken i.p.v. het als vrije software te leveren, ondanks eerdere toezeggingen.

Heb je bewijs van deze claim?

Het probleem is niet dat de middelmatig werkende functie die in de release candidate zat, wordt verwijderd in de release.
Het probleem is dat Microsoft aangaf dat de functie werd verwijderd en alleen beschikbaar zou worden gemaakt in Visual Studio.

Visual Studio (niet te verwarren met VS Code) is een freemium closed source project en is niet beschikbaar onder Linux. .NET (core) is een open source project en werkt op meerdere platformen.
Het weghalen van bepaalde functionaliteit uit een open source project (met als doel om betaalde MS software of services te promoten) ondermijnt het vertrouwen dat developers hebben in dit ecosysteem.

Ik gebruik toch echt liever visual studio code dan visual studio.

Appels en peren. Heel andere tools.
Ik gebruik ze zelf naast elkaar, omdat ze eigen krachten en zwaktes hebben.

Ligt eraan, voor bepaalde tooling (Unity) is de debugger in VS vele malen beter dan die in Code.

Hoezo dan eigenlijk, want de normale versie is in feite veel uitgebreider.

"Hoezo dan eigenlijk, want de normale versie is in feite veel uitgebreider."

En veeeeeeeeeeeeeeeel trager

En veeeeeeeeeeeeeeeel trager

Wat eigenlijk een prestatie van formaat is, als je nagaat dat Visual Studio grotendeels C# en C++ is - waar VSCode binnen Electron draait en voor een zeer groot deel bestaat uit TypeSscript.

Geeft je ook te denken over het feit dat het team wat verantwoordelijk is voor Office, aangekondigd heeft af te stappen van Electron voor MS Teams - zogenaamd omdat het niet schaalt, met de connotatie dat daar de traagheid en stroperigheid in dat product vandaan zou komen. VSCode is het levende bewijs dat dat dus niet het geval is, of tenminste: hoeft te zijn.

[Reactie gewijzigd door R4gnax op 24 oktober 2021 19:07]

Die laatste PR is wel echt een stukje komedisch goud!

Ah ja de mannen van Xamarin, en de meeste Microsoft werknemers die bijdragen doen aan .NET, werken vooral op MacOS hé

Oeps, als reactie op @PieterjanDC bedoeld.

Maar daar heb je natuurlijk ook gewoon een Visual Studio versie voor. Ik vind hem echter wel vreselijk, maar ik heb begrepen dat de komende release een heel stuk beter wordt. Er komt dan een echte native MacOS UI voor.

[Reactie gewijzigd door xFeverr op 24 oktober 2021 13:09]

Nee, bepaalde versies van Visual Studio kosten geld.