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

Mark

Comments

• Anonymous
  November 24, 2005
  The comment has been removed
• Anonymous
  November 24, 2005
  The comment has been removed
• Anonymous
  November 24, 2005
  The comment has been removed
• Anonymous
  November 24, 2005
  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.
  
  Mark
  
  
• Anonymous
  November 24, 2005
  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.
• Anonymous
  November 24, 2005
  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.
• Anonymous
  November 24, 2005
  The generics bug you mentioned is this one?
  http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=eb24881a-87b3-41f3-942c-1c9c944ec03e
  
  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...
  
• Anonymous
  November 24, 2005
  The comment has been removed
• Anonymous
  November 24, 2005
  (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?
  
• Anonymous
  November 24, 2005
  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
  
  http://blogs.msdn.com/somasegar/archive/2004/10/15/242853.aspx
  
  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.
• Anonymous
  November 30, 2005
  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.
  
  Thanks,
  
  James
  
• Anonymous
  November 30, 2005
  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.
• Anonymous
  December 04, 2005
  The comment has been removed
• Anonymous
  December 04, 2005
  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.
• Anonymous
  December 17, 2005
  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.
  
  Will
  
• Anonymous
  December 19, 2005
  "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.