-
Notifications
You must be signed in to change notification settings - Fork 4.1k
EnvDTE.CodeElement.GetStartPoint(part)/GetEndPoint(part) not implemented for many parts #2461
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hey @carlos-j-quintero - can you let us know whether these are really compatibility issues? From @basoundr's research, it looks like we threw the same exceptions in VS2013. While I know it would be nice to fix them, I am concerned about making changes like that so close to the end of VS2015, without giving time for other extensions to test with the changes. |
On the one hand, these are not really compatibility issues because the GetStartPoint/GetEndPoint methods have been buggy since VS.NET 2002... Any add-in or package using them has to apply a lot of workarounds and patches on top of them to get the correct results, either because they are not implemented, or they cause COMException in some cases, or they return an incorrect result. So, it would be very nice that at some point they are fully implemented and reliable. On the other hand, my extension has all the needed workarounds and patches implemented and as of VS 2015 RC all my integration tests pass. I have had to implement new workarounds specific to VS 2015 for bugs that I have reported but I will be able to remove them once your last fixes are available in VS 2015 RTM (such as #2437, #2355). Notice that most workarounds about GetStartPoint/GetEndPoint rely on CodeElement.Name returning the correct result even on edge cases (such as #2437, which is now fixed but I was able to workaround in VS 2015 RC). Notice that GetStartPoint/GetEndPoint needs unit tests for 6 vsCMPart (whole with attributes, whole, header with attributes, header, name and body), 2 locations (start/end), 2 languages (VB.NET and C#), many code element kinds (namespace...enum item) and lots of edge cases. Bottom line: I would prefer you to fix NEITHER this bug NOR #857 (which is a compatibility break still pending but I have a workaround) until after VS 2015 RTM, for the risk of breaking what now works (although with workarounds). |
Moving this bug out of 1.0, because of the risk of changing this so late in the cycle. |
We're not intending on changing codemodel except where critical or where we have somehow regressed it. It is entirely in maintenance mode. We recommend directly getting C# or VB information through the direct Roslyn apis. |
When you use the EnvDTE.ProjectItem.FileCodeModel to call EnvDTE.CodeElement.GetStartPoint(part) and EnvDTE.CodeElement.GetEndPoint(part), many calls fail as "not implemented"
Steps to reproduce the problem:
namespace Namespace1
{
public class SkipReview : System.Attribute
{
}
[SkipReview]
public delegate void Delegate1(int p1);
[SkipReview]
public interface Interface1
{
}
[SkipReview]
public class Class1 : Interface1
{
}
[SkipReview]
public struct Struct1
{
}
[SkipReview]
public enum Enum1
{
}
}
vsCMPart.vsCMPartWholeWithAttributes
vsCMPart.vsCMPartWhole
vsCMPart.vsCMPartHeaderWithAttributes
vsCMPart.vsCMPartHeader
vsCMPartName
should be "valid" parts (ie, "implemented") for any kind of code element.
vsCMPartBody (not shown in this report) may fail for code elements that lack body (parameters, members of interfaces, abstract method/properties, etc.)
Test also with VB.NET code
The text was updated successfully, but these errors were encountered: