How can we help you today? How can we help you today?

Build 381: Issues when navigating to members in the IDE

Hi,

I've encountered some issues when using the "Go to definition" from the context menu in the IDE on a type or member:

* navigating to an inherited property of a class you don't have the sourcecode of (or is decompiled), a message dialog pops up with message "Index and count must refer to a location within the buffer.Parameter name: startIndex", with the following details:

System.ArgumentOutOfRangeException
at System.String.Join(String separator, String[] value, Int32 startIndex, Int32 count)
at .?.?(String )
at .?.(String )
at .?.??(String )
at .?.?()
at (Object )
at ?.?.?(ILog , IWin32Window , MethodInvoker )

* Navigating to inherited methods from classes in decompiled assemblies lands me on the top of the sourcefile, not in the implementation of the method.

* Sometimes (I haven't found out how to trigger the issue consistently yet), when navigating to a class or member that I don't have the sourcecode of, it launches .NET Reflector and finds the method in reflector (correctly, b.t.w.), without opening the code in the IDE (the default "interface" source functionality already present in VS). Maybe this is as intended, but then:
a) The behaviour should consistent
b) I'd like to make a feature request to toggle this functionality on/off

All in all, sofar, I like it very much.
keep up the good work & regards

Willem
Willem.van.Rumpt
0

Comments

2 comments

Sort by
  • Alex D
    Hi Willem,
    I'm putting some improved error handling in the next build that'll mean you can send me a stack trace that hasn't been completely destroyed by our obfuscator. Then we'll be able to fix that issue with inherited properties.

    I'm not sure how to reproduce the problem with inherited method taking you to the top of the source file. Could you give an example where it happens?

    I understand about it opening reflector instead of decompiled code in VS in some circumstances. Unfortunately we just have to fix these case-by-case, so I'd appreciate you letting me know any examples you find.

    We are thinking about making opening reflector optional, would you like it enabled by default (assuming we fix it all the time when you've already decompiled the assembly)?

    Thanks,
    Alex D
    0
  • Willem.van.Rumpt
    Hi Alex,
    I'm not sure how to reproduce the problem with inherited method taking you to the top of the source file. Could you give an example where it happens?

    I have a hard time tracking down what might be causing the trouble. I encountered it when navigating to base.OnInit() in the Control class in the System.Web assembly. I made an isolated test project to rule out as much as possible and found the following weird behaviour:

    * navigating to base.ResolveUrl(), base.CreateChildControls(), base.LoadControlState() and base.SaveControlState() work as expected
    * navigating to base.OnInit(), base.OnLoad(), base.AddedControl() and base.Render() brings me to the top of the file

    I tried several other inherited members, some work, some don't. The last feeling I got was that it has something to do with the types of parameters. Methods with parameters of type System.EventArgs and types in the same namespace as the assembly were failing. The ones with no parameters, or parameters of type Object and String seem to work.

    If I find more, I'll let you know.
    I understand about it opening reflector instead of decompiled code in VS in some circumstances. Unfortunately we just have to fix these case-by-case, so I'd appreciate you letting me know any examples you find.

    I'll let you know when I encounter them. Sometimes it gets a bit confusing and I'm not sure anymore if I was expecting it to popup or not, since I was focussing on something else.
    We are thinking about making opening reflector optional, would you like it enabled by default (assuming we fix it all the time when you've already decompiled the assembly)?

    Optional is always good :D
    I think my preferences would go to disabled. I think I would extend the option to "off / only in absence of source / always". I don't like windows popping up or stealing focus.

    I consider Reflector to be (or rather: I use it as) an external tool window of the IDE, replacing the build-in classbrowser, and personally, I'm not that fond of toolwindows floating around.

    The ideal situation for me would be to (be able to) integrate (dock) Reflector in the IDE. The next best thing would be Reflector as it is now, but with the option of displaying the disassembly in the VS IDE.

    Regards,
    Willem
    Willem.van.Rumpt
    0

Add comment

Please sign in to leave a comment.