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#
EnvDTE.Project.CodeModel doesn’t retrieve attribute code elements in AssemblyInfo file for 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 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.”
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:
EnvDTE.CodeElement.Name doesn’t include type placeholder for generics types or methods