Вопрос сначала получился не очень нормально составленный.

Короче интересно понять как и где располагаются метаданные. Одни метаданные(метаданные о самой сборке) располагаются отдельно.
Если добавить аттрибут к какому-нибудь типу в коде программы, то эти метаданные находятся среди кода IL, самого типа(например среди типа или определния ф-ии).
Вот пример ф-ии Main на языке IL( тегом

выделено описание аттрибута[STATHREAD] в коде IL):


Если в ILDASM.exe при просмотре IL нажать Ctrl+M, то откроются метеданные всех типов.
Вопрос: откуда берутся такие метаданные как кол-во переменных у ф-ии? Они где-то отдельно находятся
или ILDASM.exe их просто щетает при просмотре отражения типов?

Хорошо. С этим разобрались. Метаданные хранятся в потоковых таблицах.
Теперь просматриваем IL код ф-ии Main с помощью ILDASM и видим:
.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 )
// Code size 7 (0x7)
.maxstack 1
.locals init ([0] class aaa a)
IL_0000: newobj instance void aaa::.ctor()
IL_0005: stloc.0
IL_0006: ret
} // end of method Class1::Main[/quot]
Откуда взялись эти данные в коде?
Эти метаданные хранятся и в самом IL коде?
Если метаданные хранятся в таблицах то зачем их дублировать в коде? Или IL на самом деле не содержит никаких метаданных, а только двоичные инструкции , а это
уже конечный результат IL кода после загрузки сборки в память?

Красныи цветом в коде выделены МЕТАДАННЫЕ

Понятно. Т.е. сам код IL не содержит метаданных, а содержит только инструкции. А при компиляции в двоичный код, метаданные компиоируются вместе с IL кодом, или они так и остаются в таблицах?
Например есть ф-ия. до компиляции IL кода этой ф-ии ее параметры и другие типы хранятся в heap таблице, а тело ф-ии в ILинструкциях. Но ведь при компиляции в двоичный код типы парметров и др. типы компилятся вместе с телом этой ф-ии? Или они(метаданные) не компилируются, а CLR при исполнении ф-ии берет ее параметры и др. типы опять из таблиц, а тело ф-ии в двоичном виде берет уже из хеша после компиляции Jit'terom?

Короче разобрались.
Все метаданные хранятся(кроме текстовых и некоторых двоичных) в потоковых таблицах. В этих таблицах хранится и сам IL код. IL код не содержит информации о типах, а содержит только инструкции по управлению данными этих типов. Т.е. если у нас есть какая-нибудь ф-ия, то IL содержит только тело этой ф-ии, т.е. он содержит только инструкции(на подобии что положить в стек), и при этом эти инструкции нейтральны к типам данных(т.е. сам IL не содержит никаких метаданных об этой ф-ии, а содержит только код, который должна выполнить эта ф-ия причем этот код не зависим от типа данных).

Когда стартует компилятор в native код, он собирает информацию об этом методе(метаданные). Он находит тело метода - IL код тела метода(типо-независимые инструкции) и находит метаданные для данного метода(которые лежат отдельно). После этого он компиоирует метод(собирая его по отдельным кускам):
Он компилит тело метода(типо-независимые инструкции IL) в типо-зависимые двоичные инструкции, вытаскивая инфу об этих типах из метаданных.
Вместе с телом он компилит и сигнатуру метода(тоже собирая ее по отдельным кускам, т.к. такие данные как параметры и возврвщвемый тип метода в методанных находятся отдельно).

В итоге получается готовая двоичная ф-ия с определенными типами.
Такие метаданные как манифест, он ествественно при этом не трогает.

Подтверждением этому служит статья о физической организации метаданных на RSDN и цитата ведущего разработчика microsoft:
В итоге получается готовая двоичная ф-ия с определенными типами.
авторРешение предпочесть запуск native кода интерпретации, оказало большое влияние на форму IL. Это поменяло набор включенных инструкций, и порядок их расположения. Если вы посмотрите на два IL, то сможете отметить, что они очень разные. Чувствуется, что наш IL нейтрален к типам. Нет информации в инструкциях, которая говорила бы о типах аргументов. Только подразумевается, что было положено в стэк. Этот подход делает IL более компактным. JIT компилятору в любом случае нужна эта информация, так что нет смысла хранить ее в инструкциях. Теперь вы знаете о некоторых разных решениях, которые позволяют проще переводить IL в native код.