Roslyn: Expected behavior for Go To Definition for metadata references

Created on 19 Jan 2018  Âˇ  26Comments  Âˇ  Source: dotnet/roslyn

The Navigate to Decompiled Sources feature recently added is the first step towards a better F12 experience. This issue describes the more complete picture for how this experience should eventually look.

⚠️ This workflow is currently just a draft

  1. Start with the metadata reference
  2. Locate the correct runtime assembly from the metadata reference (accounting for execution environment and assembly binding redirection)
  3. Locate the symbols for the runtime assembly
  4. Using the symbol file and/or symbol server, locate the original source file(s) for the symbol getting decompiled
  5. If step 3 or 4 fails, decompile the symbol from the runtime assembly using ILSpy
  6. If step 2 fails, attempt steps 3-5 using the metadata reference instead of the runtime assembly
  7. Otherwise, don't attempt to decompile
Area-IDE Discussion Feature Request InternalAsk Story

Most helpful comment

Hello again, we're nearing almost 2 years since this issue was first created.

Now that we have 3.1 out of the door (big thanks for lots of amazing features), has there been any progress on this issue?

Seems like it's assigned Priority 1, which makes me very hopeful for v16.5 !

All 26 comments

/cc @kuhlenh @jasonmalinowski @siegfriedpammer

A few comments:

  • I think we should first determine if we can find the original source locally - in the PDB (embedded), in debugger source cache, etc. If we can we should display it.
  • Otherwise, we should use the current Metadata As Source implementation that only displays signatures and doc comments. The benefit is that you don't need to agree to anything legal at that point and it's fast. Based on my personal experience in most cases I just want to see the signatures of the public APIs and doc comments.
  • Then we should have 2 gestures (like expanding a collapsed method body or buttons in gold bar etc.):
    1) One that triggers symbol and source resolution from symbol servers.
    2) One that runs disassembly.

I think we should first determine if we can find the original source locally - in the PDB (embedded), in debugger source cache, etc.

This is step 4 of the original workflow.

Otherwise, we should use the current Metadata As Source implementation that only displays signatures and doc comments. The benefit is that you don't need to agree to anything legal at that point and it's fast.

This is a somewhat orthogonal discussion (if/how to trigger Go To Definition separately from "Show Signatures"). Given the decompiler is currently only enabled at the explicit request of a developer, I believe it's reasonable to assume that the use of ILSpy in these cases is the desired behavior.

I would love to see this. If this feature is implemented in sync with SourceLink, it can make debugging libraries so so much easier.

Now, if you want to put a break-point inside a class, you have to find a path of step-into's that lead to the source file to be opened. Then, you can put you break-point and see how the code works.

In fact, finding the "path of step-into's" can be very tricky, as the assemblies are optimized. I once spent nearly 4-5 hours and couldn't find the source of my problem. Then I switched to using ILSpy and I found it in less than an hour. And I was just disappointed that I couldn't put a break-point there and see the code live and in action.

Is true! Is true:

I support this:

https://github.com/dotnet/sourcelink/issues/169

"
@ctaggart Yes, we need a tool that navigates directly to the source in the IDE so that we can analyze the underlying implementation and debug the current code directly at run time.
@chuckries Java in the IDE to download the source code, can be directly in the current project to view the source code, such as the JDK source code, observe these implementations, can improve their development capabilities, and. NET to view the source code is complex, we need to use the Anti-compilation tool (Ilspy) or from git to get the source code

I think it has a positive effect on the development of the community and can benefit more. NET Developers
"

https://github.com/dotnet/sourcelink

I think the people of dotnet foundation are "stand still and refuse to make progress ", they don't and wouldn't to think about why more and more .net programmer turn to Java!

Is there any progress on this? Resharper has had this for a decade now.

This is extremely useful functionality, for quickly verifying assumptions instead of scouring the internet for source files and documentation!

isnt dnspy the right tool for the debugging? https://github.com/0xd4d/dnSpy

@oliverjanik I agree. Visual Studio is getting to a point where I almost don't need resharper anymore. With IntelisenseExtender (which btw, should also be a standard option), this is basically the only thing I really need to be able to move to a leaner non-resharper world.

When you've split your business code across several nuget packages with interdependencies, this sort of support is a pretty vital analysis feature, so I hope this will get some more attention soon.

