Hi Keith, Thanks for your detail explanation.
Because I use Cecil as a complete replacement of System.Reflection, and supposed Cecil worked same as System.Reflection for this case. And now I know I was wrong. Regards, Wicky On 3月27日, 上午7时53分, Keith <[email protected]> wrote: > Hi Wicky, > > Cecil is pretty much just an object wrapper on the .NET metadata. > There's a 1-to-1 correspondence between TypeDefinition, for example, > and an entry in a module's TypeDef table (Partition IIB, 21.34). Same > for other classes in Mono.Cecil. To use Cecil effectively, you really > need to understand the table structure of metadata. See The Common > Language Infrastructure Annotated Standard by Miller and Ragsdale, or > Expert .NET 2.0 IL Assembler by Lidin. > > For example, your TestWin.Test has as parent interface type > IEnumerable<ExpressionType>. In Cecil, this is just a TypeReference (a > GenericInstanceType, actually), an entry in the TypeSpec table which > references 2 other entries in TypeRef. A TypeReference doesn't give > you its methods; you have to Resolve() IEnumerable<ExpressionType> to > its TypeDefinition, which corresponds to a TypeDef entry in the module > where it's defined (in mscorlib.dll), and that represents > IEnumerable<T>. When you get its methods, they are AS DEFINED. > > Test::GetEnumerator (the generic one), also uses !0 in its ReturnType > since its metadata signature must exactly match that of the method > it's implementing, in this case IEnumerable<T>::GetEnumerator. (I > believe that's the reason.) > > System.Reflection (SR) is a bit higher-level. Its objects don't > correspond directly to metadata entries and signatures. In this case, > IEnumerable<ExpressionType> is a System.Type which will give you its > methods as seen from that type's point of view. Therefore, its > GetEnumerator()'s ReturnType is the Type IEnumerator<ExpressionType>. > > Don't anyone think I'm bashing Cecil. Just explaining how it works by > design. And SR has certain well-known drawbacks that Cecil doesn't > have, in particular, once you load a System.Type, it's integrated in > the runtime. (To load an assembly, all assemblies it references must > be loaded. Can't inspect conflicting assemblies. Can't currently > unload assemblies.) Cecil treats its objects as pure data and has no > such problems. > > I have in mind to create an alternative to SR and Cecil with the best > of both: > + Type/Method objects are high-level, as in SR; easier to use > + Objects are pure data, as in Cecil; prereqs not required > + Better performance (much less typecasting) > + Smaller memory footprint (fewer unused empty collections) > + Easier to insert/inject IL > + Documented > If any company would like to sponsor this effort, please contact me. > > -- Keith --~--~---------~--~----~------------~-------~--~----~ -- mono-cecil -~----------~----~----~----~------~----~------~--~---
