New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
System.Reflection.Metadata should provide easier signature reading API #13931
Comments
For reference, here's the classes I've developed for my own use. tunnelvisionlabs/dotnet-compatibility#24 I like the fact that they are lightweight, but they are probably sub-optimal for certain use cases for a few reasons, such as lack of caching nested signatures. |
Early draft of signature decoder is in dev/metadata branch now (has been for a while) but I didn't get around to updating this issue. Priority is lower on this as we won't ship it until some time after VS 2015 RTM. Any help refining the API and/or adding tests is welcome in the meantime. |
Can you publish the mini spec? |
@devhawk done. |
@terrajobst This is ready for API review. |
Design changes to discuss:
|
We reviewed the API today and have some minor feedback. Please switch back to |
@nguerrera I think we implemented all changes we wanted. Can we close now? |
Yes, all of the changes were implemented. |
👍 |
@nguerrera Can you update the Milestone for this issue? Edit: I just realized it might not be possible since this is just one assembly in a repository with many. |
EDIT 12/3/2015 - Replaced entire description with the detailed proposal matching PR dotnet/corefx#4809
Today, System.Reflection.Metadata provides low-level access to ECMA-335 CLI metadata, but only provides signatures as blobs that must be parsed with direct knowledge of the format as described in the section II.23.2 of the CLI specification. There is a
BlobReader
for reading various elements out of blobs, but it is up to the caller to read the right things at the right positions.This was by-design as the library is designed to sit at the lowest level behind the scenes of higher level API such as Reflection proper, Roslyn, or CCI.
The challenge with signatures is that they are variable-length and encode tree structures, and each higher level model that could sit on top of System.Reflection.Metadata will have different representations for the trees. We do not want to introduce an API to build a fully-formed tree that then has to be traversed and rewritten to match the actual use case.
This proposal is therefore a middle ground between:
It works as follows:
TType
, for type symbols and implementsISignatureTypeProvider<TType>
. (See full API spec below).TType
that represents this primitiveTType
that represents this TypeDefinitionTType
that represents an array of this other TTypeSample Usage
Given a suitable
TypeSymbol
andTypeSymbolProvider : ISignatureTypeProvider<TypeSymbol>
, here is code walking all of theTypeSymbol
's for every field, parameter, and return type:Full API
Additions to existing types
These provide convenience entry points. There are other use cases where you want to parse only part of a signature or a signature that you did not obtain from the metadata reader. For that, the
SignatureDecoder
New types
Notes
ISignatureTypeProvider<T>
is for futureTypeNameParser
andCustomAttributeDecoder
(still under development in dev/metadata branch), which share some but not all of the same requirements for a type provider as theSignatureDecoder
The text was updated successfully, but these errors were encountered: