Replies: 1 comment
-
It was even called out by David Broman (https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/profiling/davbr-blog-archive/Metadata%20Tokens%2C%20Run-Time%20IDs%2C%20and%20Type%20Loading.md#future) that in future some improvements should be done for TypeRef resolution. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Currently it is not possible to resolve TypeRef to TypeDef and ModuleId, even if target assembly already loaded.
IMetaDataImport::ResolveTypeRef
will not work if assembly with same id loaded more then once. It can happen if assembly loaded in multiple AppDomains (.Net Framework, probably can still be mapped manually by resolving AppDomain for assembly) or if assembly loaded in multiple Assembly Loading Context.There is no profiler API to get information about belonging assembly to Assembly Loading Context or there relations.
We need method like
HRESULT ICorProfilerN::ResolveAssemblyReference([in] AssemblyId scope, [in] mdAssemblyRef reference, [out] AssemblyId *pAssemblyId)
or something similar. It may set pAssemblyId to nullprtr if assembl is not resolved yet.In fact, resolving TypeRef even with that info may be hard, as it additionally may require to properly follow TypeRedirects. Having helper method may be great, something like
HRESULT ICorProfilerN::ResolveTypeRef([in] ModuleId scope, [in] mdTypeRef reference, [out] ClassId *pClassId)
- or something similar that will work with generics.Beta Was this translation helpful? Give feedback.
All reactions