Некоторые вполне могут вводить недопустимый IL, который CLR может запустить, но ILDASM и т. Д. Не обрабатывают. На мой взгляд, это плохая вещь - CLR вполне может жаловаться на это в будущем.
Другие могут хорошо создать действительный IL, который может вызвать срабатывание ILDASM и Reflector из-за непредвиденной ситуации. В качестве глупого примера предположим, что идентификатор содержит непечатаемый символ. Из того, что я помню, это действительно, поскольку CLR рассматривает идентификаторы как непрозрачные BLOB-объекты, но что-то, пытающееся отобразить их, вполне может потерпеть неудачу. Скорее всего, это будет только временная помощь - хотя ILDASM обновляется не так часто, Reflector часто обновляется, и я ожидаю, что разработчики исправят подобные проблемы, когда узнают о них.
Третья альтернатива, которая помогает против высокого уровня декомпиляции, но не дизассемблирования, заключается в создании IL, который не имеет очевидного аналога в C # / VB, но который является совершенно допустимым. Фактически, блоки итераторов иногда уже делают это (смотрите в конце статьи).
Я ожидаю, что все, что является законным и гарантированно работоспособным, будет демонтировано (сейчас) или, по крайней мере, в будущем. Crashing Reflector сейчас (точнее, когда была написана реклама) не является хорошим показателем будущего сбоя.