Updating references to a generic class?

[mousecurs0r]

Updating references to a generic class?

[mousecurs0r]

Yes, I've been handling non-generic types without issue.

[ds5678]

Did you verify that renaming non-generic fields poses no issues?

[Washi1337]

There is unfortunately nothing built in (yet) to do assembly level renaming/refactoring of symbols. You will have to do the renaming of related objects (i.e., member references) yourself.

That being said, you can get access to all member references in the module, even in high level mode. Have a look at e.g., ModuleDefinition::GetImportedMemberReferences. For other types of members you can also query ModuleDefinition::LookupMember or TryLookupMember which takes arbitrary metadata tokens and attempts to resolve them to their representative IMetadataMember object.

[mousecurs0r]

Thank you! The name GetImportedMemberReferences (and GetImportedTypeReferences) is kind of confusing; I thought "imported" referred to members defined outside of the module. Thanks for the hint with LookupMember! (which is also kind of confusing, I guessed "type member" instead of "metadata member"). Looking at the source for the GetImported methods I see that I can simply go through all of the RIDs, which is definitely good enough. Still, it would be nice to have first-class support for iterating through all (or at least a few more) of the other tables in high-level mode, though I understand why it isn't necessary for most use cases.

That aside, why is memberRef.Resolve() returning null? Does the method only check if the ref's Parent is a TypeDef, ignoring TypeSpecs? If so, is that intended behavior? (I guess that makes sense, since TypeSpecs don't truly have members of their own and pointing to the original generic's member would be inaccurate). Anyway, thanks again for the help!

[Washi1337]

I thought "imported" referred to members defined outside of the module.

A member being imported merely means it is also present in the underlying MemberRef table. Whether it is an actual reference to an external member is not included in this definition. As you have seen with this example, a member reference can also refer to members in the current module.

Still, it would be nice to have first-class support for iterating through all (or at least a few more) of the other tables in high-level mode

There are two main reasons this was not done for all members. 1) Not all metadata tables have a representing IMetadataMember (such as EventMap and PropertyMap). 2) To keep the API relatively simple, we did not want to add too many "convenience" methods to the public APIs, or else one cannot see the forest from the trees. That being said, I am open to suggestions on which helper methods should be added. You can of course also make your own extension methods to ModuleDefinition that do these things for you if you need them. Indeed, it is just iterating over all metadata tokens and calling LookupMember on each of them.

That aside, why is memberRef.Resolve() returning null? Does the method only check if the ref's Parent is a TypeDef, ignoring TypeSpecs? If so, is that intended behavior? (I guess that makes sense, since TypeSpecs don't truly have members of their own and pointing to the original generic's member would be inaccurate). Anyway, thanks again for the help!

I cannot seem to reproduce this problem locally. Do you have a binary that you could share for which this is the case?