Введение
В данной статье я расскажу про то, как можно добавлять свой код в существующие .NET сборки и о том, как это связано с аспектно-ориентированным программированием. Статья будет сопровождаться работающими примерами, так как я считаю, что код — это лучший способ донести идею.
Многие .NET разработчики знают, что для доступа к объектам чужой сборки можно использовать Reflection. С помощью типов из System.Reflection мы можем получить доступ ко многим объектам .NET сборки, просмотреть их метаданные, и даже использовать те объекты, доступ к которым ограничен (например, private методы чужого класса). Но использование Reflection имеет свои ограничения и главная причина этому — данные, с котороми вы работаете через Reflection, все еще считаются кодом. Таким образом, вы, к примеру, можете получить CodeAccessSecurity exception, если сборка, к которой вы пытаетесь применить Reflection, запрещает это. По этой же причине Reflection работает довольно медленно. Но наиболее важным для данной статьи является то, что стандартный Reflection не позволяет изменять существующие сборки, только генерировать и сохранять новые.
Mono.Cecil
Качественно иной подход предлагает бесплатная библиотека с открытым исходным кодом Mono.Cecil. Главное отличие подхода Mono.Cecil от подхода Reflection в том, что данная библиотка работает с NET сборкой как с потоком байт. При загрузке сборки, Mono.Cecil разбирает PE заголовок, CLR заголовок, MSIL код классов и методов и т.д. работая напрямую с потоком байтов, представляющим сборку. Таким образом, с помощью данной библиотеки можно как угодно (в пределах предусмотренного) изменять имеющуюся сборку.
В этой заметке расскажу о своем опыте юнит-тестирования JS-кода, опыте использования среды выполнения тестов js-test-driver, ее возможности code coverage и скручивании ежа с ужом, а именно данных о code coverage от js-test-driver и генератора отчетов о покрытии PHP_CodeCоverage. Расскажу и покажу как получить 
