Careful With Your VS 2015 Updates!

[Last updated 3 Aug 2016, 11:05 Eastern time to clarify some wording]

Yesterday was 2 August 2016 — Windows 10 Anniversary Update (1607, build 14393) was released.

As welcome as the Windows updates themselves are, they also come with updates to VS, the SDK, and the WDK. In the past 24 hours we’ve discovered that it pays to be careful in how you apply these updates.

First, it’s important to note that the update to WDK 14393 is very much a one way street: Once you upgrade, there’s no way (at least none that we’ve found) to go back to the 10586 WDK.

So… before you grab and install the new WDK, be sure it’s what you want. Be sure you don’t mind living with the spurious CA warning we described last night.

Now, I bet you’re thinking “Well, surely that can’t be correct.  If I install the 14393 WDK and I decide I won’t want it, all I’d need to do is remove it and I’ll be back to the 10586 WDK.”

No.  It does not work that way.

Happy?  No?  Me neither.  And if that’s not terrific enough, there’s another wrinkle about which you should be aware:  Once you install anything that contains or is related to the 14393 SDK, your 10586 WDK will stop working and you will have no choice but to upgrade to the 14393 WDK.

Now, I bet you’re thinking “Well, surely that can’t be correct.  If I install the 14393 SDK that should live side-by-side with the older one.  And, geez, at worst, if I install the 14393 SDK pieces by mistake then all I’d need to do is remove them.”

Right.  That’s what I thought too.  It does not work that way.

But installing the 14393 SDK has got to be easy to avoid, right?  Just don’t download the new SDK or the new WDK!  Well, no, not so easy, actually.  Yesterday, I’m working in VS and it popped-up the notification that an update (KB165756 ) was available.  You know how VS does these things.  So, I said to myself “WTF… why not… sure… it’s update day, let’s update my good friend Visual Studio!” And this subsequently broke the 10586 WDK, by resolutely insisting that the include paths for things now be something with the numbers 14393 in them.

Now, I bet you’re thinking “Hey!  Just roll-back to the restore point that was created before installing the KB!”  Yes, that’s what I thought too.  I did that.  The roll-back worked.  And it rendered by installation of VS entirely unusable.  As in, the UI hung.

Thus began my 4+ hour odyssey of attempting to repair VS, remove VS, remove the 14393 WDK, install the 10586 WDK, and somehow bend Visual Studio, the SDK installation, and the WDK to my will.  “My will” in this case being nothing more complicated than “a working VS 2015 + 10586 WDK.”  But it was not to be.

I finally discovered that resistance is futile:  I installed the 14393 WDK and will just live with the spurious Code Analysis issue.

Some of this undoubtedly has to do with the new way that the SDK is being distributed.  Prior to 14393, the SDK could be downloaded and installed as a separate component.   Starting with 14393, the SDK is now packaged along with Visual Studio — it’s no longer separately downloadable.  However, it seems that packaging work somehow went astray and broke side-by-side SDK installs or the 10586 WDK or something.

This is just all too reminiscent of the Windows NT 3.5 DDK — Let’s see… I have to be sure to keep this CD with this version of VC, and that CD with that version of the Platform SDK, and this CD over here, with this version of the DDK… and be sure I install them in exactly the right order… or I won’t be able to do my job and write drivers.

Deja vu.  My head hurts.