Какие инструменты выполняют посткомпиляционную модификацию IL?

Question

Недавнее упоминание PostSharp напомнило мне об этом:

В прошлом году, когда я работал, мы думали использовать PostSharp для ввода инструментов в наш код. Это было в среде Team Team Server Build/Continuous Integration.

Думая об этом, я почувствовал, как работает PostSharp - он редактирует IL, который генерируется компиляторами. Меня это немного беспокоило.

Я не был так обеспокоен, что PostSharp не выполнил свою работу правильно; Меня волновало то, что я впервые услышал о таком инструменте. Я был обеспокоен тем, что другие инструменты могут не учитывать это.

Действительно, поскольку мы продвигались вперед, у нас возникли некоторые проблемы, связанные с тем, что PostSharp путался о том, в какой папке находился оригинальный ИЛ. Это нарушало наши сборки. По-видимому, это связано с конфликтом с целью MSBUILD, которая решает ссылки на проекты. Конфликт, по-видимому, связан с тем, что PostSharp использует временную директорию для хранения немодифицированных версий IL.

Во всяком случае, у меня не было StackOverflow, чтобы ссылаться на него тогда! Теперь, когда я это сделаю, я хотел бы спросить вас всех, если вы знаете какие-либо другие инструменты, которые редактируют IL как часть процесса сборки; или принимает ли Microsoft что-то инструмент во внимание в Visual Studio, MSBUILD, Team Build и т.д.

---

Update: Спасибо за ответы.

Суть в том, что, по крайней мере, с VS 2010, Microsoft действительно должен знать, что такого рода вещи могут случиться. Поэтому, если в этой области есть проблемы в VS2010, Microsoft может поделиться виной.

Answer 1

Я знаю, что Dotfuscator, программный obfuscator, модифицирует сборки сборщиков IL и используется во многих процессах сборки.

Ил модифицируется не только для запутывания кода и защиты, но и придать дополнительную функциональность в приложениях (см наши) сообщения в блоге (Preemptive на время выполнения разведки here.

Кроме Common Compiler Инфраструктура Microsoft имеет возможность читать в сборках, изменять их и переписать их. См CodePlex для проекта.

Answer 2

Я знаю о Mono.Cecil, библиотеке каркаса, расширяющей набор инструментов System.Reflection, который используется проектом LinFu.

Я не уверен в поддержке процесса сборки, вы должны проверить их на размер.

Answer 3

.NET 4.0 включает в себя проект code contracts от Microsoft Research, который выполняет требования времени выполнения (и некоторые параметры времени компиляции) в условиях до/после ваших методов. Утверждения реализованы в библиотеке, а компилятор .NET испускает условия pre/post как вызовы методов в IL. Однако, поскольку контракты, как правило, указываются в начале метода, второстепенному инструменту необходимо переписать IL, чтобы утверждать правильные порядки и правильные местоположения.

EDIT:

• cccheck является инструментом, который работает после сборки и является статической проверки, которая проверяет контракты на время компиляции
• ccrewrite является инструментом, который работает после cccheck , переписывая ИЛ и генерируя проверку времени выполнения из контрактов

(Я не могу найти никаких дополнительных техническая информация об этих инструментах)

Я еще не использовал Visual Studio 2010, но я видел демонстрацию функции Code Contracts и интегрирован в процесс сборки IDE. cccheck должен всегда запускаться, возвращая код, если контракты присутствуют в встроенной сборке. Если они присутствуют, код будет означать, что ccrewrite должен работать.

Answer 4

Fody является расширяемым инструментом для плетения сборок .NET на основе архитектуры плагина.