Roslyn: Public API for IMetadataAsSourceService

Created on 16 Jan 2017  路  4Comments  路  Source: dotnet/roslyn

I have just found IMetadataAsSourceService interface that enables me to replace default metadata view with decompiled code from ILSpy in about 50LOC - see https://github.com/icsharpcode/ILSpy/pull/791 It is sooo cool :), but the interface is internal so I had to hack it a bit. Would it be possible to make it an official extensibility point?

Area-IDE Concept-API Feature Request

Most helpful comment

In addition to returning the source document, it would be tremendously helpful if the implementation of IMetadataAsSourceService could provide symbol load information. This would allow users who disable Just My Code and then disable automatic symbol loading (for performance reasons) to still set breakpoints in source files provided by the IMetadataAsSourceService. Furthermore:

  • One implementation of IMetadataAsSourceService could locate source files for NuGet packages via Symbol Source. The associated symbols would be provided through there as well.
  • One implementation of IMetadataAsSourceService could provide source files by decompiling the bytecode. The associated symbols would be generated during the decompilation process and provided through there as well.

All 4 comments

In addition to returning the source document, it would be tremendously helpful if the implementation of IMetadataAsSourceService could provide symbol load information. This would allow users who disable Just My Code and then disable automatic symbol loading (for performance reasons) to still set breakpoints in source files provided by the IMetadataAsSourceService. Furthermore:

  • One implementation of IMetadataAsSourceService could locate source files for NuGet packages via Symbol Source. The associated symbols would be provided through there as well.
  • One implementation of IMetadataAsSourceService could provide source files by decompiling the bytecode. The associated symbols would be generated during the decompilation process and provided through there as well.

@sharwell

provide symbol load information

What kind of symbol load information do you mean? You can put a breakpoint to any source file. Binding the breakpoint however requires the PDB to be loaded. So if you have symbol loading disabled how would the debugger bind it?

One implementation of IMetadataAsSourceService could locate source files for NuGet packages via Symbol Source

I assume we start with an assembly reference. The reference might point to a reference assembly file in a NuGet package. So first we would need to find the right implementation assembly, if the reference isn't an implementation assembly already. Perhaps we could display a list of runtime TFMs in the combobox on top of the editor when showing source from metadata, so that the user can select which implementation to get source for. If the debugging session is active we could ask the debugger what the current runtime is where the referring assembly is loaded to and preselect that one (might not be loaded or the debugger might be attached to multiple runtimes, so that won't always result in a single runtime).

Once you get the implementation assembly we can ask the debugger to find symbols for it. Once we have the PDB we can get the source link or srcsvr info out of it.

Not all metadata definitions have source information stored in the PDBs currently. In fact, only methods with body do. So you won't be able to find source file for any other definitions.

Tagging @rchande and @kuhlenh as well, since this overlaps with the discussion we were just having.

@tmat There are several cases which would be valuable to support.

  1. Symbols provided for a NuGet package

    • Go To Definition shows the source file obtained from Symbol Source (or one of the related source linking approaches)

    • "Symbol load information" is the PDB(s) contained in the same symbol package as the source file

  2. Symbols provided for a reference assembly found in a NuGet package

    • Go To Definition and symbol load information behaves the same way as the previous item

  3. Symbols generated for an assembly

    • Go To Definition goes to a generated source file produced by a decompiler

    • "Symbol load information" is the PDB generated by the decompiler alongside the decompiled output

:memo: It's important to note that we do not need to handle all edge cases (e.g. binding redirection or assembly load event handling that swaps implementation assemblies) in order for this to be a tremendously useful feature.

When a breakpoint is set in a file provided by IMetadataAsSourceService for which one or more PDBs are associated, the debugger will automatically attempt to load symbols for that module, even if automatic symbol loading is disabled. For performance reasons, we may want to limit the symbol resolution to PDBs provided by the IMetadataAsSourceService when automatic symbol loading is disabled.

So you won't be able to find source file for any other definitions.

The fallback case involves (or allows for) automatic decompilation of the IL and production of a symbol file to accompany it.

Was this page helpful?
0 / 5 - 0 ratings