Although VS 2010 Beta 2 hasn’t been released yet, Microsoft has stopped fixing the certainly minor bugs that I have reported in the last days about the C# file code model. Instead they are currently focused “on stabilizing and improving the performance of VS2010”. This is something that has happened in the past (I remember since VS 2005): once the Beta 2 is released no feature is changed and very few bugs are fixed (only the big ones that would prevent the release of the product), but I think that this time is worse, the facts are:
- VS 2010 Beta 1 was not feature completed (the customization of toolbars was disabled for Beta 1, for example)
- It had important bugs in the new WPF commandbar model
- VS 2010 Beta 2 is not released yet, but some bugs won’t be fixed until VS 11 !
Too bad. I’m talking about minor bugs that should be easy to fix, not ones requiring architectural changes that I understand will be postponed.
I find quite stressing what will happen if the WPF commandbars are not fixed correctly for Beta 2, or new bugs appear with features that were not completed in Beta 1. I’d rather see no CTPs at all and a longer series of betas instead:
- Beta 1: quite feature completed. Time to complete it and fix bugs.
- Beta 2: feature completed. Time to fix bugs.
- Beta 3: bugs fixed. Time to focus on stabilization and performance.
- RC1, etc.
At least we would have two beta cycles to get bugs fixed.
All that said, I welcome the focus on the performance of the Visual Studio (the 2005 release was quite bad in this regard).
UPDATE: Microsoft clarified that this affects only to bugs in the code model because they are investing in a new code model. See Clarification on my previous post “Microsoft no longer fixing (small) bugs for VS 2010”
Well, that wouldn’t be anything new. I stopped reporting bugs since I have some open since .NET 1.1 and aparently nobody is ever going to fix them …
Big surprise there, eh? VS2010 still crashes when you’re working on WPF apps. The syntax highlighter is still hosed, and you can’t select your favorite keyboard command configuration (all in beta 1) It’s hopeless. Someone needs to step up and provide an alternative IDE that actually works (and doesn’t impose its own screwed up idea of interface colors on the programmer).
See the article was picked up InfoQ (http://www.infoq.com/news/2009/08/VS10-Bugs) and DJ Park responded there with: “Since I’m the original poster, I figured I should jump in here :). I apologize if my responses made it seem like we are no longer fixing minor issues on VS 2010. In fact, the main focus for the VS and .NET teams at this point in the product cycle is to fix bugs and do performance work in order to deliver a high quality release. To support this, we are making a conscious effort to focus on bugs and performance rather than new features or functionality. The decisions made around the EnvDTE bugs were targeted decisions and should not be taken as a broader indication that we are no longer fixing bugs.
To shed some light around the decisions regarding these C# code model bugs, the main reason we decided not to fix these issues is because we are making longer term investments in a public language model. This API will do a much better job than the existing Code Model in surfacing our compilers and will provide a richer representation of code. As a result, we decided to limit our investment in EnvDTE/CodeModel and treat regressions of existing functionality with higher priority. The bugs in question, while important, existed in previous releases.
Thanks,
DJ”
Hey Carlos – Thanks for raising the thoughts/concerns. I wanted to jump in to provide some more context on the bugs you mentioned. I’d be happy to talk about this further if you’d like, so just let me know. (Quick note: I’m taking the excerpt below from a response I posted on InfoQ)
First of all, I apologize if my responses made it seem like we are no longer fixing minor issues on VS 2010. In fact, the main focus for the VS and .NET teams at this point in the product cycle is to fix bugs and do performance work in order to deliver a high quality release. To support this, we are making a conscious effort to focus on bugs and performance rather than new features or functionality. The decisions made around the EnvDTE bugs were targeted decisions and should not be taken as a broader indication that we are no longer fixing bugs.
To shed some light around the decisions regarding these C# code model bugs, the main reason we decided not to fix these issues is because we are making longer term investments in a public language model. This API will do a much better job than the existing Code Model in surfacing our compilers and will provide a richer representation of code. As a result, we decided to limit our investment in EnvDTE/CodeModel and treat regressions of existing functionality with higher priority. The bugs in question, while important, existed in previous releases.
I really hope once and for all MS will fix the damn slow intellisense issue that we’ve been struggling with in VB.NET projects since VS 2005!
I have posted numerous bug reports, memory dumps etc etc, and then supposedly it was fixed in SP1, which IMHO made it even slower.
Just give us the option to turn off background compiling, PLEASE!
>> Too bad. I’m talking about minor bugs that should be easy to fix, not ones requiring architectural changes that I understand will be postponed.
I hate it when other developers can decide how difficult someone elses bugs are to fix. We don’t have a clue of the complexity of the code for VS2010. To give such a broad statement about bug fixes is detrimental to us all !!
Don’t forget, it’s not just a question of going in, changing the code to do it properly and releasing it. They have probably got thousands of tests to run against a single change – and this is something that has to be factored in when deciding if a bug should be fixed or not.
As an MVP, I thought you may have more aware of that fact than others.
SimplyGed,
While you are right that it can be difficult to estimate the difficulty of fixing a bug, I have a clue about the minor (IMHO) bugs that I reported because my add-in has a layer on top of the VS code model that in turns has bugs like those, and I know what it took to fix those bugs in my case (most of the time a couple of lines code). About passing tests for the code model automation, they should be automated so there is no much to be factored there.
In fact, they are not fixing the bugs not due to complexity or simplicity, it is just because they are no longer investing a minute in the actual code model as they explained to me and I posted later (I will update this post to reflect that).
Beta 1, Beta 2, Beta 3, RC1, etc….Will the product still be called VS 2010!