VS.NET Service packs and why they're not here

Dan Fernandez blogs about the Whidbey release date slip and VS.NET service packs. An understandable article and I thank him for giving some insights in the why-o-why's. He also talks about service packs and why this is a problem. He gives some reasons why service packs for VS.NET aren't released yet. Let me warn you first: reading the reasons may cause you to fall of your chair so grab your desk or other strong, solid piece of material to avoid you getting hurt. Please acknowledge that Dan is most likely not the origin of these statements so a "Don't kill the messenger" is appropriate.

Ready? Ok, here we go. I commented on his reasoning below his comments.

WRT your point about why there have been no service packs for VS, first realize that we have several hotfixes up at http://support.microsoft.com if you have a particular problem to address, feel free to contact me directly.

This is absolutely bogus. Here's why:
Say there is a bug which I need fixing for my own software to work correctly. Am I helped with a fix from PSS? No! My own install perhaps works with the fix, but my customers who will use my software have to call PSS as well!

An ISV can't rely on that: "To get this piece of software working, you first have to call Microsoft for a fix". Most customers don't want to install hotfixes for .NET, they want service packs for .NET. That's why a hotfix is nice for an internal application, however for ISV's it's absolutely not usable: they can't ship the software with the patch, the customers have to call MS themselves.

I appreciate the time you want to take, Dan, to fix bugs or communicate between developer and MS developer but please realize that hotfixes are unusable for ISV's for the reason I just mentioned. Support like this is not to be called support. Sorry that I might sound a little annoyed but as a matter of fact I am annoyed about this issue. I'm getting pretty tired of all the blabla coming from MS about that there is no issue with support, that customers get the best support possible etc. while a massive amount of developers complaints about this day in day out (read the newsgroups f.e.). So, please please please realize what the pains of the developer community are today so please address them a.s.a.p.

You can read all about the developer implications of Windows XP SP2 here. I don't work on the Visual Studio servicing side (anyone who does chime in here), so I'm just giving you an educated guess here, but since there are specific developer implications for Windows XP SP2, the VS team would need to factor/depend on those changes for any future Visual Studio service packs.

This is pure CoverYourAss.exe, pardon my French. It's not my nor anyone elses problem that the design of Visual Studio apparently relies on Windows XP's structure and changes made to WindowsXP seem to break Visual Studio.NET. Furthermore, VS.NET and .NET 1.1 were released in April 2003 (!). That's almost a year ago. Are you trying to sell me the idea that in that year all bugfixing effort has been put on hold because of an XP service pack coming later this year? I hope not

A lot of bugs are already fixed, for a long time (hotfixes are available if you call PSS, but not for the public), however they're not released to the public. What's wrong with: release the fixes now and release another fix for XP SP2 when it arrives? Why o why do we have to wait till Q4 2004 before any fix for vs.net 2003 or .NET 1.1 are released?

Let me take a wild guess: fixing stuff costs money and time. Putting developers on those fixes now is not productive because they can better work on Whidbey as it is behind schedule as it seems. Understandable, but again, not the problem of the customer. The customer (the developer using VS.NET and .NET 1.1, you know, the people who do the hard work for Microsoft to get .NET accepted in the real world) payed for software and wants support, because s/he has every right to get support in the form of fixes.

I know that this rant will not make any difference, but so be it, at least some people now know the other side of the story.


  • Why VS6.0 has 5 Service Packs (the 6th is quite ready) and VS2002/2003 have no SP at all?

    I think that there are some problems with the past (and perhaps current) .NET strategy...

  • I'm not the right person to discuss this as I don't work in support. Don't consider me the messenger, I'm not trying to represent Microsoft support.

    I copy/pasted relevant parts below from a response I gave you on my blog


    My post wasn't supposed to be meant as *the* explanation for why we don't have service packs. I don't know the answer to this, I don't work for support. I don't know the answer to the servicing questions and I'm not trying to make excuses, I was simply trying to help. There are plenty of people that aren't even aware of what hotfixes are available on our support web site.

    My point *was* that VS 2005 has quite a bit of work that still needs to be done before it will ship.

    I asked you to contact me directly if you had a specific problem and I told you I would try and help. I still haven't received email from you on what specific issues you have. Help me help you :) I can't promise anything, but I'll try my best...

    **Warning: I am not a Support person**

    WRT ISVs - You do need to make the distinction between VS.NET and .NET framework service packs as there is nothing blocking an ISV from applying hotfixes to developer tools in their organization. The other point on multiple service packs is that we got flack from customers saying that we were releasing too many service packs for Windows and that their customers didn't want to patch all of their systems once every six months, let alone once every two months. ISVs complained that multiple service packs for Win 2K increased their test matrix and they found themselves requiring a specific version of a service pack, say SP3 for their customers to install the software. Once ISVs required a specific version of a service pack, that createe a barrier for customers/organizations who are not ready to upgrade to a specific version of a service pack. In large organizations, a service pack is tested quite thoroughly before it is rolled out on all machines domain administrators lock down machines so that users can't patch unapproved machines. The pain that we've heard from ISVs is that we are forcing them to choose - create a release that works with a specific service pack and lose customers that can't/won't/haven't upgraded to that SP, or create multiple releases that work with multiple service packs and the additional dev/test/QA/support work this entails. I don't know the right answer to this situation....

  • >>"Why VS6.0 has 5 Service Packs (the 6th is quite ready) and VS2002/2003 have no SP at all?



    I suppose a more relative question is, how many services packs were released for VS6.0 in it's first 12 months?

  • Simon: Alright then, how many for VS.NET (2002)? Let's not forget (since most of us have MSDN subscriptions) that 2002-2003 was NOT free.

    Frans: Let's hope MS isn;t adding more developers to a late software project. Brooks' Law and all that...

  • Brooks' Law is useful... but even properly run projects get behind sometimes, and properly run projects *can* add people without harm.

Comments have been disabled for this content.