One of the difficult realities about Visual Studio (VS) is that developers can't really use the latest version to develop the latest version of VS. Although developing VS is obviously difficult, I nevertheless feel the need to complain about two aspects of using the latest version of VS, particularly after I read recently that Microsoft is planning on extending its reach into new and additional sectors. For related articles, see "Microsoft Windows 8 Metro UI: One Size Does Not Fit All" and "Why Can't SQL Server and Visual Studio Get Along?"
SQL Server and Visual Studio Can't Get Along
In the past, I've written about how Microsoft SQL Server business intelligence (BI) projects (involving SQL Server Reporting Services—SSRS, SQL Server Integration Services—SSIS, and SQL Server Analysis Services—SSAS) too frequently get relegated to a hand-me-down version of Visual Studio that's commonly at least one version behind the latest and greatest version of Visual Studio that .NET developers are using. This mismatch leads to ugly versioning and compatibility errors, which leaves companies that have spent tens or hundreds of thousands of dollars on licensing to deal with second-class tooling, time-consuming workarounds, and troubleshooting.
In my view, the biggest problem is that Microsoft facilitates the perception that it simply doesn't care about preventing or addressing perennial problems. That sounds very harsh. But it's hard to avoid feeling like this based on the feedback and criticisms that I've seen on Microsoft Connect for long-standing bugs and incompatibility problems—to say nothing of the bugs that I've recently found myself. In fact, I've found three bugs that point to this perception problem within just a week of using SQL Server Management Studio (SSMS) 2012.
In my mind, the first two of these bugs are related. I found both of them within two minutes of using SSMS 2012. The first bug was that I couldn't use my scroll wheel to select a database from the drop-down list of available databases on the server that I'm connected to. The second bug is fairly similar; I'm no longer able to use my mouse's middle button to close tabs in SSMS's main work area. These bugs aren't earth-shattering, but they do make me wonder where QA was because I found them both within a few minutes of use.
The third bug is, sadly, an old standby from Visual Studio that has finally made its way into SSMS 2012. In practice, this bug plays out something like this: You're minding your own business and open up an existing file in SSMS 2012, only to be greeted by a big ugly modal window about inconsistent line endings, as Figure 1 shows.
Figure 1: The Inconsistent Line Endings dialog box when opening an existing file in Microsoft SQL Server Management Studio (SSMS) 2012
There are some really infuriating problems with the third bug. First, this problem of inconsistent line endings pops up with files that were completely created and saved by SSMS 2012—even when these files weren't touched by any other application. Second, you'll continue to receive the error if you click Yes in an attempt to fix the line endings. What's even worse is that you'll still receive the error if you tell SSMS 2012 to stop annoying you with these antics by clearing the Always show this dialog check box.
It doesn't take much work in SSMS 2012 to cause this bug to crop up. However, nothing about this bug is more annoying than the fact that Microsoft patently refuses to believe that this problem exists, despite all of the complaints over the years about this bug in past releases of Visual Studio. Another big problem is that this is a Visual Studio bug that's now affecting SQL Server. I can only imagine the kinds of internal politics associated with fixing this bug—that is, assuming Microsoft can ever be persuaded to acknowledge the problem's existence.
SQL Server Data Tools and a Minor Complaint
I later found out that the cause of my middle-button bug was because I had SQL Server Data Tools (SSDT) installed on my machine. However, I had to install SSDT to test-drive access to all of the SQL Server 2012 BI components. And the only way to access those BI components with SSDT is to uninstall Visual Studio 2010, install SQL Server 2012, and then reinstall Visual Studio 2010—as per Microsoft's workaround.
Strangely enough, the biggest thing that leapt out at me when using SSDT was that my unit test windows and other toolbars weren't functioning when I was working on some simple SSIS projects. But as you might have guessed, I don't need unit tests when working on SSIS projects. However, this doesn't matter. With Visual Studio, you get a one-size-fits-all IDE in which a single profile (e.g., a collection of settings, tool window positions, and visibilities) is shared between all different types of operations. In other words, you get the same default profile when creating .NET class libraries as you do when working on extraction, transformation, and loading (ETL) transforms.
I personally think having a single profile is totally messed up, and I know that Microsoft MVPs and ASPInsiders have been begging Microsoft for half a decade to let developers easily shunt back and forth between different managed profiles. One common reason for this request would be to let developers toggle between normal developer mode and presentation mode for full-blown presentations or during a simple lunch-and-learn session within corporate environments.
Visual Studio Slated to Take Over the World
Consequently, when I see that Microsoft plans to have Visual Studio take over the world by extending its reach into the realm of operations, it strikes me that there are two really big complaints that Microsoft has to address before they're going to be able to find success with this initiative.
First and foremost, Microsoft's hand-me-down approach to using an older version of Visual Studio for nondevelopers needs to stop. Otherwise, Microsoft needs to stop allowing such glaringly simple regressions and incompatibility problems to continue to exist. This isn't free software we're talking about—Visual Studio comes with a very hefty price tag for users in the BI space who have to keep dealing with these problems.
Second, if Microsoft is really going to keep trying to push Visual Studio into other realms (first Visual Studio was a developer tool, then it was foisted onto DBAs, then onto testers, and now it looks like it's headed for operations), then the company needs to address the real fact that many Visual Studio users wear multiple hats. Failure to acknowledge this problem is largely behind all of the versioning and incompatibility problems that I've complained about here and in previous articles. However, the other aspect of this problem is that a one-size-fits-all IDE that doesn't easily enable different user profiles is going to continue to meet with friction, cause additional problems, and create more cranky end users.
