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 -~----------~----~----~----~------~----~------~--~---
