What sort of support cases are we seeing with Whidbey?

Customers are now starting to use the release version in earnest. Inevitably, support cases are coming in. I thought that it might be interesting to let you know what areas seem to be generating the calls.

As we would expect, there are some setup issues for the IDE. That is not because the install is problematic but because a lot of people are currently installing the product. With a product that is not shiny and new, most users have it installed and the problems that they hit will be related to usage. With a new product, everyone is at the installation phase and so we get a rash of setup issues. There are fewer than I would have expected which is a good sign. A lot of them are from people who had the Beta and didn’t clean up properly before installing the release.

We are seeing some applications broken by known breaking changes. This often catches people out when we go from one major version to another. Minor revisions (1.0 to 1.1) have relatively few breaking changes. Major revisions (1.1 to 2.0) have more. Remoting between 1.1 and 2.0 doesn’t work well because of this.

Intellisense for C++ seems to have some issues. That will probably result in a hotfix in the fairly near future but I am not involved in that so please don’t mail me about it.

Generics seem to be working well but there is at least one complex and rather obscure case where we generate invalid code after passing nothing to a constructor. It isn’t an intermittent issue so it should show up quickly when you test if you manage to hit this particular set of circumstances.

We have seen some issues with the IDE if SQL Server 2005 is installed on a machine after VS. None of them affect anything major but you might prefer to install SQL first.

All this might sound like a catalogue of disasters but this is based on support calls from 1/3 of the world so it is actually a very short list. The product quality seems good, especially for a major revision. I am sure that there will be a few glitches that we will hear about in the next few weeks but that is always true of a product release, be it from Microsoft or anyone else.

Signing off


