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?
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:
IMetadataAsSourceService
could locate source files for NuGet packages via Symbol Source. The associated symbols would be provided through there as well.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.
: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.
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 theIMetadataAsSourceService
. Furthermore:IMetadataAsSourceService
could locate source files for NuGet packages via Symbol Source. The associated symbols would be provided through there as well.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.