In response to my entry on VB hotfixes being made more available, Paul L brought up a point that’s worth addressing:

While this is great (and long overdue), the truth of the matter is that most companies do not have the time and resources to download these hotfixes, test them, and then propogate them to other teams. Indeed, after installing *all* of the hotfixes that you list we still had envrionment issues that remain unresolved. Sure, we can contact PSS every time we run into something, but aren’t we supposed to be spending our times working with tools that are just supposed to work out of the box…

I should have emphasized that the hotfixes are, well, hotfixes. We also call them “QFE”s, which stands for “Quick Fix Engineering,” which should give you a further appreciation of their nature. QFEs are produced in response to urgent customer product support requests and although we take as much care as possible with them, they are intended to solve the specific problem and are not put through the extremely rigorous tests that a full release or service pack gets. Thus, installing a hotfix is really only for people who need their particular problem solved. Everyone else should wait for VS 2005 SP1, which is already in beta and will contain lots of other fixes and will be much more rigorously tested. Seriously – if you can wait for SP1, you should. It’ll be much better.

Paul continues with:

Instead, we made a more strategic choice to simply convert all of our VB applications to C# and we haven’t looked back. In each case, the application conversion process took a day or two (thanks to the conversion features of SharpDevelop) and I can certainly say that our development experience has been on orders of magnitude more stable and reliable with the IDE experience than it was with VB.

I feel extremely regretful that the C# experience has been so much more stable for Paul than the VB experience was. I’ve been doing a lot of development work in a mixed C# and VB solution recently and haven’t noticed any difference between the two in terms of stability, but as is obvious from the hotfix and SP situation, there are some problems. There shouldn’t be any difference between the two IDEs, but I think that part of the problems, such as there is, stem from the greater ambitions of the VB IDE. I find it very annoying switching between C# and VB because I’m always missing my background compilation and much more accurate (in my experience) Intellisense when I flip over to C#. This comes directly from the greater integration between the compiler and the IDE, which also means that there’s more opportunity for problems and for us to screw things up.

The interesting thing to see is what happens in Orcas. With a much greater reliance on type information that type inference demands (both for local variable type inference and lambda expression inference), C# is going to need to forge much closer links between their compiler and their IDE, similar to what VB has done. What effect that will have is going to be interesting to see.