In veel van mijn artikelen moet ik constateren dat Microsoft-producten te vaak problemen en ook veroorzaken, van de installatie tot het dagelijks gebruik. Natuurlijk zijn er tal van gebruikers van Microsoft-programma's, zoals Office die na installatie zelden of nooit met al die problemen geconfronteerd worden.

Goed voor devs, goed voor Microsoft

Maar veel mensen komen met grote regelmaat problemen tegen in Windows of in een van de andere programma's van Microsoft. Ter illustratie gaat dit artikel gaat het over problemen met de ontwikkelomgeving Visual Studio en dan beperk ik me tot het installatieprogramma.

Er is Microsoft veel aan gelegen om ontwikkelaars gunstig te stemmen. Een ruime beschikbaarheid van toepassingen voor Microsoft-producten en software vergroot de kans dat deze in trek blijven of komen. Denk hierbij aan Windows 10-features zoals het ondersteunen van Tijdlijn of Windows Ink, voor de cloudomgeving Azure geschikte toepassingen maar ook Windows Universal Apps (UWP).

Visual Studio & UWP

Door het beperkte succes van de Windows Phone, gevolgd door het feitelijk laten vallen van het product is de aantrekkelijkheid voor ontwikkelaars van het maken van dit soort apps behoorlijk gereduceerd. In theorie is een UWP voor eindgebruikers aantrekkelijk. Zo'n programma wordt goed gecontroleerd voor het in de Store staat dus de kans op malware is zo goed als nul. Je betaalt aan Microsoft en Windows regelt de installatie en de updates.

Een belangrijke manier om ontwikkelaars te ondersteunen is het beschikbaar stellen van de tools om software te maken. Microsoft produceerde de ontwikkelomgeving Visual Studio. Hierin kunnen ontwikkelaars hun programmacode inclusief schermen en menu's en dergelijke schrijven, testen en er een eindproduct mee maken.

Visual Studio komt compilers voor diverse programmeertalen zoals C#, Visual Basic, C++ en F#. Een compiler controleert of de code technisch juist is en aan de regels voldoet en produceert dan het gewenste eindproduct, bijvoorbeeld een .exe-bestand. Programmertaalontwikkelaars kunnen hun eigen taal in Visual Studio opnemen; de compiler van die taal en projecten in die taal worden dan herkend en alle functionaliteit van Visual Studio is beschikbaar bij het werken met die taal; althans, de functionaliteit die de maker van die taal op de juiste manier aan zijn product "koppelt". Dat kan bij veel opties nog heel wat werk zijn.

Visual Studio Community

Sinds 2014 is de versie Visual Studio Professional in een licht afgeslankte vorm gratis te gebruiken voor ontwikkelaars die aan een aantal voorwaarden voldoen. Je mag het altijd gebruiken voor het ontwikkelen van open source software, Visual Studio-extensions, Windows-devicedrivers of opleidingsdoeleinden.

Voor alle andere applicaties mogen tot 5 mensen het product gebruiken mits de organisatie geen "enterprise" is; een enterprise is volgens de licentieovereenkomst een bedrijf met meer dan 250 mensen of meer dan een miljoen dollar omzet.

Deze versie heet Visual Studio Community en wijkt in vrij weinig af van de betaalde Professional. De meest in het oog springende afwezige is CodeLens. Hierbij kan de ontwikkelaar bij een methode (een stukje programmacode die een bepaalde deeltaak uitvoert binnen het programma) direct zien hoe vaak die code in bet programma wordt gebruikt en ook waar.

Dat kan handig zijn als je iets gaat veranderen in de code; die verandering die nodig is bij gebruik vanuit bijvoorbeeld scherm één is oké bij de aanroep vanuit scherm twee, maar als je direct ziet dat de code ook vanuit scherm drie aangeroepen kan worden waar de wijziging helemaal niet gewenst is zal je de programmering sneller aanpassen dan wanneer je dat niet ziet, zoals in de Community-versie. Met iets meer inspanning zie je da natuurlijk wel; door even te zoeken naar de verschillende aanroepen.

Installatie

