CustomDebugInformationTableTreeNode: split Kind, fix Offset, add EncStateMachineStateMap,

[fowl2]

Improvements for CustomDebugInformationTableTreeNode:

• add kind EncStateMachineStateMap as "Edit And Continue State Machine State Map (C# / VB)"
• split Kind column into Kind, KindGuid, and KindGuidHeapOffset columns
• Show offset for embedded
• add Parent kind to tooltip
• Format value blob heap offset to 8 digits

Before:

Parent Tooltip:

After:

Parent Tooltip:

[siegfriedpammer]

Thanks for adding the missing custom debug info kind.

Would you mind explaining why you think the other changes are needed? Thanks!

[fowl2]

split Kind column into Kind, KindGuid, and KindGuidHeapOffset columns

Because previously this was just all combined together, unlabelled in a single column.

Show offset for embedded

Because the column was blank before.

add Parent kind to tooltip

Because otherwise @30000001 is pretty opaque. I'm working on linking this up.

Format value blob heap offset to 8 digits

I think this was to be consistent with other view.

Hope this helps

[siegfriedpammer]

split Kind column into Kind, KindGuid, and KindGuidHeapOffset columns

Because previously this was just all combined together, unlabelled in a single column.

That was a deliberate design decision. I only wanted to show columns that actually exist in the physical metadata format (except for RID, Token and Offset, which are kind of necessary to make the table usable). Additional info / text representation is usually added in tooltips. The reason I added the text representation in that column (instead of just showing the raw GUID offset), is because I wanted to be able to filter the debug info kinds by name.

I think adding two new columns to that table for one piece of information puts too much emphasis on that piece of information. Especially KindGuidHeapOffset seems to be quite useless. How about adding a tooltip that contains the information? I would keep the "human readable" description of the kind directly in the table cell (to allow easy filtering) and move the GUID representation to the tooltip. And probably get rid of the GUID heap offset altogether. What do you think?

Show offset for embedded

Because the column was blank before.

Yeah, I fixed that in my latest commit. It now shows n/a like in all the other tables. The offset is generally not useful, when the debug metadata is embedded, because the stream containing the data is compressed and there is no physical offset in the image, where the offset could refer to.

add Parent kind to tooltip

Because otherwise @30000001 is pretty opaque. I'm working on linking this up.

I am not against changing that in general, however, I think we could use the format: <token> (<table name>). What do you think?

Format value blob heap offset to 8 digits

I think this was to be consistent with other view.

I think, I deliberately left it like that to distinguish heap offsets from tokens.

I hope you don't mind discussing this with me further, so we can come to a conclusion...

[fowl2]

I think adding two new columns to that table for one piece of information puts too much emphasis on that piece of information. Especially KindGuidHeapOffset seems to be quite useless. How about adding a tooltip that contains the information? I would keep the "human readable" description of the kind directly in the table cell (to allow easy filtering) and move the GUID representation to the tooltip. And probably get rid of the GUID heap offset altogether. What do you think?

As someone not that familiar with the format I couldn't identify the various parts without the column headings and I just didn't want to remove some functionality in case some one was relying on them for some reason. It absolutely makes sense they don't need to be in as much focus.

Yeah, I fixed that in my latest commit. It now shows n/a like in all the other tables. The offset is generally not useful, when the debug metadata is embedded, because the stream containing the data is compressed and there is no physical offset in the image, where the offset could refer to.

Ahh embedded implies compressed - that I wasn't aware of. I guess it's completely hidden from the object model. How about a tool tip explaining that because the stream is compressed the offset might not be as meaningful?

I am not against changing that in general, however, I think we could use the format: <token> (<table name>). What do you think?

Sure. Would that be with the expanded version on the second line? (eg. method names get reaaaalllly long)

I think, I deliberately left it like that to distinguish heap offsets from tokens.

Makes sense. Could we use additionally use different column heading to make it clearer?

I hope you don't mind discussing this with me further, so we can come to a conclusion...

Of course - thanks for the project and engaging with me so readily!

[siegfriedpammer]

Sure. Would that be with the expanded version on the second line? (eg. method names get reaaaalllly long)

I would only add that for items that previously had no specialized tooltip and were just showing @XXXXXXXX.

Ahh embedded implies compressed - that I wasn't aware of. I guess it's completely hidden from the object model. How about a tool tip explaining that because the stream is compressed the offset might not be as meaningful?

So you would still want to display the offset instead of "n/a", or just add an explanatory tooltip, as to why it shows "n/a"?

Makes sense. Could we use additionally use different column heading to make it clearer?

Yes, any suggestions? :)

[siegfriedpammer]

I have made some adjustments to your code following our previous discussion. Thank you for contributing and discussing things with me. If there is anything else you would like to see changed, please feel free to open an issue.