Software-update: Visual Studio Code 1.86.2

Visual Studio Code logo (79 pix) Visual Studio Code is een opensourcecode-editor met ondersteuning voor IntelliSense, debugging, Git en code snippets. Downloads zijn beschikbaar voor Windows, Linux en macOS. Ondersteuning voor de gangbare script- en programmeertalen is aanwezig en het kan daarnaast via extensies uitgebreid worden. Microsoft heeft versie 1.86.2 uitgebracht en hierin zijn de volgende verbeteringen aangebracht:

Update 1.86.2: The update addresses these issues:

Visual Studio Code

Versienummer 1.86.2
Besturingssystemen Linux, macOS, Windows 10, Windows Server 2016, Windows Server 2019, Windows 11
Website Microsoft
Download https://code.visualstudio.com/#alt-downloads
Licentietype GPL

Door Bart van Klaveren

Downloads en Best Buy Guide

15-02-2024 • 17:30

14

Submitter: guidogast

Bron: Microsoft

Reacties (14)

14
14
6
0
0
7
Wijzig sortering
Vraagje voor de VS Code gebruikers: Ik gebruik nu Eclipse in een Linux VM, met een remote X-server (VcXsrv) op mijn Windows-10 desktop. Dat werkt als een tierelier. Die setup probeer ik ook met VS Code, maar dat is extreem traag. Gewoon wat code inkloppen is bijna niet te doen, elke toetsaanslag heeft dikke vertraging.

Is er onder de Tweakers iemand die een zelfde setup gebruikt en dat goed werkend heeft? Is dit een bekend probleem?
VS Code gebruikt standaard hardwareversnelling, wat soms problemen kan veroorzaken bij gebruik over remote X-server verbindingen. Je kunt proberen hardwareversnelling uit te schakelen om te zien of dit de prestaties verbetert.
Waarom draai je VS Code niet gewoon op de desktop?
Makkelijker om binnen vscode met SSH te connecten naar je vm met de 'Remote Ssh' plugin.
Precies, zo doen wij dat ook
Ik hoop toch niet voor productie?

Waarom niet gewoon lokaal, en dan met Git je changes pushen en binnenhalen?

SSH is ongelofelijk langzaam, wel veilig(er), maar nog altijd wel gedoe. Ik zou het enkel gebruiken in noodgevallen, maar persoonlijk zou ik eerder mijn workflow aanpassen.
nee, niet voor productie. Onze dev server kunnen we alleen met SSH bereiken (intern gelukkig). Op de windows bak developen gaat niet lukken, sommige libs zijn linux only. Docker mag niet van ICT op de windows machines.
Dus, VScode lokaal, dat mocht nog net, en met SSH naar de dev server. Vandaar naar git en na checks pas door naar prod.
Wij werken met VSCode en de remote-WSL-extension op WSLg van Windows 11. Dat werkt echt wel prima, near-native. Met behulp van WSLg kunnen we met Cypress werken. Met WSLg kan je Linux applicaties starten, die dan als Windows verschijnen. Dit is echt wel beter als Windows 10 en een lokale x-server-client (vcx…).
Een leuk truukje die ik gebruik voor de ontwikkelomgeving is om de Cypress-docker-container als basis te gebruiken voor een custom WSL-Distro. Dezelfde Cypress-docker-container gebruiken we om in te builden en testen. Hiermee hebben we geen last van omgevingsverschillen tussen dev en CI. Tevens hoeven we niet zelf de omgevingen (met browsers in de container) te onderhouden, dat doet Cypress voor ons.

[Reactie gewijzigd door Shorty24 op 27 juli 2024 15:36]

Ik stel voor dat je onze onderbezette ict afdeling even belt. Wellicht hebben ze in 2028 tijd
:-) Als je het telefoonnummer geeft, bel ik je "ict afdeling met verkeerde prioriteiten" wel even..
Beveiliging, zeker weten dat iedereen dezelfde versie van VS Code heeft draaien, met dezelfde versies van plugins, wat met een remote VS Code instantie flink wat gemakkelijker is. Ook een stuk minder tijdrovend om dat centraal op te zetten en bij te houden. Daarnaast heb je ook meer mogelijkheden met toegangsbeheer.

Dat zijn voordelen die ik zo 1-2-3 kan bedenken waarom een bedrijf een remote versie van VSCode wil draaien. Nu weet ik ook wel dat lokale VS Code instanties op meerdere ontwikkelcomputers/-laptops gelijk te trekken zijn aan elkaar. Maar het heeft wel meer voeten in de grond en is minder zeker. Toegangsbeheer is ook wel te doen, maar is opnieuw minder zeker en als de dev wat uit wil testen op een ontwikkelserver die ook op de lokale computer/laptop draait, hoeveel data blijft dan achter op die lokale VS Code instantie?

In een ideale wereld? Niets. Maar VS Code is verre van ideaal, want het is en blijft een Microsoft product, welke meestal goed genoeg zijn gemaakt, maar nooit perfect ("perfect" is tenslotte de vijand van "goed"), want producten moeten woren geleverd.

En legio mensen die hun werkcomputer/laptop niet netjes behandelen en/of kwijtraken. Mogelijk belangrijke data en/of code kan daardoor zijn weg vinden in onguurdere kringen. Een remote instantie van VS Code heeft daar praktisch geen enkel last van.

Toegegeven, latency is zeer zeker een ding met remote VS Code instanties, maar als de data/software belangrijk genoeg is, dan is de keuze al snel gemaakt. Nu draai ik 'voor funsies' een remote VS Code instantie in mijn lokale netwerk. Een netwerk wat ik zelf in elkaar heb gezet, zelf de kabels voor heb gemaakt, zelf de netwerk-apparatuur voor heb geconfigureerd. En ik merk erg weinig van latency met de op mijn netwerk gehoste VS Code instantie.

Niet om mezelf schouderkloppen te geven, maar de tijd die aan het netwerk is besteed, stelt me wel in staat om gauw elke mogelijke bron van latency te achterhalen en er ook wat aan te doen in een redelijke tijdsspanne. Een voordeel wat je met de cloud al gauw kwijtraakt. En tsjah...latency houdt al snel in dat werknemers en/of bedrijfsprocessen extra tijd moeten besteden. Tijd waarvoor de cloud-provider betaald wil worden.

Opzichtig kan men dat niet maken, maar met genoeg "random" latency komt er stiekum toch een leuke zakcent binnen voor de cloud-provider. En als jij denkt dat jouw cloud-provider daarboven staat...het zijn veel kleine beetjes die wel degelijk helpen, want het zelf beheren van datacenters, dat mag dan een leuke omzet opleveren, de kosten van energie en koeling drukken flink op de winst.
In het geval van VS code zou ik een dergelijke plugin gebruiken:
https://marketplace.visua...code-remote-extensionpack

Eclipse biedt iets vergelijkbaars (https://eclipse.dev/tm/), maar er zal vast een goede (? :+) reden zijn dat deze oplossing niet voor jou werkbaar is.
Ik gebruik vscode met WSL, geen idee of dat soortgelijk is, maar werkt helemaal prima voor mij.
Er is ook een prima integratie vanuit vscode mogelijk met Remote.
VS Code draait hier als een zonnetje native op Apple silicon (M2 Pro)

Op dit item kan niet meer gereageerd worden.