I recently noticed in the notification window of Visual Studio Community ’17 that there were some Azure-related updates available. Normally these updates lead to an uneventful experience in which I approve the updates, VS takes a loooong time to download install said updates, then everything moves forward as planned. This time, however, was slightly different so I thought I’d bring you all on my journey of discovery and illustrate why Visual Studio’s attempt to help me figure out what went wrong was so unhelpful. Even so, it’s an easy fix that I’m guessing many of you could figure out anyway. Indeed, my approach takes the slightly longer way round.

The story begins with the update notifications. This is a very common thing to happen with this particular Integrated Development Environment (IDE), and now that I think about it, I can’t recall a time there weren’t updates to be had. Anyway, as I mentioned they’re normally uneventful, and these two were for components I don’t use too terribly much – Azure Data Lake and Stream Analytics Tools, and Azure Functions and Web Jobs Tools. The former are tools to aid and assist with the streaming, gathering, and analysis of the massive amounts of data gathered from IoT connected devices, and that is an area in which I have significant interest, so these tools will be useful for me soon (I hope). Azure Functions and Web Jobs Tools are of less interest to me, but I can’t have an incomplete update hanging in the air above me. So, without thinking too much about it I clicked the notification, clicked on [Update], and went about my business.

No problem

As expected, the process began without much of a hitch.

Good so far

Still good

I should mention that when it comes to Visual Studio, you don’t ‘update’ or ‘patch,’ you instead ‘Modify.’ All just a big semantics issue. Anyway, although things had gone well up to this point, that was about to change.

Uh Oh

So the Data Lake and Stream Analytics tools installed fine, but the functions and Web Jobs tools was another story. I don’t even need those, and I probably should have let it go, but I just couldn’t. That red X would have haunted my dreams.

The obvious next step was to check the install log, as the Installer so helpfully suggested. Speaking of the installer, and if you’re interested, VSIX is a method of deploying updates to Visual Studio, and does so in the right place with the right components and so on. It’s a compressed file, and you can even rename a VSIX file to .zip and extract it. Just wanted to get that out of the way.

I clicked on “View Install Log,’ and the result was a log that was a breezy 865 lines long, and mainly, but not entirely, comprised of stuff that looked like this:

Thanks for the help, install log

This log punches you in the gut twice, because A) You have to find the part that identifies the problem in those 800+ lines all on your own, and B) the part that identified this particular problem was all the way at the very end. Luckily, ctrl-F helped out significantly here.

There you are

Luckily, I knew, or at least suspected, that from here it would be easy. That the update task didn’t exist and the setup instance was not in a launchable state indicated to me that there was a disagreement between the installer and Visual Studio, and not that some fatal, unrecoverable error had happened. Fortunately, my suspicions turned out to be correct and it was really easy to fix. In fact, I could have just done it from within Visual Studio, but this is more illustrative. At least I think it is. Maybe it’s not.

I didn’t even need to go full control panel on it. I simply went in to the apps section of settings, scrolled down to Visual Studio, and selected ‘Modify.’

That brought up the Modification window with the ‘Workloads’ tab highlighted, but we want ‘Individual Components.’

Workload tab in modification window

Individual Components tab in modification window

You’ll notice that ‘Microsoft Azure WebJobs Tools’ isn’t highlighted, so easy fix. That’s also the reason I mentioned earlier that it could easily be repaired from within VS itself. Clicking that checkbox caused almost all the other checkboxes to become selected, and after clicking [Modify] there in the lower right-hand corner, the long, slow update process began anew!

It was at zero percent for a long time, but that’s normal for Visual Studio. Its updates are never a quick thing. After it chugged along for a while, success!

Success!

Remember, I don’t actually need these components, but I was not going to let the VSIX installer win, and now I could raise my head in triumph. Plus, I can experience – for a brief moment anyway, if I know Visual Studio – the blissful Zen of the empty notifications window.

Ahh…

When it comes to a failed component update, I have seen others suggest uninstalling and reinstalling Visual Studio, clearing caches, even making changes to the registry! I have never needed to do any of that for any kind of installation or update hiccup. I don’t know why people think that, especially when a straight repair or modify, as shown here, always works. This is not an advanced technique or a hidden trick Microsoft doesn’t want you to know about; it’s a standard, Occam’s Razor approach that should always be the first line of defense and action for this kind of thing.

If this helps anyone out there avoid all those unnecessary machinations, then I’ve done my part.