Sometimes I'm wondering how CLI would looked like, if there wasn't Reflection. I allow that CLI is designed in a way to be dependant on meta information. In the broad sense it's only meta information that assembly contains. It's required for verification process, late compilation, GC, and for other services. But concern of mine is Reflection as part of managed library, which exposes meta information.

Well written application usually avoids using of Reflection classes. In rare cases System.Type class is used, but not more then as a handler that identifies class. This is because of fact that whatever operation or service Reflection classes provide, it can be achieved more easily and in more verifiable and strict fashion at compile time.

CLI extensively exploits technique of attributed programming in very diverse it's parts: VM, and JIT recognize special attributres, managed (and not only) languages often support their attributes, and finally managed libraries define immense number of custom attributes. Attributed programming brings power technique of the "meta programming" into the CLI. In order to expose attributes to managed libraries Reflection is used. Architects of CLI implicitly say that in order to use attributed programming you need to inspect types at runtime, extract all required attributes, and you can do whatever you want with these data. This idea, as if proves that Reflection is just required. The disgraceful climax of this technology in my opinion is achieved in xml serialization library (fx), where a C# code is generated from attributes that describe xml serialization of type, and then this code is compiled and loaded, and all of these occur at runtime! This is in the worst traditions of script languages, indeed.

Well, then how to benefit from attributed programming, but without using Reflection at runtime? Let's inspect how attributes are used either by VM, JIT, or managed library. Usually some data is collected, or some verifications are run, or some code is injected or generated. I'd try to move as most of processing as possible out of scope of runtime. And what is the better place then compilation to do such a work; either early compilation when sources are compiled or late compilation (JIT, which in my opinion works to late now anyway ) when IL instructions are converted in to machine code. What I would add to compilation is ability to generate additional data as a post compilation process. In this way when you would declare new attribute type, you may specify that post compilation operation is to be performed (naturally this means that some method is invoked by the post compilation process for each application of the attribute). This would allow to prepare data, generate or inject code inplace or in satellite assembly. This effectively moves using of meta information out of runtime.