ISerializable - Roy Osherove's Blog

I find it hard to judge the stability of VS2005, since Ive been mostly working with WinFX and have Resharper 2.0 EAP installed. The verdict: it's pretty unstable, unsurprisingly :-)

Ah well, I love VS 2005, I use it everyday, and find it very stable - there are some things it won't do, and sure there are things crashing it, and it can be better.
But still, it is the best IDE I ever used, and I don't wanna switch back, or have waited longer - it's far more than good enough for me.

And honestly, some of the 'bug'-complaints are plain stupid "if I do this and that the IDE crashes" - so don't do it, or can't you learn?
Or people complaining the scrollbars in the IDE don't use the windows theme - I'd strip these folks of the title 'developer' and name them 'user' then.

As Douglas Adams wrote: nothing spreads as fast as bad news, and blogs make this even faster.

Roy all developers using already VS 2003 expect the quality from VS 2005 because they know what they have already. Nothing like 2002 where everything .Net was new. It's a great version but its somehow frustrating that in name of progress some rules of compatibility were broken.
And regarding the Product Feedback Center, yes it's a great idea, but Microsoft is the one who decide what to consider a bug, which is a bit sad attitude.

I personally don't care about the bugs. What irks me is that it's going to take 2 to 3 years before the next release and/or a service pack where Microsoft fixes them. Unfortunately, the new release will introduce new bugs and the cycle will repeat.

I don't expect perfect software, but I do expect quality software. Microsoft just can't seem to break the cycle of releasing crap. Until I see regular and routine bug fixes for their development products, they are not moving in the right direction.

Bryan

I'm using Resharper AEP too, so I try not to be too quick to judge it, but it is a serious pain.

I spent 10 minutes trying to figure out why VS.Net was reporting invalid errors, only to rebuild and get a compile-time error of:

"The application domain in which the thread was running has been unloaded"

finally, it built ok after this. Maybe it's resharper...

I have used vs2005 since beta1 almost every day for a medium sized winforms solution (about 15 projects). The overall quality is acceptable, but the design time of the winforms is much too sensitive to user coding mistakes.

For example, if i misbehave in a default constructor of a Form, vs.net shows an quite cryptic error that it cannot render the form in design time (good) but than completly crashes. Also using inherited forms is a very sad experience.

And in the process of failing, some old temp assemblies are left behind that you need to manually clean up otherwise changes to your form code are never picked up (basic clean solution doesn't help).

The funny thing is, in the last ctp/rc seemed actually more stable to me than the RTM.

A last note about Resharper 2.0 EAP: it's nice for small solutions, but for large solutions the startup parsing it's just too slow when you have multiple vs.net 2005 crashes a day. And stability is not the strongest point of the current build (210)

My 2 cents

"And honestly, some of the 'bug'-complaints are plain stupid "if I do this and that the IDE crashes" - so don't do it, or can't you learn? "
You're the one who's producing stupid complaints. If I type in code into an editor I don't want it to crash. It's just plain text. So you're saying now that I shouldn't type in code into an editor because it might be crashing the IDE? What are you, a manager?

Oh, and if you're in a large project and refactoring it from pure .NET 1.x code to .NET 2.0 code, and you have a lot of errors (because not everything is refactored yet), say over a 100, it takes a long delay before it actually shows up the errors after the compile is long done, long delay as in: 5-15 seconds minimum. On 2003 this wasn't the case. I'm not sure what it's doing, but it's weird.

Just so you're clear in case you though that was me Frans, that was a different Sam (from Germany). I have no opinion on this matter without further research.

Roy, I agree with you in principle that the VS quality thing might come down to the change in the dev world since the last release, but my first experience with the RTM (http://www.brokenkeyboards.com/brokenkeyboards/blogs.aspx?blogid=188) wasn't pretty.
And, after wailing bitterly to PSS about the handful of issues we have had to skirt around each week with VS 2003, I was really hoping for Whidbey to be the solution to my problems.

To me, it all comes down to managing expectations. If I make a client wait for a month or more before handing out updates, I'm not going to be popular. However, if I *try* and get hotfixes out often and make sure that the client doesn't feel that they are paying for it, then I'll stay in business.

If I told the client to wait for the next version, I'm sure they would be critical no matter what when it finally come out. Understandably too.

Microsoft's handling of the client's (our) expectations wrt Visual Studio has been poor. And it's made me a little meshuga to say the least.

Ward: "if i misbehave in a default constructor of a Form, vs.net shows an quite cryptic error that it cannot render the form in design time (good) but than completly crashes. Also using inherited forms is a very sad experience."
This is scary as most of our work (and IDE bugs) are in the Winforms space. Hopefully the infamous 'disappearing usercontrols' bug is fixed.

And, I've been finding speed issues with .NET 2.0 when compared to .NET 1.1. This, and the poor support, is definitely reason enough for me to not move my team onto .NET 2.0 until SP1.

"You're the one who's producing stupid complaints. If I type in code into an editor I don't want it to crash. It's just plain text. So you're saying now that I shouldn't type in code into an editor because it might be crashing the IDE? What are you, a manager?"

There are only a very few very special cases of source entered that can crash the IDE. So learn them, and don't type them. Programming in VS 2005 with source highlighting and intellisense is very obviously not 'only entering text'. If you really only want to enter text, use notepad.

VS 2005 is a tool, and a tool for a professional who should be knowing what he is doing, who should be able to learn what this tool is good for, and what not to do with it, and act accordingly.

In the final release of Visual Studio, the MonthCalendar Windows control has a terrible visible flaw and I wonder how that control made it passed testing.

To see the flaw:

Drop the control on a form and run.
Select a range of dates within a month.
The display within the control is messed up.
Change the month.
The display continues to be messed up.

Also, I'm disappointed that snaplines and grid don't work together.  They must be used independently.

I do like VS.NET as a tool.

Yes Microsoft has screwed up and has been screwing up Visual Studio since VS6 The reason is simple, there has not been a patches or bug fixes for a compiler since VS6 SP6! Yes if you compare the release of VS6 to VS2002-2003 or 2005 you can say they had similar issues. However the thing that irritates us all is that you don't make that comparison. You compare VS200X to the VS6 SP6 release which had been cleaned up. For some reason supporting the development community in this way doesn't seem important to Microsoft. I realize that there have been many new features; they have all come at the expense of stability and predictability. VS200x releases have had the most heinous of bugs and for some reason they weren't worth patching. For example: VS2003 C++ project references wouldn't consistently build code correctly. So yes, you learn and go back to the old Force using technique. However, this is only after months of annoying intermittent problems with multiple developers and few weeks reporting the bug to microsoft support. All in all probably tens of thousands of dollars wasted.. only to be told wait for VS2005 and MsBuild.. hmm lets see that was late 2003. I'm sorry.. VS6 SP6 was very solid when it came to developing 32bit windows applications. At the very least it was predictable and you knew you're devil. I was hopping that VS2005 was going to clean things up a bit. Sorry, I've already reported a bug in the VS2005 Managed C++ compiler that is preventing the transition of 500,000 lines of C++ and C# code from VS2003 to VS2005 And for C++/CLI... Hmm.. you have to ask.. wouldn't it have been nice to stabilize the C++ environment before making radical changes like those involved with C++/CLI. The only reason VS2005 isn't screwed up is because there isn't a reasonable competitor! Otherwise we would be using someone else's product like SomethingElsePlusPlusCLI.NET So, to summarize the Screw up with VS2005 is this: NO PATCHES! Microsoft: We need faster fixes to development tools so we can respond to our customers in a more predictable fashion. Christopher

do a clean project and rebuild, instead of build.