Software-update: Microsoft Visual Studio 2017 15.9.2

Microsoft heeft versie 15.9.2 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.2

These are the customer-reported issues addressed in 15.9.2:

• MFC EXE (binary) size is 5 times bigger in VS 15.8 (_MSC_VER = 1915).
• Key 'OPENSSH' is not supported.
• Windows magnifier can no longer track keyboad cursor.
• Analysis fails with immediately-invoked lamba in while loop.
• Xamarin iOS designer not working with 15.9 and Xamarin.iOS 12.2.1.10.
• We improved the reliability of incremental linking for large C++ projects.
• LNK2001 "unresolved external symbol" errors for certain vector deleting destructors will now be resolved.
• Compiler execution time has been improved for code that makes heavy use of chained, inline functions involving lambdas or local classes as parameter or return types.

Versienummer	15.9.2
Releasestatus	Final
Besturingssystemen	Windows 7, Windows Server 2012, Windows 8, Windows 10, Windows Server 2016
Website	Microsoft
Download	https://www.visualstudio.com/downloads/
Licentietype	Freeware/Betaald

Reacties (20)

[kdekker]

Als er gebruikers van visual studio 2017 zijn: hoe houden jullie de hoge update frequentie bij als je een hele rij systemen in 1 organisatie wilt gebruiken, waar iedereen dezelfde versie moet hebben? De frequentie is voor mij te hoog. En het gevaar is groot - als iedereen zijn eigen VS2017 bijwerkt - er verschillen ontstaan. Bijvoorbeeld bugs in de output (C/C++) die versie afhankelijk is. Niet fijn voor reproductie... en debuggen...

Hier staat wel waarom MS sneller released, maar niet hoe je dat managed.

[Reactie gewijzigd door kdekker op 25 juli 2024 18:39]

[MeMoRy]

In het laatste sw bedrijf waar ik heb gewerkt hadden we daar de configuration manager voor: een persoon die precies daar verantwoordelijk voor is. Sowieso was het niet de bedoeling om zelf tools van het web te halen: alles werd geïnstalleerd vanaf een netwerkstation. Die werd ook gebackupt, omdat het nodig was specifieke tools te waarborgen. Soms moesten we nog bugs in 25 jaar oude producten oplossen en dan wil je niet switchen naar de nieuwste tools, omdat die niet altijd 100% backwards compatible zijn.
Vaak werd er niet eens geupdate naar de meest recente versie van een tool: je update alleen als het nodig is.

[Reactie gewijzigd door MeMoRy op 25 juli 2024 18:39]

[kdekker]

Zo'n netwerk share bijwerken, a la de instructies op https://docs.microsoft.co...isual-studio?view=vs-2017 is geen pretje. Een update vanuit een notification is meestal in een kwartiertje (of minder) gepiept, maar bij werken van de hele setup duurt gerust uren. Ik ga eens kijken of de --clean optie helpt.

Update: die clean vereist dat je zelf uitzoekt wat je obsolete vindt. Bepaald niet handig. Zo langzamerhand lijkt het hele concept 'update van een share die door een admin bijgehouden wordt' zoveel meer tijd te kosten dan 'doe het zelf om de zoveel tijd', dan ik voor die 2 omgevingen die ik consistent wil houden het wel op die manier doe. En gebruikers op hun eigen PC hun eigen keuze maken welke updates ze willen. Er zal vast een betere methode zijn, maar ik heb er nu geen tijd voor.

[Reactie gewijzigd door kdekker op 25 juli 2024 18:39]

[MeMoRy]

Het was een groot bedrijf, dus ze konden het zich veroorloven om iemand aan te nemen die dat voltijd deed

[Maxxi]

Iemand die full time innovatie mag tegenhouden?

[majetta]

Hou het op minor (15.9) releases tenzij je tegen een specifiek issue aanloopt dat in een update (15.9.1) release wordt verholpen.

de aanpassingen na een minor release zijn meestal bug fixes die door de community wordt aangekaart.

[o_f_course]

... en dus die zijn niet relevant?

[Franckey]

