Software-update: Microsoft Visual Studio 2017 15.8.9

Microsoft heeft versie 15.8.9 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:

Top Issues Fixed in 15.8.9

These are the customer-reported issues addressed in 15.8.9:

• Added support for Xcode 10.1 in Visual Studio Tools for Xamarin.
• Updated the Xamarin.Forms template to Xamarin.Forms 3.3.0.
• Update 15.8.6 breaks Installer Projects.
• Internal Compiler error in VS15.8 msc1.cpp line 1518.
• Microsoft Visual Studio 2017 Installer Projects 0.8.8 and VS 15.8.6.
• SFINAE fails to detect matching overloaded function in preview VS preview 3 15.9.0.
• XAML Designer crash on Visual Studio close.

Versienummer	15.8.9
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 (10)

[kdekker]

De (veel) hogere frequentie van uitleveren van Visual Studio heeft voordelen (bugs worden eerder opgelost) maar ook nadelen. Als je een infrastructuur hebt waar op meerdere machines dezelfde versie van Visual Studio moet draaien, dan levert de hogere frequentie van updates behoorlijk wat meer werk op.

Automatisch uitrollen van dit soort updates (in een bedrijf waar het gros van de systemen geen Visual Studio heeft en daardoor voor de IT afdeling niet op hun netvlies staat c.q. in de test procedure) is een mogelijkheid. Maar als een product een codefreeze heeft dan wil je niet dat tijdens de test periode en mogelijke rebuild ondertussen Visual Studio bijgewerkt wordt. Een update van Visual Studio kan ook weer nieuwe bugs opleveren + je oorspronkelijke product is niet meer te bouwen. Zeker omdat niet makkelijk te zien is wat er in een update zit (bijv. als de runtime aangepast wordt is minder erg dan een core part als compiler).

Al met al was die 1x per langere tijd updates (zoals voor Visual Studio 2015 het geval was) zo gek nog niet. Vroeger waren dingen soms beter

Sowieso is de tendens dat ieder (Microsoft) product zijn eigen updates uitrolt (en niet of minder via Windows updates) lastiger i.c.m. eisen voor downtime/maintenance time windows. Een geautomatiseerde/gedistrueerde update houdt daar (in ons bedrijf: nu) geen rekening mee. Als eindgebruiker c.q. systeembeheerder wil je ook maintenance windows kunnen definiëren.

[Charlie_Root]

Het updaten van dit pakket is een eitje, gaat vanzelf. En binnen een grote omgeving heb je daar APP-V voor, gebruiken wij ook. Ik vind deze manier van updaten (zeker van MS!) erg goed en Visual Studio is een van de betere pakketten die ze ontwikkelen.

[kdekker]

Ik gebruik de procedure van https://docs.microsoft.co...isual-studio?view=vs-2017. Daarmee download je dus eerst de laatste setup en werk je de netwerk image bij. Dat duurt uren.

Een lokale instance bijwerken is geen punt, maar dan download je wel iedere keer diezelfde tig GB. Ik ben zelf ontwikkelaar, geen systeembeheerder. Al doe ik dat laatste voor development systemen erbij, omdat IT daar geen kaas van gegeten heeft c.q. geen rekening kan/wil houden met mijn codefreezes en ongeschikte tijden voor downtime. Visual Studio draait met name op een stel (terminal server) systemen, maar ook op lokale PCs/laptops. Als je een update doet, moet liefst alles tegelijk (daar je reproductie van een probleem wel met dezelfde visual studio versie wilt doen).

Ik heb 1x in mijn migratie traject naar Visual Studio 2017 gezien dat de gegenereerde output (die we heel soms in ons versiebeheer systeem opslaan, wat een uitzondering is, omdat je normaal gesproken alleen sources opslaat en het resultaat iedere keer opnieuw bouwt) van formaat wijzigde. En een nieuwere VS2017 versie vertikte om de vorige versie pdb/lib files te slikken.

