Clarification on my previous post "Microsoft no longer fixing (small) bugs for VS 2010"
My post of a week ago "Microsoft no longer fixing (small) bugs for VS 2010, now focusing on stabilization and performance" has been commented (see the Comments section) by the DJ Park (C# IDE, Program Manager) explaining that the three bugs in the C# code model that I reported:
EnvDTE.CodeFunction.Parameters causes COM exception with add/remove methods of C# event
EnvDTE.CodeFunction.Attributes doesn't return attributes for get/set property accessors in C#
and whose original answer was:
"We unfortunately won't be able to address the limitation in the
Project.CodeModel for the VS2010 release given that we're purely
focused on stabilization and performance but I've marked this bug down
to be considered as we begin planning for the next release. In the
meantime, I'm going to mark the bug as a "Wont Fix" but please feel
free to re-activate if you have any further questions/comments."
aren't going to be fixed not because they are no longer fixing minor bugs on VS 2010 Beta 1 but because they are working in a new code model:
"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
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
Since that second explanation was missing in the first response to my bugs in Microsoft Connect, that led me to the false conclusion of my post. The explanation is also now in a new fourth bug that I reported a couple of days ago: