Workaround for when Visual Studio Update says it doesn’t apply
I previously blogged about a problem some customers were running into that prevented Visual Studio Update from installing. You might see a dialog like the one to the right and an error message that read something like,
Update 2 does not apply, or is blocked by another condition on your computer.
At least for many people, they had an applicable Visual Studio installed. From the logs alone, however, we were unable to determine the root cause and certainly never ran into it during countless tests across not only the division but dogfooding across the company…until recently.
One cause of this problem is when the package cache is corrupt or missing. Previously, the related bundle code in Burn – our setup chainer and part of WiX – relied only on registration but at some point a check for the cached file on disk was added. In most cases, errors when checking related bundles is not terminal so no useful errors were reported.
Workaround
To work around this issue, you need an executable where the related bundle should be. Re-installing Visual Studio from the original media or download is the best course of action. If your colleague has the same edition and language installed you could also copy “%ProgramData%Package Cache” from their machine to yours.
If for some reason neither of these options are possible, I wrote a little batch script to copy a benign executable already on your system to the locations of missing bundle executables. This is enough to get past the blocking error, though should you ever uninstall VSUpdate explicitly you’ll be left in a broken state because VSUpdate attempts to repair Visual Studio RTM when uninstalled to restore any upgrades that were removed when VSUpdate was uninstalled.
You must run the following script from an elevated command prompt to make changes, though you can run it as a normal user if you pass /n to see what changes would be made without actually making them.
Package Cache
The package cache is there to solve a great many problems customers have experienced in the past: if source cannot be found when repairing or often times servicing the product, the installation fails and the product may be left in a broken state. This problem is by no means limited to Visual Studio products, but can happen with any product that cannot otherwise recover from such errors.
We realize that such a large package cache is a lot to fit on your system drive, so if you have another drive consider redirecting the package cache using either this method or, more simply, a directory junction (as one commenter pointed out).
If you don’t have another drive – which is likely the case on a laptop – don’t simply delete the entire “%ProgramData%Package Cache” directory. At the very least, don’t delete folders with .exe files in them as they are likely the bundles themselves that are needed to repair, service, or even uninstall. Do consider, however, that Visual Studio isn’t the only product using the package cache. This is an optional but oft-used feature of Burn which has a growing number of users. Some bundles like Visual Studio can restore missing payload from the Internet if you’re connected, but not the executable itself without re-downloading or re-installing from original media.
Light
Dark
0 comments