Schrodingers_Cat28 окт 2015 в 13:17

Сравни меня полностью. Рефлексия на службе .NET разработчика

23 мин

34K

.NET * C# *

Из песочницы

+27

Комментарии 20

shai_hulud 28 окт 2015 в 14:27

Неплохо. Но гораздо удобнее генерировать динамический код через System.Linq.Expressions, в 4.5 помимо функциональщины добавили еще немного императивщины.

Schrodingers_Cat 28 окт 2015 в 15:09

Абсолютно согласен. Конечно у Reflection.Emit больше возможностей, но гораздо проще ошибиться и словить VerificationException. Пожалуй, что на досуге я добавлю ещё одну реализацию, использующую деревья выражений. Хотя опуститься на уровень IL было интересно, много нового для себя открыл.

Scratch 28 окт 2015 в 17:24

А можно таким макаром заменить в рантайме метод из какого-либо класса? Например, метод, который что-то проверяет и возвращает True, а мы раз и делаем False

forcewake 28 окт 2015 в 20:08

Можно. Гуглить по .NET CLR Injection, например вменяемая статья с примерами кода codeproject
Хотелось бы предупредить, что, если целитесь на подмену метода, проверяющего наличие лицензии, реализованного, скажем, с помощью LicFileLicenseProvider, то может не сработать.

Schrodingers_Cat 28 окт 2015 в 20:34

Такая задачка будет посложнее. Нужно знать структуру внутренних объектов CLR. Один из подходов к перехвату .NET'овских методов, про который я читал ещё давно вот тут состоит в том, чтобы подменять адрес JIT'овской заглушки целевого метода на метод-перехватчик. Но работать это будет только если хук поставить до JIT-компиляции. Со сборками, по которым прошлись NGEN'ом поэтому такой трюк не прокатит. Статья эта 2009 года, с тех пор многие структуры могли измениться. Другой подход, описанный тут, основан на использовании CLR Profiler API. Эта апишка используется и в Visual Studio для реализации edit-and-continue, то есть для применения правок к коду прямо во время отладки. И ещё есть готовый продукт — библиотека CodeCop, которая позволяет перехватывать метод до его выполнения, после его выполнения, или вообще целиком подменить метод. Бесплатная версия позволяет установить максимум 25 хуков, а за полный функционал разработчики просят денежку. Как реализован CodeCop ничего не могу сказать — репозиторий на BitBucket естественно закрытый. Но предполагаю, что они используют именно CLR Profiler API, потому что с RyeJit они пока не умеют дружить, как говорится здесь, а в блоге команды .NET как раз было упоминание, что при включении нового JIT'а функция Edit & Continue перестаёт работать.

Dywar 29 окт 2015 в 06:32

Еще добавлю Graywolf, парень выступал на нескольких конференциях с этим.

shai_hulud 29 окт 2015 в 09:55

Советую для этих целей easyhook.github.io
Очень удобное API и возможно хукать всё что движется.

mird 29 окт 2015 в 06:03

Скажите, а что за прикладная задача требует подобного сравнения объектов?

Schrodingers_Cat 29 окт 2015 в 07:27

Объекты из моей задачи представляют собой параметры запуска различных измерительных тестов. Поведения у таких объектов нет никакого, они являются просто-напросто контейнерами свойств. Для каждого теста известны типовые (дефолтные) параметры запуска. Так вот в UI требуется по-разному отображать тесты с дефолтными и недефолтными параметрами.

mird 29 окт 2015 в 09:38

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

Schrodingers_Cat 29 окт 2015 в 10:14

Проще-проще, Вы правы. Но к сожалению, добавить такое свойство не представлялось возможным (организационно). Если бы можно было изменить все эти классы, то я бы реализовал для них всех интерфейс IEquatable<T>. Как я написал в статье, это как раз пример accidental complexity.

mird 29 окт 2015 в 06:09

И еще. Вы сравниваете два ссылочных типа по свойствам. А вас не смущает, что для них может быть специальным образом переопределен метод equals, который определяет, что два объекта равны, если у них равны не все свойства, а только часть? В результате ваш метод вернет что объекты не равны, а они вообще-то равны.

Schrodingers_Cat 29 окт 2015 в 08:00

В моей задаче было достаточно именно такого сравнения, поскольку сравниваемые объекты, как я ответил выше, моделируют параметры запуска тестов и являются контейнерами свойств без всякого поведения. Но Ваше замечание справедливо и в реализации ещё много чего можно улучшить. Помимо вызова переопределённого метода Equals, было бы неплохо настраивать способ сравнения строк (StringComparison) и макс. допустимое для сравнения double/float. Плюс коллекции, которые реализуют IList<T> (или IReadOnlyList<T>), возможно, что было бы более эффективно сравнивать не с помощью Enumerable.SequenceEqual, а циклом for. Кроме того в текущей реализации DynamicCodeComparer не учитывается, что структуры тоже могут быть коллекциями, а, например, в Roslyn такое сплошь и рядом, взять хотя бы SeparatedSyntaxList<TNode>. А ещё мне самому не очень нравится название класса DynamicCodeComparer. Задачу необходимо было решить в сжатые сроки, поэтому действительно не всё ещё доведено до ума.