Ik ken APP-V niet, maar een eigen uitrol structuur verzinnen die afwijkt wat onze IT afdeling gebruikt (voorheen SMSS, nu een ander product) is niet mijn kerntaak.

[ZwarteIJsvogel]

Dan lijkt mij het volgende ook relevant:
https://docs.microsoft.com/en-us/visualstudio/install/controlling-updates-to-visual-studio-deployments?view=vs-2017.

Je zou het zo moeten kunnen maken dat VS2017 deployments voor updates alleen kijken naar de lokale installatie layout. Het updaten controleer je dan door de layout te updaten op een geschikt moment. Je kunt dan ook twee layouts maken: één voor testen en één voor productie.

[Reactie gewijzigd door ZwarteIJsvogel op 23 juli 2024 16:52]

[kdekker]

Ik vind het alleen gestoord dat bijwerken vanuit visual studio zelf meestal slechts 10 minuten of zo duurt, maar een offline installer bijwerken veel meer (werkelijk uren, nie normaal meer). Ik test meestal eerst zelf lokaal een visual studio versie, voordat ik de share bijwerk. Daarna is het aan de gebruikers om of via de share of via de reguliere update notifications een update te doen.

[robertpNL]

VS draait meestal bij de developer op zijn lokale systeem of laptop. Hij of zij kan zelf weten wanneer te moeten updaten. Het update alleen de IDE, niet het Framework.

[OMX2000]

Ik snap je punt mbt nadelen van vaak releasen. Maar in mijn ogen moeten developer gewoon zelf hun machines inrichten en beheren. Het is al lang niet meer zo dat Visual Studio bij een nieuwe release incompatibele solutions/projecten oplevert, dus je hoeft niet meer heel conservatief te zijn met welke Visual Studio versie je installeert. Minimum requirements voor een project zijn handig, maar meer ook niet.

De regelmatige updates vind ik niet meer dan normaal, die enorme codebase van Visual Studio kan nogal veel bugs bevatten. En 1 jaar wachten op een update is dan nie heel fijn.

[Jogai]

Je hoeft toch niet te updaten? Ik probeer altijd wel bij te blijven, maar sla op het werk ook wel eens wat minor releases over.

[fdm391]

...
Automatisch uitrollen van dit soort updates (in een bedrijf waar het gros van de systemen geen Visual Studio heeft en daardoor voor de IT afdeling niet op hun netvlies staat c.q. in de test procedure) is een mogelijkheid. Maar als een product een codefreeze heeft dan wil je niet dat tijdens de test periode en mogelijke rebuild ondertussen Visual Studio bijgewerkt wordt. Een update van Visual Studio kan ook weer nieuwe bugs opleveren + je oorspronkelijke product is niet meer te bouwen. Zeker omdat niet makkelijk te zien is wat er in een update zit (bijv. als de runtime aangepast wordt is minder erg dan een core part als compiler).
...

Het builden danwel packagen en releasen van software zou tegenwoordig toch wel via een build server/service moeten lopen en niet lokaal moeten gebeuren. De buildserver kun je dan simpelweg niet updaten tijdens een codefreeze/testperiode/whatever.
Developers kunnen lokaal VS updaten, mocht dat tot problemen leiden (breekt build oid), ligt niet direct heel je proces op z'n gat... Sowieso kunnen developers dan binnen het team direct die kennis delen en hoeft niet iedereen tegelijk versie te jumpen.

'It works on my machine' is iets dat je in principe nooit wil horen... (natuurlijk bestaat het probleem nog wel met een buildserver, maar is het een stuk minder problematisch en tijdrovend)

[fruumel]

Er zit nog steeds een lelijke bug in deze versie, nl bij het toevoegen van een nieuwe database en je maakt een tabel aan dan crasht VS na drukken van de update knop, de tabel is dan ook niet aangemaakt. Zeer irritant....