Software-update: Microsoft Visual Studio 2017 15.9.12

Microsoft heeft versie 15.9.12 van Visual Studio 2017 uitgebracht. Deze populaire programmeerontwikkelomgeving beschikt over handige opties om het programmeren in onder andere Visual C++, Visual Basic, C#, F#, Python en R makkelijker te maken. De hele waslijst veranderingen van de 2017-uitgave kun je nalezen in de bijbehorende releasenotes. De wijzigingen van deze uitgave zien er als volgt uit:

Issues Fixed in 15.9.12

These are the customer-reported issues addressed in 15.9.12:

• Access violation C++ /CLI 15.9.5 ISO C++ Latest Draft Standard since 15.9.5.
• An error occurred loading this property page (CSS & JSON).
• Visual Studio 2017 crashing when editing package.json.
• Opening package.json locks up Visual Studio.
• PGO Code Gen Bug - Vectorized instruction accessing memory OOB.
• Bad code gen in recursive bucket split routine.
• Compiler optimization bug in 15.8.9.
• We have fixed a linker error LNK4020 when using PCH, /Zi, and /GL in distributed build systems, such as IncrediBuild. The C++ compiler backend now correctly associates CIL OBJs with their corresponding compiler generated PDB when generating debug info for cross-module inlining.

Security Advisory Notices

• CVE-2019-0727 Diagnostics Hub Standard Collector Service Elevation of Privilege Vulnerability
  An elevation of privilege vulnerability exists when the Diagnostics Hub Standard Collector Service improperly performs certain file operations. An attacker who successfully exploited this vulnerability could delete files in arbitrary locations. To exploit this vulnerability, an attacker would require unprivileged access to a vulnerable system. The security update addresses the vulnerability by securing locations the Diagnostics Hub Standard Collector performs file operations in.

Versienummer	15.9.12
Releasestatus	Final
Besturingssystemen	Windows 7, Windows Server 2012, Windows 8, Windows 10, Windows Server 2016
Website	Microsoft
Download	https://docs.microsoft.com/nl-be/visualstudio/releasenotes/vs2017-relnotes#15.9.12
Licentietype	Freeware/Betaald

Reacties (13)

[Anoniem: 426269]

Waarom zou je dit nog nemen als 2019 er al is? Die heb ik al meer dan een maand geleden geinstalleerd.

// edit: Aha, er komt dus iets meer bij kijken, net zoals bedrijven niet zomaar van de ene Windows versie naar een nieuwere versie kunnen overstappen.

Ik ben een beginner hierin en had ongeveer 2 maanden geleden voor het eerst VS 2017 geinstalleerd. Ik dacht dat het een gratis programma was. Dan zal ik van 2017 de Community versie gehad hebben. Ongeveer een maand daarna kwam 2019 uit en die heb ik toen geinstalleerd. Ik vond het ook al een beetje raar dat ik ze beiden tegelijk geinstalleerd kon hebben staan. Toen maar de 'oude' 2017 gedeinstalleerd. En ik zie nu dat mijn 2019 geen Community versie is en mijn trial verlopen is. Dank u, ik ben weer wakker.

[Reactie gewijzigd door Anoniem: 426269 op 22 juli 2024 22:25]

[Zezura]

Vs2019 heeft een verschrikkelijke bug.
Als ik een wijziging maak in de code. En opnieuw debug. Dan bouwt hij alleen een OBJECT. En runt vervolgens een oude build. Dat is heel lastig als je wil debuggen omdat je oude code zit te debuggen. Nu moet ik bij elke verandering aan code een solution clean doen.

Kinderziektes

[mrFoce]

Ben dat zelf niet tegengekomen. Het lijkt mij ook vrij sterk dat zo'n extreme bug in de RTM versie komt voor alle projecten. Ik neem aan dat je je best gedaan hebt om dit te melden via https://docs.microsoft.co...isual-studio?view=vs-2019

