Инструменты – средство усиления вашего таланта. Чем они лучше и чем лучше вы ими владеете, тем больше вы сможете сделать.
Энди Хант и Дейв Томас «Программист-прагматик. Путь от подмастерья к мастеру»

DISCLAIMER: это не заказная и совершенно не проплаченная статья (JetBrains, я ни на что не намекаюJ). Здесь представлены лишь возможности популярного расширения для VisualStudio (а иногда и аналогичные возможности самой студии), которые я лично использую в повседневной деятельности.

Введение

В данной статье я расскажу про то, как можно добавлять свой код в существующие .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 код классов и методов и т.д. работая напрямую с потоком байтов, представляющим сборку. Таким образом, с помощью данной библиотеки можно как угодно (в пределах предусмотренного) изменять имеющуюся сборку.

Начиналось все как и в прошлый раз, достаточно прозаично: мне пришлось разработать *-надцать ViewModel-ей для своего MVVM-приложения.
Для того, чтобы они оптимально работали как ViewModel-и, мои классы должны были наследоваться от DependencyObject или же реализовывать заезженный до дыр интерфейс INotifyPropertyChanged (INPC).

Давно уже ни для кого не секрет, что DependencyProperty тормознее ручной реализации INPC. Мои тесты показывают, что запись в DependencyProperty в ~13 раз медленнее ручной реализации. Поэтому я, как неисправимый оптимизатор, склоняюсь именно к INPC. Тем более, что код поддержки INPC выглядит логичнее и органичнее, чем описание DependencyProperties.