Моно Cecil по сравнению с Ядром PostSharp по сравнению с Microsoft CCI для реализации платформы AOP
from sys import version_info, api_version, version, hexversion
print(f"sys.version: {version}")
print(f"sys.api_version: {api_version}")
print(f"sys.version_info: {version_info}")
print(f"sys.hexversion: {hexversion}")
производит
sys.version: 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC v.1900 64 bit (AMD64)] sys.api_version: 1013 sys.version_info: sys.version_info(major=3, minor=6, micro=5, releaselevel='final', serial=0) sys.hexversion: 50726384
3 ответа
Microsoft.CCI и Mono.Cecil являются низкоуровневыми и не проверяют созданные сборки. Если есть ошибка в сгенерированном коде или структуре сборки, требуется много времени, чтобы найти причину проблемы.
Я бы рекомендовал использовать PostSharp, если его возможностей достаточно для ваших задач.
В противном случае ... Mono.Cecil имеет лучшую, более понятную и удобную в использовании объектную модель. Однако у меня возникла некрасивая ошибка, когда я использовал ее в своей программе (ссылка на неправильный метод была сохранена в сборке; я думаю, что была некоторая ошибка с обработкой токенов метаданных)
Microsoft.CCI имеет уродливую, чрезмерно продуманную объектную модель, в которой отсутствуют многие простые функции; однако он более зрелый, чем Mono.Cecil. Наконец, я отказался от Mono.Cecil и использовал Microsoft.CCI в своей программе.
Как и в случае с большинством фреймворков, которые уже существуют, я бы посоветовал вам относительно реализации вашего собственного фреймворка АОП: Не делайте этого . Уже есть несколько, в том числе (скоро) коммерчески поддерживаемый PostSharp и CThru , фреймворк АОП на основе Typemock .
Но в любом случае я нашел Mono .Cecil очень прост в использовании. Он абстрагируется от необходимости иметь дело с Reflection.Emit и пользуется поддержкой сообщества Mono.
Я предлагаю вам взглянуть на LinFu - это открытый - исходный набор библиотек, одна из которых представляет собой структуру АОП, реализованную поверх Mono.Cecil. На CodeProject есть хорошая статья о LinFu AOP .
AFAIK, LinFu построен на Mono.Cecil.
Я бы сказал, что PostSharp.Core имеет более высокоуровневые функции, чем другие фреймворки, поэтому его менее сложно использовать для больших работ. Вы также можете работать на низком уровне, но не на двоичном уровне (по замыслу). Вы можете выполнить слияние / сжатие сборок с помощью PostSharp, но тот факт, что он компилируется с использованием ILASM, установит некоторые ограничения (например, даже внутренние члены должны быть названы). С другой стороны, наличие ILASM в качестве бэкэнда значительно упрощает разработку поверх PostSharp, поскольку ILASM проверяет многие правила, и вы можете легко прочитать созданный код MSIL. PostSharp даже позволяет вам помещать комментарии в MSIL, чтобы помочь отладить генерацию кода.
Еще один момент: если вы хотите сделать настраиваемый аспект (например, вы разрабатываете механизм базы данных и хотите обеспечить аспект устойчивости), вам нужно гораздо больше, чем просто перезаписчик MSIL. Вам нужна инфраструктура AO, которая сделает большую часть работы за вас. Когда вы разрабатываете индивидуальный аспект, я бы сказал, что 1% работы относится к вашему индивидуальному аспекту, 39% - это инфраструктура аспектов, а 60% - это материал для перезаписи MSIL. Я часто могу запрограммировать очень конкретный аспект за пару часов на основе PostSharp.
Итак, возвращаясь к вашему вопросу, и, конечно же, с моими собственными биографиями, я бы сказал: если вы хотите написать обфускатор, слияние / shrinker и т. д., лучше выбрать Mono.Cecil или Microsoft.CCI по той единственной причине, что их лицензия более удобна, чем у PostSharp. Но если вы просто хотите разработать индивидуальный аспект, с помощью PostSharp вы сэкономите недель ,