Zelf ben ik enkele bugs tegengekomen in Visual Studio 2019 maar dat was altijd in functionaliteit die niet elke developer gebruikt. Tot nu toe is het altijd opgelost in de patches.

[faim]

Dit betreft een update? Bedrijven die een jaar geleden allemaal licenties hebben aangeschaft voor 2017 zullen nu niet direct gaan overstappen naar 2019.

[jp]

Als je in een VS2017 project aan het werk bent, zie ik geen reden om ineens je IDE te upgraden als de oude nog ondersteund wordt, om eens wat te noemen.

[MaestroMaus]

Omdat sommige organisaties afspreken welke tooling ze gebruiken voor een bepaald project en niet van deze tooling af mogen wijken tenzij er een wijziging gedaan wordt van de afspraken. Dit voorkomt dat verschillende programmeurs met verschillende tools voor problemen gaan zorgen en maakt het makkelijker vanuit de software beheer kant om de teams te ondersteunen.

[Reactie gewijzigd door MaestroMaus op 22 juli 2024 22:25]

[Rub3s]

Ik vind 2019 nog niet helemaal bruikbaar. Ik kom nog wel es een probleem tegen, bijvoorbeeld als ik werk met entityframework (database first). Bij een update van de database wordt dan het model bijvoorbeeld niet geupdate. Bij sommige projecten lijkt ie ook allerlei classes, namespaces niet te herkennen, terwijl die projecten prima werken in 2017.

[mvhorssen]

Ik kan legio redenen bedenken waarom je nog niet overgaat naar Vs2019.

Voor mij persoonlijk heb ik Vs2017 geïnstalleerd staan voor de C++ compiler. Ik gebruik deze om mijn Qt projecten op Windows te compileren. Visual studio 2019 is nog niet ondersteund vanuit Qt, vandaar dat ik Vs2017 gebruik

[faim]

Visual Studio 2017 crashing when editing package.json.

Prettig

[sjongenelen]

Haha da's ook een manier om iedereen aan PackageReference te krijgen

[R4gnax]

Haha da's ook een manier om iedereen aan PackageReference te krijgen

Geschoten en mis.

Het package.json bestand is gerelateerd aan Node.js en NPM, niet aan NuGet.
Jij zit te denken aan het packages.config bestand.

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

[sjongenelen]

Ahh je hebt gelijk

[R4gnax]

Je moet package.json sowieso al niet met de hand bijwerken binnen de workflow die Microsoft probeert aan te bieden. Dat heeft namelijk ZEER onwenselijke neven-effecten.

Wat Microsoft doet is een file-system watch op package.json zetten. Bij wijzigingen draaien ze onder de kap het kale npm install commando. En daar zit het probleem. Dat commando loopt je package installatie langs en werkt deze van begin tot eind bij.
Ja; dat installeert ontbrekende packages. Alleen als neveneffect werkt het ook andere packages bij naar nieuwere versies, waar de version range dat toelaat.

Op dat moment wordt ook het package-lock.json bestand bijgewerkt en kunnen deze andere bijgewerkte packages dus potentieel onder de radar mee gaan in deployments, zelfs als deployments vanaf build servers ingericht zijn om zoals hoort via het npm ci commando de exacte versies uit het lock bestand te installeren en niet anders.


Als Microsoft de editor experience voor package.json een beetje degelijk hadden geschreven, dan hadden ze een diff gemaakt tussen de nieuwe en oude inhoud wanneer de gebruiker het bestand opslaat, en daaraan gekoppeld aparte npm install package@version uitgevoerd. Dan zou je dit probleem niet hebben.

Maar ja; zoals gewoonlijk bij alles wat niet C# is, gaat het Visual Studio team tekort door de bocht.
(Maak me trouwens wakker wanneer hun code completion voor Less verder reikt dan hoe die taal er ca. versie 1.5 in 2014 uit zag.)

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