Microsoft’s Visual Studio “Bloat” is Hurting All Professional Developers…

Up through Visual Studio 2010, updating the development environment with new service packs was a no-brainer. You simply did an update through a web-install or by downloading the ISO image. If the targeted system was clean, installations were not known to cause issues, though there were some reported on occasion.

This all began to change with the release of Visual Studio 2012, which for the most part was mostly reviled by the professional Microsoft developer community. Rather ugly with its flat icons, dark colors, and upper-case master menu bar, Visual Studio 2012 was ignored by many developers simply because of its looks. However, that was merely the tip of a larger issue which has been developing since.

Microsoft does make great products and probably produces the best development environment available with only rivals like Java’s Netbeans and Embarcadero’s Delphi to match it. For Windows development however, Visual Studio is the majority choice no matter what .NET language is selected for development.

However, with the advent of so many new methodologies being used for development at all levels, Microsoft has decided to stray from its roots in its attempt to maintain relevancy to the younger generations of developers who are adopting these techniques. And with the accumulation of so many new products into the fold this has resulted in an ever increasing size to Visual Studio initial implementation packages and its subsequent service packs. For those still developing with trusted 32bit machinery, installations can be a half-day affair with the less than adequate options to select and choose the various components that one wants to install. The result is that most take the standard default and let all of the components go in.

Unlike, Visual Studio 2010, which was rather an easy implementation comparatively to repair if anything went wrong, Visual Studio 2012 and its current successor have both become drawn out length processes to install and even worse to fix if something goes wrong. A search on the Internet tells this story more explicitly as one finds increasing issues with either major version.

In Microsoft’s rush to attract new developers to the community while attempting to keep the existing base stable, the Visual Studio 2012 and 2013 products appear to be trying to be everything to everyone, with literally thousands of files and assemblies being installed for each. However, that is not the real problem.

It is understandable that Microsoft would want to offer this and why not? Their products individually do have a high level of quality. Yet, the way this is all being done is showing signs of an increasing sloppiness in package design that was not as prevalent previously if it ever was.

Foremost, there seems to be no interest in allowing professionals to make their own tool choices in either Visual Studio 2012 or 2013. You can make some general choices as to whether you want “F#” and or “Blend” installed for example but with so many tools now being incorporated into Visual Studio one would think that the choices being offered would be far more granulated making many such installations more timely to work with.

For example, Black Falcon Software primarily develops with ASP.NET and WPF (Windows Presentation Foundation) against SQL Server databases. This mode of development is still fairly standard for many developers. So the question is why does such a development perspective require cloud development tools, Windows Phone SDKs, MVC extensions, Windows Forms modules, JavaScript Frameworks, and the like? Why using such a setup is “.NET Framework Core” required when standard ASP.NET still only makes use of the standard framework installation? In short, such options are not necessary for such an environment and if needed later should be available as options that can always be added with the installation’s “Modify” process. Such granulation in tool options would surely support better modularization on Microsoft’s part.

Nonetheless, they are not offered and for the most part, as developers, we tend take the whole ball of wax.

You would think that with so many complex and diverse levels of installations, a Visual Studio install process would first make entirely sure that the targeted environment can ensure a successful installation much the same way that the standard SQL Server installations provide. However, this does not appear to be the case and the Visual Studio installation package simply assumes that the environment is ready with any existing necessary installed components when it may not be. Such a lack of preparation on these packages’ parts now also increases the chance of a general, internal failure, which the developer may or may not know about until the end of the entire process.

Even if a package installs apparently correctly something can still go wrong as has happened with Visual Studio 2012. Try uninstalling what appeared to be a successful installation of this version and you could find yourself with uninstall failures leaving you with a registry that is out of sync with the product as well as a host of files left on your hard drive.

To avoid such nastiness with such installations it is now better to purchase third-party “Uninstall” tools such as “Revo Uninstaller” for monitoring installations or “Max Uninstaller” for cleaning up the mess after the fact.

Visual Studio 2013 was supposed to be the answer to the interface issues the developer community complained about in VS 2012. However, with more to offer, the 2013 version is even bigger with the new 2015 version probably expected to be the biggest and baddest bad-ass on the community’s block (Visual Studio 2013 with Update 5 unzipped is 7.3 gigs and all these new versions both bring the 32bit and 64bit files along for the ride! Why, when you are only going to install one or the other?).

