Docs around Type and TypeInfo/Examples?

[msedi]

There is not so much well documented info around Type and TypeInfo, as well as what GetTypes, ExportedTypes, DefinedTypes really do.

Additionally what happend to the separation of Type and TypeInfo as shown in https://devblogs.microsoft.com/dotnet/evolving-the-reflection-api/. I think I remember (but I can't find the blog anymore that this strict separation has not been done because of too many problems that arose.

I'm especially interested in the MetadataLoadContext. Since you get the "full" Type it's not quite clear to me what the GetTypeInfo() does. I understand somehow that you didn't want to introduced a ReflectionOnlyAssembly and instead throw exceptions on methods where the full reflection is not available.

For me it's currently a bit trial and error and it would be nice if someone could guide me in a direction where I can find some more docs and infos around this topic.

[huoyaoyuan]

I remember TypeInfo was introduced for limited reflection for Windows Store. Now are there any real difference?

[msedi]

@huoyaoyuan: I'm not sure. TypeInfo derives from Type. From the explanation https://devblogs.microsoft.com/dotnet/evolving-the-reflection-api/ they say you can get rich type information by getting the TypeInfo, where as for "poor" information you get the Type (without the need to load the dependencies).

It seems that the original intention was that Type is something where you can do reflection but you cannot instantiate the Type itself, because the necessary information was not loaded.

Originally, when ReflectionOnlyLoad was still available I assume before the split Type is where the ReflectionOnly flag was set to false, where in TypeInfo it is set to true, but I'm not sure if this is true.

The problem is, that on Type you can request TypeInfo (with GetTypeInfo()) which still results in a type that you cannot instantiate. I agree that this is maybe not what you want when being the MetadataLoadContext but it's a but confusing what happens. I assume that the split would have caused to much pain for existing codebases,

Furthermore if I load the same type (lets say class MyOwnClass {}) in the MetadataLoadContext and another the the AssemblyLoadContext and compare the types they do not match. I somehow understand that this might be the case because they are from different contexts but in the end they should be identical types if the metadata and the type references are the same. Then the question is how shall I compare types from two different contexts?

[alexrp]

Then the question is how shall I compare types from two different contexts?

It depends. Do you know for certain that the Type instances you're comparing come from the same module on disk? If so, you can compare the MetadataToken for best performance. If not, you should probably be comparing by AssemblyQualifiedName.

[msedi]

@alexrp: Yes, currently I know that they are coming from the same assembly/module and I'm currently checking against MetadataToken or AssemblyQualifiedName. It only seems to me like a hack but if this is the preferred way how to do it, I'm OK with that.

[reflectronic]

There is no functional difference between Type and TypeInfo as of .NET Core 2.0. Calling .GetTypeInfo() simply creates a TypeDelegator around the Type you pass in. All of the method calls on TypeInfo are forwarded to equivalent members on Type.

[msedi]

@reflectronic : Thx for the info and thanks for mentioning TypeDelegator. I was about to write my own wrapper and didn't know that one exists.