Right now, disassembling methods for nested types shows a blank page because the type name is passed to the loader in a C# format, with dots as separators, while the runtime's formatter uses pluses.
This PR addresses that with a simple workaround in the loader that C#-ies runtime type names. It also adds a comment explaining the motivation behind that decision instead of, for example, passing the properly formatted type string to the loader.
This PR also fixes an issue where the null check was inserted too late and the member access before it would have always failed with a null-ref exception. As far as I can tell, this only impacts local debugging scenarios.
I noticed that the analyzers in the solution produce a lot of VSTHRD010 warnings. Can they be safely suppressed?
If not, I have some free time these holidays and can work on addressing them, as well as #17 (on which I just need guidance on the best approach).
Right now, disassembling methods for nested types shows a blank page because the type name is passed to the loader in a C# format, with dots as separators, while the runtime's formatter uses pluses.
This PR addresses that with a simple workaround in the loader that C#-ies runtime type names. It also adds a comment explaining the motivation behind that decision instead of, for example, passing the properly formatted type string to the loader.
This PR also fixes an issue where the null check was inserted too late and the member access before it would have always failed with a null-ref exception. As far as I can tell, this only impacts local debugging scenarios.
I noticed that the analyzers in the solution produce a lot of
VSTHRD010
warnings. Can they be safely suppressed? If not, I have some free time these holidays and can work on addressing them, as well as #17 (on which I just need guidance on the best approach).