Comments (16)
  1. The problem with installing SQL first is the IDE then locks into SQL. The RSS feed for the startup screens is SQL (easily changed), the getting started box on the start page is all SQL (no idea how to change that to be more developer focused), the "How Do I" link in help goes to the SQL how to I and help is limited to SQL help until you remove all the filtering.

    Can’t win 🙂

  2. Then of course there is the fact that you broke the URL re-writting shortly after Beta 2 and it never got fixed and right after the RC you made it even worse by making it the .NET framework crash when you try and re-write the root of a web site under IIS.

    You can’t have it repath relative URLs (i.e. ~/) to the client’s path because of the bug you introduced in post beta 2, and you can’t handle the root of a site (i.e. http://www.darwinproductions.net/) without a crash in the framework when you re-write it (as you have to when you turn on wildcards that don’t check to see if the file exists, which you have to do for URL re-writting) thus making the functionality completely and utterly useless.

    There are several like this as all of the blogs talk about. Most of them are complete show stoppers on functionality just like the URL re-writting issues and thus are a major step back from .NET 1.1.

    Then of course there is the inane debug web server that loads a full website up as a subdirectory, thus forcing you to use relative pathing because it’s too stupid to load a web site up in the root where it belongs and when you’re working on a directory application it doesn’t let you set the path to it to maintain relative pathing. Brilliant.

    The problem with Vs.net 2005 and SQL Server 2005 is that in both cases, despite the entire teams blogging, you’re still not listening to customers (other than a few fortune 500s) and the end result is that you’re throwing in functions in a vaccuum and then ignore people’s feedback when they tell you that it doesn’t work because your developers didn’t bother to understand the requirement in the first place, they just checked off a feature on a checklist. (C# edit and continue is actually an excellent example because it’s more anoying than usefull even though it has the potential (if done like VB6) to be the biggest timer saver there is for me. (i.e. I can’t edit and continue on a dll that a web project references, I can’t even work with the debugger running and change source code in the dll, I have to stop the debugging and change it and then start it again, which is a PITA.)

    Then of course there is the DateTimePicker that is still useless… but that’s just beating a dead horse.

    All in all, VS.net 2005 has great promise, but the actual delivery is shotty and fails to delivery on the promise completely, which is worse than expecting nothing and getting nothing.

  3. tzagotta says:

    James, while I respect your view, I think you are a bit jaded. VS2005 has to be everything for everyone, and maybe in your case, it has disappointed a bit. Our experience has been pretty good so far – out of the box it is performing very well with only a couple very minor issues. We’ve shipped several apps built with VS2005 on .NET 2.0 already.

  4. MSDN Archive says:

    I agree that the Yukon/Whidbey co-existance thing is not great. We are looking at that and hopefully will soon have a better solution. It might well be a manual tinkering process but that shouldn’t be too bad since it only has to be done once.

    The URL rewriting is a bit of a pain but it was caused by a security change. You can work around it with RewritePath(path, false). If that isn’t working for you then you need to raise a support case. I mentioned this in a previous blog.

    Genuinely not aware of a DateTimePicker problem. Can you be more precise?

    I am sorry that you feel that we are not listening. I am also surprised that you find that. A great many of our developers and product managers are very accessible. If you have feedback on the direction that you would like to see the product take then I will be happy to pass it on if you email it to me.

    Always good to hear your views.


  5. mike g says:

    Congratulations on getting a shorter issues list than you expected. A product the size of VS 2005 is *always* going to have problems, and some of them might be "show-stoppers" for some people.

  6. MSDN Archive says:

    Thank you 🙂

    A shorter list would have been better still but it is all holding together pretty well and our developers are off enjoying their ritual sacrifice of turkeys.

  7. Sergio Silva says:

    The generics bug you mentioned is this one?


    And the obscure case is this?

    namespace ConsoleApplication1


    class Program


    class TestBase<T>

    where T : class //removing this constraint resolves the problem



    class Test<T, D> : TestBase<T>

    where T : List<D> //can be any generic class



    static void Main(string[] args)


    Test<List<string>, string> s = new Test<List<string>, string>();




    This code generates an assembly that imediatly raises an BadImageFormatException when run. The same example in VB behaves the same. In Managed C++ the compiler doesn’t stops with: T must be a reference class so it doesnt generate an assembly but its incorrect because the code is valid.

    Hardly an obscure case…

    BTW, I think VS 2005 is a fantastic evolution from VS 2003, and I only hope that this time Microsoft issues updates integrated with Microsoft Update instead of making us call for a Hotfix…

  8. MSDN Archive says:

    That looks like a more obvious variant of the one that I had debugged but yes, I think so.

    We get confused as to what the type is. In the managed C++ case, we stop with a bogus error. In the JIT case, we generate bad IL.

    I can’t talk about future service packs so let us just say that we plan to fix this at some point.

    I don’t think that Dev tool patches will ever be on Windows Update as a matter of routine. Before something can go on WU, it has to be regression tested to death – it is what we call a GDR for General Distribution Release. The test time and cost for a GDR is around 15 times higher than a general fix. Since we only have so many devs and testers, we could do 1/15th of the fixes if we made them available the same way. I know it is a hassle to call support but it is probably the best of the two options.

    Glad that you are liking VS 2005 🙂

  9. James says:

    (C# edit and continue is actually an excellent example because it’s more anoying than usefull even though it has the potential (if done like VB6) to be the biggest timer saver there is for me. (i.e. I can’t edit and continue on a dll that a web project references, I can’t even work with the debugger running and change source code in the dll, I have to stop the debugging and change it and then start it again, which is a PITA.)

    Here here! I would love to know a work around for that. It would be nice to *at least* be able to change code in the referenced dll.

    Also, just curious..what other IDE-related issues have you seen when installing SQL 2005 after VS.NET 2005?

  10. MSDN Archive says:

    It would be nice to have edit and continue but I don’t see it happening in before Orca.

    Here is a quote from one of our VPs.

    "Edit and continue for both C# and VB does not work for ASP.NET. There were two major reasons for this. The first and by far the most important reason is that the ASP.NET team felt that their current model was already incredibly iterative even without E&C and that trying to apply the same model that we use for client apps would actually be more restrictive. The reason is that the ASP.NET model is generally compile on the server. So in order to get updated changes, see new content, hit breakpoints on newly added code, you can just hit F5 on the page in IE to refresh. That hits the server and tells ASP.NET to recompile the changes. If we were to use an E&C model instead then the set of ‘rude edit’ restrictions would need to be in place, so it would suddenly become illegal to add new public methods.

    The second reason was simply that it was technically difficult to do and even in the very early planning stages of E&C for Whidbey both VS and the CLR were trying to limit the scope such that we didn’t end up in the same position with E&C that we did for 2002."

    You can read more from him at


    To be honest, it doesn’t seem that installing Yukon afterwards breaks very much. It breaks some undocumented stuff but we are yet to see a case where this mattered.

  11. Mark,

    The Microsoft team have done a fantastic job. For a product of this size and complexity it fantastic achievement. A challenge any development team to have produced a better product.



  12. MSDN Archive says:

    I will pass on your comment – thank you. We get a lot of brick bats and the odd bunch of flowers is very welcome.

    I don’t think that any other company has the resources to assign hundred of developers to a language product. It has been fun watching the developer tools from 1995 to 2005.

  13. Will Pearson (MVP) says:


    On the whole a good product. Some of the new features, such as PREfast, class designer and unit testing are really useful, and I know some of the new features in the .Net CF are ones that have been requested in the community for a while now.

    I’ve not known a product ship without any bugs, well, apart from "hello world", and so you’ve done well to keep the number of problems so low for this point in time, especially seeing the complexity of VS 2005.

    Here’s looking forward to Orcas, and I wonder if we’ll get a can of cider free in the box…

  14. MSDN Archive says:

    It is considered good policy to check all return values. Printf returns the number of characters written. How sure are you that "Hello world" is bug free? If I somehow redirect output to a read only device, it silently fails.

  15. Will earson (MVP) says:

    Hi Mark,

    Good point. Bug free was a poor choice of terms on my part and not really what I was thinking. Completely fit for purpose would have been a better choice, in that it defines the scope of use in which people are expected to use something according to the design.

    This leads onto another interesting area, that of what to test for. Iscode coverage still important seeing as not all code paths will be executed by a user, or is test coverage, i.e. how many test scenarios are tested, more important? All the books I’ve read on testing seem to offer a different opinion on this. question.

    Merry Christmas.


  16. MSDN Archive says:

    "What to test code for?"

    That is an interesting question. There are two things to test code for and a lot of people forget one of them.

    1. The code must do what it is supposed to do.

    2. The code must not do what it is not supposed to do

    Things that are often missed are leaking memory, writing to random bits of memory within the process and so on.

Comments are closed.

Skip to main content