Zelf heb ik jarenlang geprogrammeerd in een geavanceerde Windows-taal waarvan de 'roots' teruggaan tot de Clipper, dat weer een vervolgstap was op de database-met-programmmertaal-omgeving dBase. Cavo heeft ook vandaag nog zeer veel mogelijkheden al is de toegang tot vooral nieuwe technieken veel eenvoudiger te realiseren in zogenaamde .Net-talen. Cavo-gebruikers kunnen daarvoor terecht bij de .Net xBase (=gebaseerd op het oude dBase) taal X#.

Persoonlijk vind ik Visual Studio meer nadelen hebben dan voordelen qua opties en programmeergemak als ik het vergelijk met Cavo. Maar we hebben dus feitelijk Visual Studio nodig om alle opties in veel moderne programmeertalen te kunnen gebruiken, zoals het genoemde X#. Anderen zijn er weer wel enthousiast over, want ja, er kunt er dus heel veel mee. Nu is het interessant om eens te kijken of een product voor ontwikkelaars minder problemen geeft dan ik vaak zie bij Microsoft-producten. En het antwoord is helaas: nee.

Visual Studio 2017 heeft een geheel herziene installer, waarmee je eenvoudiger een basisinstallatie kan uitvoeren als je maar weinig functies nodig hebt. Als je zaken nodig hebt als ondersteuning voor mobiele platforms loopt de minimum installatie van een paar 100 megabyte al snel op tot boven de 20 GB. En als ik alle opties aankruis, buiten de 2 bovenste die al geïnstalleerd waren, dan komt daar maar liefst 22 GB bij, en dan zijn nog alleen de belangrijkste onderdelen aanwezig:

Op zich is de installer prima. Je kunt met Modify een installatie aanpassen, dus iets weghalen of toevoegen. Met Repair kun je een niet goed werkende installatie opnieuw neerzetten en je kunt er nieuwe versies mee ophalen. Maar voordat ik zo ver kwam was ik maar liefst 1,5 dag in uren verder!

