October 20, 2010 05:10 PM

Why Can't SQL Server and Visual Studio Get Along?

Michael Campbell wants to see Microsoft address ongoing incompatibilities with SSMS, BIDS, and Visual Studio
Michael K. Campbell
Dev Pro
InstantDoc ID #128857

Complaining runs the risk of making you look like a miserable crank.

Only, a recent problem that I bumped into while trying to install SQL Server Management Studio 2008 R2 on my workstation highlights a time-consuming, expensive, and recurring theme of versioning and incompatibility between Visual Studio and SQL Server that really needs to be addressed.

Specifically, I'm not writing so much about a single problem that caused me grief—but a manifestation of a trend that just seems to keep getting worse. Specifically, my beef in this case has to do with the ways in which the most recent versions of Visual Studio and SQL Server's management and development tools consistently manifest costly and problematic incompatibilities.

Installation of SSMS 2008 R2 Failed
By way of background, my workstation has Visual Studio 2008 (SP1) and Visual Studio 2010 running on it—because I still have some clients using VS2008 solutions. I also have SQL Server Management Studio 2008 installed because that's what I use to connect to my own development databases (on my dev server) and to some of my more regular clients' SQL Servers as well.

I also have a number of virtual machines (using VMware Workstation) on my desktop that I use to connect to clients' servers via VPN. And, since some of my clients are using SQL Server 2008 R2, I also have a VM with SQL Server Management Studio 2008 R2 installed.

With SQL Server Management Studio 2008 R2 successfully running on a VM, I haven't really felt the need to put it on my workstation. That and I've just worried about any issues or problems that would come from trying to put SQL Server Management Studio 2008 R2 on my box. But yesterday I asked myself: "how bad could it be, especially if I've just done a full system backup?"

Well, it turns out that trying to install SSMS 2008 R2 on my workstation didn't mess anything up.

But it also wouldn't install.

During installation, the installer started off by performing some compatibility checks. Imagine my surprise then when SSMS 2008 R2 complained about two problems that make absolutely no sense.

First, the installer complained about finding Visual Studio 2008 on my computer—without SP1. I've complained a number of times (even in this column) about how insanely hard it is to get Visual Studio 2008, SQL Server Management Studio 2008, and SP1 all living (happily) on the same box. More importantly, the only reason I have all three running on my box together now is because I rebuilt my machine a few months ago to make sure I'd be able to get those three things running on my box at the same time. And I've definitely got SP1 installed (it shows up on the About/Splash page for VS2008, and it's in the Add/Remove Programs listing as well).

Yet, the installer for SQL Server Management Studio 2008 R2 doesn't detect SP1. I can only begin to image how much fun I'll have troubleshooting that one.

Likewise, the same installer tells me I've got SQL Server 2005 Express tools installed. Huh? What? Seriously? Since I just repaved this box a few months ago, I'm sure I've never had SQL Server 2005 on this machine. Nor does anything with 2005 even get listed in the Add/Remove programs listing.

Yes, I'm sure I could probably google these issues and find some workarounds that folks in the community have figured out. But, ultimately, that's something I really shouldn't have to do. My workstation is running Windows 7. It's never had beta versions of Visual Studio or SQL Server on it.

Moreover, if this were just about reformatting my machine to start over from scratch, that would be one problem. But my gripe with that "necessity" is that there's nothing out of the ordinary with my workstation. Instead, what I'm bumping into here is just another manifestation of a recurring theme where it seems like Microsoft is totally dropping the ball when it comes to putting the latest versions of Visual Studio and SQL Server Management Studio on the same workstations.

Not an Isolated Incident
The problem I bumped into when trying to install SSMS 2008 R2 is more than just an isolated issue. In fact, compatibility problems between Visual Studio and SQL Server's client tools are so commonplace now that it sadly didn't come as a surprise when I ran into problems trying to install SSMS 2008 R2 on my workstation.

Moreover, this isn't just a problem for application developers—or even for application developers like me who spend gobs of time in SQL Server Management Studio. Instead, this is a problem that manifests itself over and over again in a lot of really ugly ways for business intelligence (BI) developers as well. And I guess the reason I bring all this up in an article is because I get the sense that Microsoft isn't doing enough to address these problems.



ARTICLE TOOLS


Want to use this article? Click here for options!