Bij ons hoeft niet iedereen dezelfde versie van Visual Studio te hebben. Wat je lokaal gebruikt maakt niet uit. Wat er naar de testomgevingen en productie gaat komt van build agents (vm's die code ophalen, builden, testen en het resultaat ergens neerzetten).

[MeMoRy]

Het gaat uitmaken als je dependancies hebt met externe tools, bijvoorbeeld al met CUDA.

[Olaf van der Spek]

Bijvoorbeeld bugs in de output (C/C++) die versie afhankelijk is

Hebben jullie vaak dat soort bugs? Zijn het code generation bugs of bugs in jullie eigen code?
Helpen automatische tests niet?

[kdekker]

Gelukkig heel zelden.

We hebben (1000-den) automatische tests. En dit soort bugs gebeurt zelden (een handvol keren in de afgelopen 20 jaar). Maar zijn heel erg lastig te vinden. Ik heb in de afgelopen 2 jaar 2x gehad dat 1 server een optelling (assembly) van een float met 1 een half uur niet werkte. En daarna, zelfde binaries, wel. En een paar keer optimizer bugs (waar meestal wel een code workaround voor geschreven kon worden).

En gedurende de tijd dat ik bezig was met de overstap van VS2015 naar 2017 heb ik 1x een probleem gehad dat de build resultaten van een oudere VS2017 build (die wij voor 1 component om praktische reden opslaan in ons versiebeheer systeem) niet meer compatibel waren met een nieuwere VS2017 versie. Dat zijn redenen (voor mij) om toch wel voor de test en productiebuild machines 1 versie van de compiler te willen gebruiken.

[o_f_course]

Ons team zit steeds op dezelfde build.
Problemen hadden we vooral bij overgang van 2015 naar 2017 met alle language syntactic sugar spullen van C#.

Wij updaten zoveel mogelijk mee, maar incidenteel is er een breaking change (waardoor een andere 3rd party product niet goed samenwerkt) en houden we onderling op de hoogte dat deze versie even nog niet geïnstalleerd moet worden. De buildserver heb ik geen idee van, maar volgens mij loopt die steeds ietsje achter.

Ik heb nog geen problemen gezien die jij nu beschrijft.

[EchoWhiskey]

"de hoge update frequentie"

Dat was mij ook al opgevallen. Heb volgens mij in de afgelopen 2 weken 3 updates moeten installeren.
Wij hebben ongeveer 10 devs en een OTAP straat, waarbij overigens niet iedereen op exact hetzelfde moment update.
Het al dan niet updaten van Nuget packages bij oudere projecten is voor ons een grotere issue.
Aangezien we veel micro services hebben, kunnen die over het algemeen met oudere versies blijven werken, tenzij er gegronde redenen zijn om die te updaten.

[majetta]

de wekelijkse updates kan je overslaan tenzij er een fix in zit die je nodig hebt. je kan zonder problemen een alle updates overslaan tot de volgende major of minor release.

[Kriekel]

Weet je of er een manier is om de gele update knop te verbergen? Hij is gelukkig niet rood, maar trekt nog steeds mijn aandacht en dan moet ik updaten van mijzelf.

[Olaf van der Spek]

Hij is gelukkig niet rood, maar trekt nog steeds mijn aandacht en dan moet ik updaten van mijzelf.

Ik neem aan dat je de notificatie elke keer handmatig kunt verrwijderen.

[Olaf van der Spek]

de wekelijkse updates kan je overslaan

Je kunt ze ook net zo goed wel installeren toch?

[majetta]

Ja dat kan, na testen.

maar soms zitten er feature-breaking bugs erin, die je pas nadat je ermee aan de slag gaat opmerkt, zo hebben wij gelukkig op een test bak ontdekt dat de SSIS Catalog deployment niet meer vanaf een remote machine uit Visual studio kon.

Nou gerapporteerd bij microsoft, 4 releases later zit het er nog steeds in.

[psychicist]

Draait Visual Studio 2017 nu ook native op ARM zodat je x86_64 en ARM64 binaries kunt compileren op Windows 10 ARM64?

[Matthijs Hoekstra]

VS draait niet native op ARM (hoeft ook niet) maar kan nu wel naar ARM64 compileren.