Op mijn systeem stond een Visual Studio 2015 die ik nodig had om Vulcan (voorganger van X#) programma's te kunnen compileren. Inmiddels zijn deze omgezet in X#, dat dus wel in Visual Studio 2017 werkt en dan biedt Visual Studio 2017 toch meer mogelijkheden. Het start ook aanzienlijk sneller een project op; dit was de grote belofte van "2017", hoewel het een aantal updates kostte voor dat ook werkelijk zo was.

Verder kun je beide versies naast elkaar neerzetten, maar bij een eerdere poging vorig jaar werkte dat beslist niet. Een Indiase supportmedewerkster van Microsoft moest er aan te pas komen en de Visual Studio 2017-installatie werkte alleen als ze tussendoor steeds bestaande directory's in Visual Studio 2015 hernoemde. Omdat ik later op deze pc een schone Windows-installatie had uitgevoerd moest ik Visual Studio 2017 recent opnieuw installeren. Ik downloadde een setup van ongeveer 1 Mb van en start deze:

En hierna....niets. Geen melding, geen reactie. Ook niet als ik het draai als Administrator. Nu leert iedere beginnende programmeur dat als er iets niet werkt dat je dat duidelijk aan de gebruiker meldt. Die les is kennelijk aan de ontwikkelaars van Visual Studio voorbijgegaan. Wel staan er inmiddels 292 (!) log files in de %TEMP% directory. In een van die logs, dd_bootstrapper_20180707140024.log, staat de vermoedelijke oorzaak:

VisualStudio Bootstrapper:7-7-2018 14:00:24: General Failure. Message:Access to the path 'C:\ProgramData\Microsoft\VisualStudio\Packages\_bootstrapper' is denied.

Maar waarom? De installer vult zelf deze directory. Even zoeken op het internet levert vele (honderden) vergelijkbare problemen op, op ontwikkelaarsites als www.stackoverflow.com of https://developercommunity.visualstudio.com.

In de meeste gevallen antwoordt iemand van (of namens) Microsoft dat het probleem vergelijkbaar is met een ander probleem en wie de link volgt ziet daar dan ook vaak geen oplossing. Of er wordt gemeld dat de oplossing in een volgende release volgt. Ik probeer het, aan de hand van al deze berichten, met Windows Defender uit, via een clean startup (in te stellen vanuit MSConfig), vanaf een usb-stick en na het volledig de-installeren van VS 2015, inclusief handmatig alles verwijderen uit Programdata, Program files en Program files X86, want de de-installer houdt niet zo van opruimen. Niets werkt.

Dan start ik de installer op met de volgende opdracht:

vs_professional.exe --layout h:\vs2017layout --add Microsoft.VisualStudio.Workload.NativeDesktop --includeRecommended --lang en-US

Op schijf H: (een usb-station) wordt een soort offline installatie aangemaakt en als ik van daar uit vs_setup.exe draai, krijg ik dezelfde maar nu in ieder geval direct zichtbare foutmelding:

Dus de installer heeft geen toegang in een directory die het programma zelf heeft aangemaakt! En dat terwijl ik de installer vanuit een elevated (Administrative) prompt start en de volledige rechten heb op mijn pc.

Ik besluit een truc toe te passen. Tijdens de installatie selecteer ik in een Verkenner de net aangemaakte mappen en kies hier Take Ownership. Hiervoor heb ik dit programma geïnstalleerd. Het werkt, mits je niet te veel bestanden en niet te "diepe" serie directory's selecteert. En nu start eindelijk het installatieprogramma, maar na een tijdje gaat het alsnog mis:

Op mijn laptop ben ik eerder wel geslaagd met een installatie van Visual Studio 2017. Deze machine is behoorlijk vergelijkbaar opgebouwd als mijn pc en een vergelijking met al dan niet gestarte processen en meer levert me dan ook geen verschillen op. Dus ik bedenk weer een truc: wat nu als ik die hele Packages-directory kopieer van mijn laptop op mijn pc?

En dat werkt! Wel na meerdere pogingen overigens; op een bepaald moment verschijnt eindelijk een venster met een Retry-optie:

Visual Studio 2017 start. Maar zodra ik een UWP-project open - een Windows Universal programma, dus dat zowel als Windows 10-app als bijvoorbeeld Windows Phone-app zou moeten werken - krijg ik deze melding:

Een rechtermuisklik lijkt gelukkig duidelijk te maken wat er aan mankeert. Ik moet de SDK (Software Developers Kit) installeren. De 10240 kennelijk, dat is zo'n beetje de oudste versie van Windows 10 maar in de eigenschappen van het project is dat als minimum vereiste Windows-versie ingesteld, dus dat kan kloppen.

Maar de fout blijft zich herhalen, ook na het installeren van nieuwere SDK's. Ik krijg de mogelijkheid direct vanuit de Solution (=het geheel van bij elkaar horende projecten, in dit geval is dat één project): Install missing features. Hierin staat een grote lijst van geïnstalleerde programma's in een venster die ik volgens mij al had geïnstalleerd en dat moet ik 3 x herhalen voordat uiteindelijk het installatieprogramma weer verschijnt. Deze eindigt als volgt:

Hoewel TakeOwnershipPro echt zijn best doet en de installer aangeeft dat het allemaal gereed is werkt het niet:

Het helpt ook niet echt dat de zoekfunctie op het Visual Studio-forum de hele dag buiten werking is:

Opnieuw besluit ik de hele map C:\ProgramData\Microsoft\VisualStudio\ChromeAdapter te kopiëren vanuit mijn laptop. En nu wordt niet alleen de ChromeAdapter-inhoud gekopieerd maar ook de ontbrekende overige ruim honderd componenten worden nu vlot geïnstalleerd.

Kan ik nu eindelijk aan de slag? Nee, helaas. Hoewel de Windows 10 Phone natuurlijk geen nieuwe gebruikers meer krijgt en bestaande gebruikers geleidelijk ooit zullen moeten overstappen op Android of iPhone wil ik sommige programma's ook gewoon laten werken op mijn Windows Phone. Al was het maar voor mijzelf, zolang 'ie het doet.

Hiervoor moet in het startmenu een optie verschijnen om het programma direct te laten draaien op een via usb aangesloten Windows Phone. Je zet hiervoor de processor op "ARM" en moet dan Device kunnen kiezen. Ook moet je emulatoren kunnen kiezen (de CPU moet dan weer x86 worden) die een Windows Phone nabootsen.

Bij iedere Windows 10-versie staat hiervoor een setup, naast die voor de SDK, op deze locatie, behalve voor de laatste April Update (1803) want die is toch niet beschikbaar voor Windows 10 Phones. Maar al installeer ik alle emulatoren, ik zie alleen een Start-knop en de optie Download New Emulators, die zonder verder commentaar de genoemde webpagina opent.

Ik schakel nogmaals Windows Defender uit en kies de Repair-optie. En hierna gaat het -bijna- goed:

Daarnaast: de zogenaamde debugproperties van het project meldt, alweer, een Access Denied-error:

Als je in het oude configuratiescherm naar Programs and features kijkt, lijkt Visual Studio 2017 zes keer geïnstalleerd. Omdat anderen die de "error 6720" zagen dit vaak oplosten met Repairs of herinstallaties besluit ik alles nog een keer te de-installeren en dan, met de eerder aangemaakte offline installatie, opnieuw te installeren.

Na de de-installatie staan er nog vijf Visual Studio 2017's in mijn programmalijst die zich niet laten de-installeren omdat er niets meer te de-installeren is. Dit kan worden opgelost door via RegEdit alle keys te bekijken in de registry van

LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall en keys weg te halen waar Visual Studio 2017 bij staat. Dat zijn er inderdaad na de-instalatie nog vijf, wat ook niet pleit voor de kwaliteit van de installer.

Kijk mogelijk (ook) in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall - deze is voor 32 bit-programma's.

Conclusie

Visual Studio is een omgeving die door steeds meer ontwikkelaars zal worden gebruikt. Vooral de wat oudere programmeeromgevingen gebruiken nog hun eigen ontwikkelomgeving, zoals CA Visual Objects. Moderne .Net-talen als X# zullen gewoonlijk (ook) binnen Visual Studio werken.

Microsoft biedt met Visual Studio Community een zeer volwaardig ontwikkelpakket dat door veel ontwikkelaars gratis kan worden gebruikt. De Professional-versie maakt weer deel uit van Action Pack waar ontwikkelaars voor enkele honderden euro's per jaar meerdere licenties van de meeste Microsoft producten hebben.

Het is daarom onbegrijpelijk dat iets eenvoudigs als de installatie zoveel problemen oplevert. In vele honderden berichten over deze problemen komt ook zelden een echte oorzaak naar voren; net als ik zijn ontwikkelaars vaak uren bezig met workarounds en herinstallaties om Visual Studio aan de slag te krijgen. Het is veelzeggend dat mijn bericht met vragen er over in een mum van tijd door 22 anderen werd gevolgd; op een willekeurige dag, lang na de eerste versie van Visual Studio 2017 kampen kennelijk velen met die problemen.

De installatie lijkt nu gelukt door het uitschakelen van Windows Defender. Afgezien van het feit dat dit niet nodig zou moeten zijn, zeker niet omdat Defender een Microsoft-product is, is het iets wat ik eerder tijdens de hele procedure ook al probeerde en toen nog zonder succes. De de-installatie hield waarschijnlijk de probleemmappen die ik van mijn laptop kopieerde op schijf toegankelijk bij de herinstallatie.

Het ontwikkelteam zou er goed aan doen om veel beter te controleren en te melden wat al die problemen, waaronder de Access Denied-foutmeldingen, veroorzaakt en deze het liefst binnen het programma zelf al oplossen. Dan zal ik persoonlijk niet snel goede vrienden worden met Visual Studio, hierover later wellicht meer, maar in ieder geval niet zoveel tijd hoeven te verspillen met zoiets triviaals als een installatie.

Reactie van Microsoft

Indien mogelijk en relevant probeer ik altijd vooraf een reactie van Microsoft te krijgen op mijn artikel. Zo voorkom ik ook dat er feitelijke onjuistheden in mijn artikel staan. Ik kwam terecht bij een senior ontwikkelaar/hoofd van de Installer ontwerpers in Redmond en vroeg haar of zij een oorzaak kon geven voor het grote aantal problemen met de installer.

Tot op dit moment zijn haar reacties beperkt gebleven tot de verzekering dat ze op zoek gaat naar iemand die mijn vragen kan beantwoorden. Ze schrijft "I'm going to have to check with our marketing/PR team on this". Maar dat was nu juist niet mijn bedoeling! Ik had van een ontwikkelaar willen horen hoe deze problemen komen of te voorkomen zijn, en niet van een PR-afdeling hoe ik wat mooier kan brengen. Een gemiste kans. Of de ontwikkelaars hebben zelf ook geen flauw idee.