VS2013 Update 2 RC–Ouch (Part 1)
So recently the Visual Studio Team released the Update 2 RC for the 2013. Among other things it has updates for project templates including the Universal Application project template.
This particular feature is something that my current development team were interested in as the project we’re currently working on is a Windows 8.1 Application, our client has strongly hinted they want it for Windows Phone 8.1 in the not too far future.
With that in mind one of our developers downloaded and installed the Update onto his development rig. The projects he added (portable class libraries) as it turned out had a solid dependency on the the Update. This meant no one on the rest of the team could build the solution without first unloading the projects he had added.
This also meant the build agent couldn’t build the solution since msbuild couldn’t open the project files. With work having already been done in these projects we all started rolling our Visual Studio installations forward onto the Update. (Whilst our Team Lead/Engineering Manager applied the update to the Build Agent).
That’s when the problems started.
I’ve been working on the CodedUI tests for this project for about 8-10 weeks now. They’re all hand coded, I use the CodedUI Test Builder tooling in Visual Studio to have peaks at the various properties of the controls I’m trying to find. After the this tooling stopped working. I’d open the Tool and then…nothing. Checking the event logs on my rig showed that the codeduitest.exe had crashed due to not being able to load any of the test extensions.
I attempted a repair installation to no avail (hoping that perhaps some of the assemblies had been corrupted). At this point I decided it would be best to reinstall visual studio 2013. My colleague kicked off an installation of VS2013 RTM for me the same evening after I left.
When I got into work the next day VS started and the CodedUI tool started! Great….but then I discovered that it was not very functional. It couldn’t pick up any objects. Poking around I found that to my horror the RTM install had decided to split itself between the root of Program Files(x86) and Program Files(X86)Visual Studio 12.0.
I made a guess that some of the dlls that the IDE used weren’t where it was expecting despite the numerous registry keys that should have been pointing Visual Studio around to where it’s innards were strewn about. I tried moving the erroneously placed components back into the the 2013 folder but this caused the IDE to fail to even start.
Needless to say I uninstalled it again then found out to my dismay that it would only let me install it into the root of X86. Reading into it if the VS installation detects that a dependency of the installation is already installed (I believe it’s the C++ binaries) it forces you to install VS in the same location.
Because VS does not cleanly uninstall I had no means of getting rid of the pointer that was forcing it into the X86 folder, short of going through my registry with regedit and destroying everything labelled Visual Studio 12.0/2013 with extreme prejudice, even then it wasn’t guaranteed to work. So I had to have my rig re-imaged and wiped down. All so I could put the correct tooling back on to do my job properly, and overall I’d lost about 3 days of time on the sprint we were on due to the faffing around trying to get my machine into working order.
You’d think by this point how could it get any worse. Well it did but that’s a separate blog post (see part 2)
The moral of this story isn’t “Don’t install VS2013 Update 2 RC!!”, it should be tested and used by the community, just not on a production project in my opinion. Our first developer to install the update should have consulted with the rest of the team before doing so and as a team we would have weighed the risks versus the gains before deciding whether to install it. The simple reason being it’s an RC not the finished product. I can’t help but wonder if we’d waited a couple of months for an RTM version would I have had the same problems upgrading.