Comments
Add A Comment
  • Michael K. Campbell
    2 years ago
    Nov 10, 2010

    As an update for anyone trying to get 2008 R2 to install while struggling through the issues I outlined:
    A) Dan Jones from the SQL (Manageability) Team followed up with me and after a phone call where we discussed some of the ways that Microsoft is trying to address this complexity going forward, he went ahead and tried to reproduce my installation woes - but was unable to do so.
    B) While building out a Virtual Machine for another task I bumped into the 'VS 2008 SP1' rule failure again. That's when I figured out: I had .NET 3.5 SP1 installed on my VM (and Workstation) but did NOT have Visual Studio 2008 SP1 installed. So, I'm a DUMMY in that regard (though, the Help > About screen in VS 2008 makes it really easy to assume you have VS 2008 SP1 installed when you only have .NET 3.5 SP1 installed instead.)
    Then, for the issue with the installer complaining about SQL Server Express 2005 tools being installed, it turns out that this is a fairly common issue with 3rd party plug ins.

    Davide Mauri covers the exact fix I needed here:
    http://sqlblog.com/blogs/davide_mauri/archive/2010/05/04/sql-server-2008-r2-installation-and-the-phantom-of-sql-server-2005-express.aspx


    (And I've let Dan/Microsoft know about this too - so hopefully that makes for easier installation/validation with Denali.)

  • East
    2 years ago
    Nov 07, 2010

    Hi Michael,
    "As [you're] a long time member of the SSMS development team, I'd like to correct your statement..."

    and point out that you appear to have missed the main point of the column entirely. I sugg3est you read it again, since I don't have the time to explain the point bcz I just spent at least a week getting SSMS installed on my machine.

    What a joke. By all the posts across the net it is obvious that MS has been aware of this particular problem for some time. Certainly enough time to have done something about it and spared me the frustration.

    SMSS install failed repeatedly stating it found VS2008 on the machine and stated VS2008 SP1 was required to complete the install. Surprisingly, install failed even after repeated installs of VS2008 SP1.

    In fact, install failed even after all Visual Studio products, and all SQL products were uninstalled along with all associated files using Revo Uninstaller in concert with add/remove.

    What I gather from my experience is MS isn't concerned whether I lose a week's worth of time and productivity. I use MS products to solve problems and save time. Lately, and this is a perfect example, they cause problems and waste time.

    The presence of VS208 on their machines indicates users affected by this issue are repeat customers. Is this really how MS treats its repeat customers?

    So Michael K. Campbell, now that you are obviously personally aware of the problem, I'll view it as your personal failure if the problem is still present at the next update.

    Jed

  • Michael K. Campbell
    2 years ago
    Oct 30, 2010

    Bill,

    Thanks for your feedback. The confusion around which reporting service control are based upon this thread:
    http://social.technet.microsoft.com/Forums/en-US/sqlreportingservices/thread/b84eb724-28f4-422f-9896-e16e0100bdb9

    And the key point here is that DIFFERENT versions were used in the development of 2008 vs 2008 R2 via some form of branching way back when.

    Over and over again, this process of branching is the culprit that I'm complaining about. It leads to all sorts of very UGLY problems for people that just confuse them.

    In the end, the details aren't that important. What's important is that your end-users are baffled by the fact that they can't do what they expect to do - because of internal decisions made a long time ago ... which can't seem to be resolved for another year or so when the NEXT version of the product(s) ship.

    It's that exact problem that I'm railing against in this article.

    That, and to be honest? Most developers don't have a CLUE what Report Builder is - it's a tool built for analysts, not developers.

    So, I don't want to SOUND aggressive here. It's just that I'd REALLY love it if the latest versions of Microsoft's tools would just RUN on my system - and not cause these recurring, ugly, compatibility problems.

    And I'm not alone. Go look at the #1 up-voted connect item right now. Yup, VS2010 and SSIS projects not being supported. People aren't happy about this and there's a very real sense in the comments for this issue (and others like it) that MS doesn't listen or doesn't care - or has become too big and bloated to do anything about people's real concerns.
    https://connect.microsoft.com/SQLServer/feedback/details/508552/ssis-vs2010-project-type

    My beef is that I know you guys can do better. VS2008 and SQL Server 2008 were PERFECT. From SP1 to R2 things just regressed back to 'ugly' though.

    --Michael K. Campbell

  • Ramos
    2 years ago
    Oct 26, 2010

    Hi Michael,
    As a long time member of the SSMS development team, I'd like to correct your statement that SQL Server 2008 R2 was built using the VS 2008 reporting services control. SSMS in R2 still uses the RS 2005 control with security fixes that were released in the VS 2008 timeframe, but it's still the same control. If customers want to build custom reports for SSMS, they must use BIDS 2005. This is one reason why I'm porting various SSMS reports to use Reporting Services for R2. This way, you can design and run the manageability reports with Report Builder 3.0. I have a session at this year's #sqlpass conference on this topic. I also have a series of blog posts at http://blogs.msdn.com/billramo taking about how to rebuild reports using Report Builder 3.0.
    Thank you,
    Bill Ramos, Principal Program Manager, SQL Server Manageability

  • Vlutters
    2 years ago
    Oct 24, 2010

    Maybe less important, but you can't combine FSX with SQL Server at 64bit machine either. And there is no fix available (like at 32bit), and Microsoft has stated to me that no fix will be made (they refunded my FSX though..).

  • ferguson
    2 years ago
    Oct 21, 2010

    I hear you. I keep database workbench pro around now. If you spend a lot of time in Management studio you'll appreciate this program

  • Langlie
    2 years ago
    Oct 21, 2010

    Michael,

    You're observations are accurate and your article *should* turn some heads at Microsoft. Whenever I rebuild, my previous nightmares remind me to install SQL prior to VS and always avoid sql "express" (since I don't normally develop with it).

    It's hard to fathom how Microsoft can continue to treat (in)compatibility between the various VS and SQL products as a non-issue.

    Best wishes,
    Stein

You must log on before posting a comment.

Are you a new visitor? Register Here