> That's exactly the question - why write code that does not work in 5% of > cases? It is evil. > If that is only the reason for the 'MainModule' to be (and I hope this is > the *only* reason), then I'll use 'AssebmlyDefinition.Modules' always. > So, is it the *only* reason for 'MainModule' to be born?
I don't think it's the only reason. Cecil mimics the ECMA-335 metadata format. The ECMA-335 specification defines one of the modules as special (the "manifest module"), so Cecil would naturally expose this. Here is some text from the specs (Standard ECMA-335, 4th edition, from June 2006): "When an assembly contains more than one file with metadata, each of the files describes the types defined in the file, if any, and one of these files also contains the metadata describing the assembly (including the names of the other files, their cryptographic hashes, and the types they export outside of the assembly)." [Partition I, 9.6] "An assembly shall contain only one manifest amongst all its constituent files. For an assembly that is to be executed (rather than simply being dynamically loaded) the manifest shall reside in the module that contains the entry point." [Partition II, 6] "Tools should be able to retrieve a single module, the manifest module, to determine the complete set of types defined by the assembly. Therefore, information from other modules within the assembly is replicated in the manifest module. By convention, the manifest module is also known as the assembly." [Partition II, 6.7] And so on. Whether the distinction between the main module and other modules makes a difference in your specific application is probably for you to know. When you iterate the types in an assembly, you should probably use the Modules collection rather than only looking into the MainModule if you want to support all possible .NET applications Cheers, Fabian -- -- mono-cecil