However, Visual Studio 2013 can be a classic example of a successful installation with hidden fault-lines that promise to provide a nightmare scenario for anyone who tries to upgrade with the various services packs.

In a recent experience with this, Black Falcon Software decided to upgrade one of its workstations from Visual Studio 2013 SP3 to SP5 (update 5). Service packs 2 and 3 went in without a hitch so what could go wrong? A lot! Talk about having a false sense of security…

As mentioned, these installation packages do not verify if the current environment can support the clean initial installation or any of its upgrades. Expecting that SP5 would simply go in like SP3, Black Falcon Software instead experienced a failed installation, which made the current, installed Visual Studio unusable. Thinking that maybe the interim SP4 was needed, the current installation was successfully rolled pack to SP3 and the SP4 installation was attempted, which also failed at the end and left the existing installation in an usable state.

Next a complete re-installation of “Visual Studio 2013 With Update 4 (SP4)” was attempted thinking that the entire installation would be refreshed and upgraded. This didn’t work and neither did the same with “Visual Studio 2013 With Update 5 (SP5)”. Not only that, but the current installation could not be uninstalled or rolled back cleanly allowing for a completely fresh installation.

Used to such clean processes with Visual Studio previous to 2012, it was thought that that version was an aberration so no “Uninstall” tool was used to monitor any installation with Visual Studio 2013.

Luckily, as an MSDN Professional subscriber, Black Falcon Software could avail itself of Microsoft Technical Support, which in this case and over the course of 4 days of effort was nothing short of excellent. The issues posed by these installations of the Visual Studio 2013 Service Packs were so difficult to find that it took two support engineers 4 days to troubleshoot the issue. What was it? Get ready to fall of your chairs at this one!

Prior to moving to Visual Studio 2013 SP5, Black Falcon Software installed .NET Frameworks 4.5.1 and 4.5.2 individually. The current installation of VS 2013 SP3 continued to work fine and all development proceeded without problems compiling software successfully against all of the 4.5.x Frameworks installed.

For some reason, Microsoft in the interim updated the 4.5.1 version of the Framework changing the internal version number now making currently installed 4.5.1 Frameworks obsolete as far as the Visual Studio 2013 SP4/SP5 updates were concerned.

Since the upgrade did not verify for a supportive environment in went both the SP4/SP5 upgrades ignoring the needed upgrade to the 4.5.1 Framework completing with only a warning at the end with no real relevant information.

When Visual Studio 2013 was initiated after the installation up came a dreaded ambiguous error informing one that a side-by-side configuration error had occurred with “coloader80.dll” in the root directory for the application. And that information also within the subsequent logs led our Microsoft engineers on a “goose chase” that led nowhere but into dead ends.

Using some relatively sophisticated internals analysis tools they finally found the real issue, which regarded the 4.5.1 Framework. They manually had to uninstall the existing version of Visual Studio 2013 as well as the existing 4.5.1 Framework, which they subsequently re-installed manually from the SP5 package directory before re-running the entire SP5 installation again. And that too did not work completely so a “Repair” was necessary, which finally produced what appeared to be a completely clean Visual Studio 2013 installation.

All of this was completely unnecessary and costly to both Black Falcon Software and Microsoft in terms of time and money. And what all of this portends are more possible disasters in the coming release of Visual Studio 2015 simply because Microsoft package design engineers are not taking the necessary precautions with the increasing levels of complexity they are implementing into these products.

The best way to make this situation known to Microsoft and demand that such packages be prepared with greater care and accuracy is to write not to technical support but to the “Office of The CEO” at Microsoft as Black Falcon Software intends to do.

None of us should have to give up in disgust as some have reportedly already done so with these products. We are paying good money for these products and for our professional subscriptions and they should operate as expected. And writing your complaints and demands to the “Office of The CEO” will definitely prevent such an issue from getting lost in the technical-support shuffle.

Any professional developer wanting to send such a letter should make it hard-copy to attract the necessary attention and sent to the following address…

Mr. Satya Nadella
Office of The CEO
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
USA