Анализ изменений BC BCL - использование за пределами любовного интереса

  

Это часть ряда вопросов, которые фокусируются на проекте абстракции, целью которого является абстрагирование понятий, используемых при разработке языка, в форме структуры. Существует дочерний проект Abstraction под названием OILexer, целью которого является создание парсера из файлов грамматики без использования инъекций кода в матчах.

     

Некоторые другие страницы, связанные с этими вопросами, связанные со структурной типизацией, можно просмотреть здесь и простота использования, найдены здесь , вопрос о написании компилятора компилятора можно найти . Мета-тема, связанная с запросом о структуре и надлежащем месте для публикации, может быть найдена . суб>

     

Одним из шагов в этом процессе было создание моего собственного анализатора метаданных ECMA-335. Поскольку я стараюсь создавать инструменты для создания инструментов, я недавно решил сделать аналитический сверху вниз в библиотеках базового класса .NET. Будущая цель будет использовать его для создания библиотек, которые представляют BCL, чтобы помочь в быстром генерации кода (подробнее об этом позже, если кто-то заботится.)

Я хотел получить общее представление об общих версиях библиотек в .NET BCL, поэтому я проанализировал папку Framework, хранящуюся локально. Выполнение этой версии для каждого фреймворка должно отражать систему конечного пользователя: прямо сейчас я нацелен на себя.

Первым шагом в этой цели является создание класса, который концептуализирует библиотеку с несколькими версиями и тянет каждую итерацию по мере необходимости. Следующим шагом является выбор всех типов из каждой версии и сравнение отдельных списков типов (как правило, больше работы, чем должно быть.)

Результатом является довольно прямое представление BCL , которое ломается вниз, версия библиотеки была представлена ​​и отображает, какие версии новых типов были введены, сгруппированы по пространству имен.

Этот должен быть исчерпывающим списком, который исключает типы, которые были введены с самой библиотекой. Вы можете предположить, что если он не указан, он был там с самого начала библиотеки. Вид очень прост: +Type означает, что он был добавлен, -Type означает, что он был удален Type->Assembly означает, что он был перемещен в этой версии.

Целевая сторона этого: если она точна, она дает вам базовое разбиение того, когда вводился тип, полезный для определения самой низкой версии .NET, необходимой для данной части функциональности. Следующим шагом будет анализ членов, который сделает первый шаг простым (в основном из-за сопоставления сигнатур метода, поскольку каждый тип параметра должен быть возвращен и просмотрен.)

Мне любопытно, может ли этот анализ впоследствии использоваться для автоматизированного инструмента, который мог бы определить самую низкую общую версию фреймворка для сборки в целом (программное обеспечение написано каркасом компилятора, которое я пишу, то есть)?

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

  

PS: Кому интересно, почему я не использую Reflection, попробуйте использовать    Type.GetType (строка) для любого из них:

Microsoft.Win32.Registry, mscorlib, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
Microsoft.Win32.Registry, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
Microsoft.Win32.Registry, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 
     

Это не подведет, но вы также не получите то, что ожидаете, даже пытаясь загрузить 2.0   mscorlib по имени файла дает сборку 4.0.

Изменить . Я должен добавить, что этот анализ исключительно фокусируется на публично открытых элементах. Обоснованием этого является то, что вы никогда не должны сосредотачиваться на зависимостях внутренней структуры BCL, так как это может измениться без предупреждения. Если вы пишете генератор кода и выражения, которые вы синтезируете, полагайтесь на эти типы, ваша система, скорее всего, будет хрупкой, как стекло, если что-то изменится в рамках, например, патч, обновляющий внутреннюю структуру версии 2.0. Из-за того, как .NET связывает своих членов в Common Intermediate Language, это очень реальная вероятность.

7 голосов | спросил Alexander Morou 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 25 Sep 2013 13:34:39 +0400 2013, 13:34:39

1 ответ


0

Из того, что я могу сказать, этот анализ можно использовать, чтобы определить, имеет ли целевая инфраструктура функциональность, представленная на данной сборке. Если, например, вы указываете версию 2 структуры, но полагаетесь на функциональность версии 4, может быть создан подробный список того, что недействительно. LINQ - яркий пример этого, поскольку он был введен в версию 3.5 структуры. Я, вероятно, буду включать архитектуру процессора /платформу для идентификаторов сборки, чтобы я мог сравнивать разные версии платформы BC BCL с основным BCL. Индивидуальные изменения перечислены онлайн, но получение полного списка кажется сложным.

Это можно сделать аналогично анализу активной промежуточной сборки по сравнению с предыдущей сборкой, чтобы потенциально обнаружить изменения прерывания (такие как добавление методов к интерфейсу).

Также может использоваться для автоматизации журналов изменений и создания итеративного представления библиотеки для инструментов анализа, чтобы скомпилировать.

Я упоминаю LINQ как элемент структуры, потому что на уровне компилятора он может быть поддержан уже в версии 2.0 фреймворка, если шаблоны методов присутствуют в соответствующих типах. Даже такие вещи, как async, доступны уже в начале этого периода, пока у компилятора есть средство для выражения этой функции, если пользователь предоставил Task <T> что соответствует требованиям шаблона, вы должны быть в порядке.

ответил Alexander Morou 3 +04002013-10-03T10:59:22+04:00312013bEurope/MoscowThu, 03 Oct 2013 10:59:22 +0400 2013, 10:59:22

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132