Как узнать, есть ли у метода какой-либо код (тело)?

Нужно выяснить, делает ли реализация метода хоть что-нибудь.
Что смог придумать:

typeof(AnyType).GetMethod("MethodName").GetMethodBody().GetILAsByteArray().Length

если тела нет - возвращает 2

+

Опишу и общую задачу, на всякий. Метод реализован всегда, этого требует absctract в базовом классе. Однако, он может ничего не делать, если это не нужно в конкретном подклассе. В другом месте есть контрольная точка: если метод ничего не делает, то один из параметров может быть пустым, если делает - генерируется ошибка, значит программер накосячил. То есть проверку можно в принципе сделать только в DEBUG-варианте и не вызывать в релизе. В принципе, понимаю, что задачу можно реализовать иначе - заставить метод что-то возвращать, перевести его на virtual вместо abstract, но хотелось бы в таком варианте.

Shocker.Pro
но хотелось бы в таком варианте.

идея - нездоровая

Shocker.Pro
В другом месте есть контрольная точка: если метод ничего не делает, то один из параметров может быть пустым

это забота вызываемого, а не вызывающего

Shocker.Pro
В другом месте есть контрольная точка: если метод ничего не делает, то один из параметров может быть пустым, если делает - генерируется ошибка, значит программер накосячил. То есть проверку можно в принципе сделать только в DEBUG-варианте и не вызывать в релизе

Вижу как минимум, 2 варианта - "навскидку" и "в-лоб".
Раз:

#if DEBUG
   // bla-bla-bla
#endif

Два:

[Conditional("CONDITION1")]
public static void Method1(int x)
{
    // bla-bla-bla
}

Shocker.Pro

Нужно выяснить, делает ли реализация метода хоть что-нибудь. Что смог придумать: typeof(AnyType).GetMethod("MethodName").GetMethodBody().GetILAsByteArray().Length если тела нет - возвращает 2 + Опишу и общую задачу, на всякий. Метод реализован всегда, этого требует absctract в базовом классе. Однако, он может ничего не делать, если это не нужно в конкретном подклассе. В другом месте есть контрольная точка: если метод ничего не делает, то один из параметров может быть пустым, если делает - генерируется ошибка, значит программер накосячил. То есть проверку можно в принципе сделать только в DEBUG-варианте и не вызывать в релизе. В принципе, понимаю, что задачу можно реализовать иначе - заставить метод что-то возвращать, перевести его на virtual вместо abstract, но хотелось бы в таком варианте.

Я вам настоятельно рекомендую исправить архитектуру в этой части. Что-то здесь неправильно.
Представте, что после вас придет другой разработчик, которому придется курить вашу рефлексию и понять зачем она здесь.
Намного проще все и правильнее все это исправить архитектурой. Resharper в помощь, чтобы не делать много рутинной работы если у вас много наследников от абстрактного класса.

LameUser
Представте, что после вас придет другой разработчик, которому придется курить вашу рефлексию и понять зачем она здесь.

естественно, это единственная строчка тщательно прокомментирована.

Кстати, немножко неправильно описал - реализовать метод обязывает интерфейс. Но реализация может быть пустой.

Изопропил
это забота вызываемого, а не вызывающего

Ну так о вызываемом и речь. Некто создает экземпляр подкласса и инициализирует его поля. Есть поле, условно говоря "текст сообщения об ошибке".
У подкласса есть метод "проверить на ошибку". Он вызывается "где-то потом", если чо - выведет пользователю указанное сообщение.

Так вот, если метод "проверить на ошибку" реально ничего не проверяет, то допустимо не задавать текст сообщения об ошибке, он все равно не понадобится. Но есть тело есть - сообщение обязано быть. Ловить косяк в момент срабатывания метода нелогично, ситуация может возникать раз в сто лет, а отловить неверную инициализацию подкласса можно довольно просто средствами базового класса и отлов произойдет сразу на этапе разработки при первом же запуске.

Поэтому я сделал такой "самоконтроль для программиста".

Shocker.Pro
Поэтому я сделал такой "самоконтроль для программиста".

этот самоконтоль лучше вычистить.

Осетрина второй свежести не бывает.
Если требуется текст сообщения - значит требуется. Точка

Shocker.Pro,
В принципе пойдет для тур дефранс, только проверить надо и для релиза, может быть и не два, (оптимизация компилятора)

Изопропил
Если требуется текст сообщения - значит требуется. Точка

Зачем писать текст, который заведомо не будет использоваться?
Ну хорошо, запретить пустую строку для сообщения. Программист будет писать "x$%", чтобы обойти ограничение пустой строки, так как он знает, что это сообщение никогда не появится.

Так вот важно, чтобы он не написал "x$%" (или пустую строку, что в данном случае проще) так, чтобы это увидел пользователь из-за ошибки программиста.

Это, в общем, такой, немного специфический контракт кода получается.

Где-то в степи
только проверить надо и для релиза

в релизе этой проверки не будет