Wish I could help, but I'm way too scared of anything this close to metal. ;)

Honestly, even having just the metadata available would be a massive step up for me. Often, I'm just looking for what members a given library type or class supports.

I notice the hover tooltip over a type in VS already shows a truncated form of this information--maybe this could take a multi-phased approach?

Currently even the metadata is not available in its full form for display via Go To Definition for external libraries, so if we started there it would add a lot of value I think.

Honestly, with .NET Core being open sourced, I kind of expected to be able to F12 into .NET Core functions. My immediate reaction to the current F12 behavior for .NET Core was "well where's the source code?" (now I know I can find it on github, but still...). So for me, this issue feels like a logical feature following from the awesome open sourcing work done by the .NET Core team. I would really like this feature. :)

Embedded source and SourceLinked source should be preferred over decompiled source. This is one of the things that makes me turn ReSharper back on.

Oren Novotny, Kevin Pilch, and Rich Lander suggested this too: https://twitter.com/runfaster2000/status/1148348176283234304 so maybe we'll see something soon?

Related ask from: https://developercommunity.visualstudio.com/content/idea/468799/integrated-decompiler-for-c-or-other-supported-lan.html

visual studio should have a de-compiler for nuget packages or an option to view source code when clicked on a method or class, and other options like go to implementation scope is limited to project code but it should be extended to nuget package source also for now it only shows class metadata but full source must be shown

there are other plugins like dotpeek but paid not all can offord that

What are the work items on roslyn and sourcelink needed to make this happen?
Has someone investigated it already?
If there is a high level design it would be nice to flesh it out so the community can help picking up the work.
I would love to help on this but I expect this requires some work on the Visual Studio side, so I believe it can not be implemented without some major upfront design.

Thank you!

Adding Related Customer Feedback:

"Setting a breakpoint in source should work, even if the source was decompiled. If from Sourcelink, it works, but you’re left in this weird not-quite-real-source mode where you can’t F12 on many types. It seems like VS loses all references and is in some disconnected source. If in decompiled source, I need symbols to also be generated and imported."

@mikadumont i feel like this moves the goalpost a little to much.

This issue is about the current state of SourceLink clients forcing users to do backflips to do something technically simple. The customer feedback you posted is coming from a place where we would need to be able to:

  • Write out symbols from decompiled IL with line information picked up by the debugger
  • magic ahead-of-time download of source files (whereas right now sourcelink downloads source files on-demand)

This is a massive increase in effort in comparison to what this issue actually only asks for: Execute the same command on Go-To-Definition that is executed when F11'ing into sourcelinked assemblies.

I agree with the customers sentiment - it was what all this at the end should look like. But it goes way beyond this issue, which would only prolong this issue's lifetime if we were to add it to the goals of this issue.

Hello again, we're nearing almost 2 years since this issue was first created.

Now that we have 3.1 out of the door (big thanks for lots of amazing features), has there been any progress on this issue?

Seems like it's assigned Priority 1, which makes me very hopeful for v16.5 !

The same behavior in VS 16.5.4

Still there is not any progress ?!

I can't add anything useful, besides remarking that this feature would be super-useful for ASP.NET Core, because it uses a myriad of extension methods that configure and inject services into the DI container, and it's often necessary to know what is exactly happening to avoid misconfiguration, incorrect ordering or redundant code.

Come on ! Three years !
On this feature ,Java is far ahead!
Does mircosoft abandon dotnet ?!

@athinboy I think there have been a few changes in some of the latest preview versions of Visual Studio, but don’t quote me in that.

@athinboy This is a priority work item, but it's taking time to ensure the feature works seamlessly across all the different ways users can interact with source code. In the meantime, the Navigate to Decompiled Sources feature can be enabled to provide a portion of this experience. 😄

@sharwell
thanks for your work!
I mean,it progress slow and late. there are too many software that without complete、exact document,even the source code of roslyn、of dotnet。
for example, in https://www.cnblogs.com ,high qualified documents become fewer and fewer ,because the people can not
to check and debug the source code .
i think it is top 1 priority that to browse 、check、debug the source code conveniently, it is proved in java.
sorry for my complaint and bad english. but what i said is true!
thanks again!

@sharwell it seems blocked on partner team,what does it mean blocked? is there any process on this?

Really hope for this feature, big thanks for the team working on this.

Was this page helpful?
0 / 5 - 0 ratings