«Ошибка применения модуля»: расширение подключено, а перехватчик не работает

01.09.2026 на пять строк кода ушло полдня.

Задача была скучная: в УТ 11.5 подменить результат одной экспортной функции общего модуля. Расширение, заимствованный модуль, &После, дописать свое в результат. Написал, загрузил из файлов, обновил конфигурацию базы данных. Конфигуратор не сказал ни слова. Открыл Предприятие — функция возвращает старое значение.

Сначала минут тридцать ушло на поиск опечатки в имени метода внутри аннотации: скопировал имя из дерева метаданных, сверил побуквенно, поменял регистр, перезагрузил расширение еще раз. Потом заподозрил кэш и перезапустил сеанс. Потом — что расширение вообще не встало, и полез в список расширений: стоит, галка «Активно» на месте. И только когда вписал первой строкой перехватчика заведомое исключение и оно не выбросилось, стало понятно: код не просто не влияет на результат. Он не выполняется вообще. Привязки нет.

Расширение загрузилось, код возврата 0, в списке расширений полный порядок, а поведения нет. Таких случаев в статье семь: пять пришли из боевых проектов за сентябрь, два нашлись уже на полигоне. Сначала писал про молчаливую платформу.

Пока не полез в журнал регистрации.

Платформа не молчит. Шесть случаев из семи она проговаривает по-русски и с причиной, просто пишет их туда, куда мы не смотрим, и с уровнем, по которому мы не фильтруем. Седьмой в журнал не попадает вовсе, и там она права: ломаться нечему.

Полигон

Все, что дальше, проверено заново 24.09.2026. В нескольких местах память меня подвела, каждое отмечу по ходу. Чтобы не гадать на типовой, где обычно находится третий фактор, завел под опыты отдельную пустую конфигурацию в своей старой файловой базе: одна константа-протокол и один общий модуль Ядро с методами-мишенями. Функции Ф1…Ф9 возвращают 1 и отмечаются в протоколе, процедуры П1…П3 просто отмечаются. Расширение заимствует Ядро и вешает на мишени разные аннотации. Дергаем все двенадцать мишеней внешним соединением и смотрим, что вернулось и что попало в протокол.

Дешево и сердито, но зато почти нет лишних движущихся элементов: та же база, тот же сеанс, меняется ровно одна вещь за раз. Почти — потому что база старая, и в ней, как выяснится под конец, уже лежало чужое сломанное расширение, о котором никто не знал. Если у вас такой заготовки нет, заведите: она окупается с первого же спора «у меня работает, а у тебя нет».

Расширений на полигоне пять, а не одно, и зовутся они Проба, Проба2…Проба5. Так пришлось сделать: один из вариантов объявления перехватчика вообще не компилируется и уносит с собой весь модуль своего расширения, поэтому держать его рядом с остальными пробами нельзя. У каждого замера ниже называю расширение, иначе будет путаница.

Если некогда читать

Зовите оба метода РасширенияКонфигурации: ПроверитьВозможностьПримененияВсех() и ПолучитьИнформациюОПроблемахПримененияВСеансе(). Пусто — проверьте, вернул ли перехватчик подмененное.

Когда виновата аннотация

Тот самый сентябрьский случай в чистом виде. Расширение Проба, один модуль, один сеанс, шесть перехватчиков:

Четыре верхние строки работают. Две нижние (&После и &Перед на функции) не делают ничего, при том что сидят в том же модуле того же расширения и дергаются в том же сеансе. Это и есть контрольный замер на «а не сломан ли у тебя стенд»: если бы дело было в сборке расширения, в uuid, в порядке загрузки или в кэше, легли бы все шесть строк, а не две из шести.

Ни одна загрузка при этом не выдала ошибки. Конфигуратор берет расширение из файлов, обновляет базу и не говорит ни слова. В пакетном режиме то же самое: /LoadConfigFromFiles и /UpdateDBCfg с ключом -Extension возвращают код 0 и пустой /Out. То есть привычная связка, которой мы выкатываем расширения, проходит целиком и молча — хоть руками, хоть из конвейера.

«На функции &После не работает» — утверждение отрицательное, а отрицания прогоном не доказываются: чтобы доказать, надо перебрать все способы, а чтобы опровергнуть, читателю хватит одного. Поэтому формулировка такая: я не нашел способа заставить &Перед или &После отработать на функции общего модуля. Пробовал четыре объявления перехватчика:

1. &После, перехватчик-процедура с параметром результата — Процедура Пр_Ф1(Результат);
2. &После, перехватчик-процедура без параметров — Процедура Пр2_Ф2();
3. &После, перехватчик-функция — Функция Пр2_Ф3();
4. &Перед, перехватчик-процедура — Процедура Пр_Ф4().

Плюс каждое из них грузил и Конфигуратором, и ibcmd. Первый и четвертый видны в таблице выше, третий разбирается ниже отдельно, а второй снимался своим заходом на мишени Ф2: вернулась 1, в протоколе только Ф2база, а в журнале та же формулировка, что и у первого, только с другим именем метода. Знаете пятый вариант?

Что при этом говорит сама фирма 1С. В блоге «Зазеркалье», в записи «Расширение модулей», формулировка прямая: если вы перехватываете типовую функцию, а не процедуру, вам доступен только перехватчик &Вместо. Это ограничение 1С задокументировала, просто в тот вечер оно мне на глаза не попалось.

Почему так решили в 1С, не знаю. Напрашивается объяснение «в &После неоткуда взять результат оригинала», но оно неполное: вариант 1 из списка выше как раз принимает результат параметром, и платформа его тоже не берет. Так что это моя догадка.

Лечится это двумя способами, и оба прогнаны 24.09.2026. Первый — &Вместо плюс ПродолжитьВызов(), честная обертка «до и после»:

&Вместо("Ф8")
Функция Пр5_Ф8()
	Ядро.Записать("Ф8до");
	Результат = ПродолжитьВызов();
	Ядро.Записать("Ф8после");
	Возврат Результат + 100;
КонецФункции

Протокол после вызова: Ф8до;Ф8база;Ф8после, вернулось 101 при оригинальном значении 1. Оригинал выполнился внутри вашего кода, результат у вас в руках, дописать к нему свое — одна строка. Способ прогнан целиком и воспроизводится с первого раза.

Второй способ — аннотация &ИзменениеИКонтроль. Про нее пишут, что на функциях ограничений нет (например, разбор на tnsoft.ru про использование аннотации на примерах), и это подтвердилось: берем тело оригинала целиком, вставляем свое между #Вставка и #КонецВставки, а платформа контролирует, что остальной текст не разошелся с типовым. Протокол после вызова: Ф9база;Ф9вставка. Работает.

Но у этой сверки есть обратная сторона, и она нашлась в первом же заходе: по привычке написал внутри перехватчика свое тело, а не копию типового. Загрузилось с кодом 0 и не применилось. В журнале потом нашлась строчка: Текст модуля для метода "Ф9" изменился. Так что &ИзменениеИКонтроль замолчит на том обновлении, которое тронет тело этого метода. Иногда именно это и нужно: пусть лучше сломается громко, чем тихо отработает на изменившейся логике. А иногда это мина на следующий релиз. Самого эффекта от обновления типовой на стенде не увидеть: полигон пустой, обновлять там нечего. Так что это рассуждение по механике, а не замер.

Третий вариант из списка, &После на функции с перехватчиком-функцией, ломается не так, как остальные: он забирает с собой весь модуль расширения.

Опыт 24.09.2026. Ради него Проба2 пересобиралась дважды, и перехватчик на Ф2 в ней на это время стал &Вместо — чтобы было чему ломаться. В первом заходе в модуле лежит только он: мишень возвращает 22, в протоколе Ф2расш, все хорошо. Во втором к нему дописаны пять строк на совсем другую мишень, тот самый &После("Ф3") с перехватчиком-функцией. Больше не поменялось ничего. И Ф2 начинает возвращать 1, а в протоколе снова Ф2база. Исправный, отработавший минуту назад перехватчик перестал работать, потому что рядом в модуле появился неверный. Текст ошибки нашелся потом в журнале:

Ошибка инициализации модуля: Проба2 ОбщийМодуль.Ядро.Модуль
по причине:
{Проба2 ОбщийМодуль.Ядро.Модуль(6,2)}: Неправильное использование аннотации (После):
Аннотацию "После" нельзя применять к функциям
&<<?>>После("Ф3")
[ОшибкаКомпиляцииВстроенногоЯзыка]

Две разные аварии, и путать их дорого:

• не встала одна привязка — остальное расширение живет. Случай коварный именно этим: половина продукта работает, половина нет, и по поведению это неотличимо от логической ошибки в вашем коде.
• модуль расширения не скомпилировался — не работает ничего из этого модуля. При этом Предприятие открывается как ни в чем не бывало, и в Конфигураторе тоже тишина.

/CheckConfig -Extension Проба2 -ExtendedModulesCheck на расширении с настоящей ошибкой компиляции отвечает Ошибок не обнаружено и кодом 0. Прогнал заодно на всех пяти пробах — везде одинаково.

Флажок, который выключает перехватчики, но не расширение

Этот случай стоил дороже всех остальных вместе взятых, и выбираться из него пришлось дважды: в первый раз я так и не понял, из чего выбрался.

Расширение — «Главное место бухгалтера», моя разработка под Инфостарт. Оно вешает &После на общий модуль БСП ПодключаемыеКоманды и за счет этого встраивает свою колонку и свои команды во все формы списков документов сразу, не заимствуя ни одной формы. Собрал его на ERP УП2 2.5.27.70, дальше надо проверить переносимость на соседних конфигурациях. 04.09.2026 ставлю его на демобазы КА 2.5.22.166 и УНФ 3.0.13.292.

Ставится без единого возражения. Захожу в Предприятие: собственная обработка расширения открывается, общая команда в форме документа на месте, РасширенияКонфигурации.Получить() по COM отдает Активно = True, объекты расширения в Метаданные находятся поименно. Половина продукта работает честно и наблюдаемо. А &После на ПодключаемыеКоманды не отрабатывает ни разу.

Вечер ушел на три гипотезы подряд. Сначала на аннотацию: заменил &После на &Вместо с ПродолжитьВызов(), потому что про &Вместо уже точно знал, что она работает. Тишина. Потом на заимствование: пересобрал модуль с нуля, сверил ExtendedConfigurationObject с uuid типовой, перегенерировал свой uuid на случай коллизии. Тишина. Потом на сигнатуру: у ПриСозданииНаСервере в ПодключаемыеКоманды второй параметр со значением по умолчанию, решил, что платформа не сопоставляет методы из-за него, переписал объявление тремя способами. Опять ничего.

И все это время перехватчик был обернут в Попытка с ЗаписьЖурналаРегистрации в Исключение, а в журнале не появлялось ни одной записи. Вот это и сбило с толку окончательно: раз зонд не пишет даже из Исключение, значит метод не вызывается вовсе, значит дело в привязке, значит копать надо в XML. Так и копал, часа три, и злился на 1С за то, что она не умеет сказать «не сопоставил».

Оказалось, лежало оно все это время на виду. Нашлось случайно, при сверке свойств расширения через COM, в списке полей рядом с Активно: галка «Безопасный режим». Снял ее программно, БезопасныйРежим = Ложь плюс Записать(), без переустановки и без правки файла расширения. Перезашел в сеанс — заработало сразу, с первого вызова.

Отдельная обида в том, что этот же флажок укладывал уже один раз, за две недели до того. 23.08.2026, заводка YaXUnit на трех разных базах: он молча не стартовал, клиент запускался, открывал рабочий стол и висел до таймаута. Ни отчета, ни файла exitCode, ни записи в журнале. Диагноз тогда звучал как «параметр /C не доезжает до сеанса», и день ушел на командную строку. А дело было в том, что расширение, загруженное Конфигуратором, получило safe-mode: yes, и YaXUnit падал на чтении файла параметров запуска еще до того, как ему было чем отчитаться. Два разных продукта, два разных симптома, одна причина, и во второй раз я ее не узнал. Оговорюсь сразу: «ни записи в журнале» там тоже относится к моему зонду, а не к платформе. В журнал тогда не смотрел вовсе, так что почти наверняка запись была и там.

На стенде тот же эффект достается одним флагом. Берем расширение Проба, в котором работают все четыре исправных перехватчика, и трогаем этот флаг. С включенным безопасным режимом Ф5 возвращает 1, а в протоколе только Ф5база; П1, П2 и П3 тоже отмечаются в протоколе исключительно базовыми строками. Снимаем флаг, ничего больше не меняя: Ф5 возвращает 99 и пишет Ф5расш, П1 дает П1база;П1расш, П2 дает П2расш;П2база, П3 дает П3расш. Четыре из четырех мимо и четыре из четырех обратно, от одного флага.

Ни ошибки, ни предупреждения на экране, ни отказа при подключении. Замер тут только по общему модулю; про остальное есть документированная формулировка в «Зазеркалье»: в безопасном режиме расширяются только клиентские методы и серверные обработчики форм. Про то, что собственные объекты расширения при этом продолжают работать, знаю из истории с «Главным местом бухгалтера»: на полигоне этого не проверял.

Тогда записал себе в заметки «в журнале ни одной записи» и был уверен, что платформа промолчала. Скорее всего, она не молчала: на полигоне в этой же ситуации она кладет строку расширение модуля запрещено из-за того, что расширение подключено в безопасном режиме. На боевой базе не увидел ее по двум причинам сразу — искал записи от своего зонда, а не от платформы, и держал отбор по критичности «Ошибка», тогда как платформа пишет это «Предупреждением».

А вы смотрите на этот флажок, когда принимаете чужое расширение?

Я до того вечера — нет ))

Если катите расширения пакетно, попасться легко. При первой загрузке расширения на полигон через ibcmd платформа сама поставила ему safe-mode: yes, никто ее об этом не просил. Снимайте так:

ibcmd extension update --db-path="<путь к базе>" --name=Проба ^
    --safe-mode=no --unsafe-action-protection=no

Раньше считал, что флаг возвращается при каждой перезагрузке расширения и его надо снимать заново после каждой выкатки. На 8.5 это не подтвердилось. Снял флаг, потом еще четыре раза прогнал /LoadConfigFromFiles -Extension и /UpdateDBCfg -Extension — флаг остался снятым. Похоже, безопасный режим ставится при создании расширения в базе, а не при каждой загрузке. На более ранних версиях наблюдение было обратное, но там и путь загрузки был другой, так что настаивать не буду: проверьте одной командой ibcmd extension list, это быстрее, чем верить статье. Только из закрытого сеанса: при живом соединении ibcmd упирается в блокировку, про это ниже. И учтите, что про применимость расширения та же команда врет — до этого мы еще дойдем, а вот флаг безопасного режима она показывает честно.

Два раза, когда виноват состав расширения

Оба сюжета короткие, и оба про то, чего в коде не видно вовсе.

Первый — скопированный uuid. Проба4 собрана так, как расширения обычно и собирают руками: берешь соседнее, переименовываешь, правишь модуль. Вместе с файлом CommonModules/Ядро.xml переехал и атрибут uuid. Импорт 0, обновление 0, active: yes, мишень Ф7 возвращает оригинал. Платформа называет это Конфликт внутренних идентификаторов у объекта CommonModule.Ядро. Сгенерируйте новый uuid, и все пройдет; почему именно так устроено, не знаю. Проверил ровно одно: скопированный ломает, сгенерированный чинит.

Второй — заимствованный объект, которого в целевой конфигурации нет. В продукте это были элементы стиля, которые есть в ERP и КА, но отсутствуют в УТ. Правда, тогда ставил диагноз наугад, поэтому за причину той истории не поручусь, зато полигон воспроизвел механику начисто. Расширение Проба3: рабочий &Вместо на мишени Ф6 плюс заимствованный CommonModule.НетТакого с выдуманной ссылкой. Мишень возвращает оригинал. Убрал из состава только лишнее заимствование, модуль и перехватчик не трогал, перезагрузил — мишень возвращает подмененное значение. То есть отключается расширение целиком, а не один этот объект. Час на это ушел, и полчаса из него был уверен, что сломал перехватчик ))

Отсюда правило для универсального расширения, которое ставится на несколько конфигураций: заимствовать можно только то, что есть во всех целевых. Проверял это на одном отсутствующем общем модуле; другие типы объектов так не гонял, но подозреваю, что разницы нет.

Почему коллега клянется, что у него работает

Единственный случай в статье, где с расширением все в порядке, а поведения все равно нет.

Правим код расширения, загружаем в работающую файловую базу, обновляем конфигурацию базы данных. Монополия не нужна, сеанс не падает, обе команды дают код 0 и пустой /Out. Проверяем — старое поведение. Проверяет коллега со своего свежезапущенного сеанса — новое.

Замер простой. Мишень Ф5 в расширении Проба, перехватчик уже работает и возвращает подмененные 77. Правлю расширение на 99, гружу и обновляю базу при открытом сеансе. Тот же сеанс: 77. Новый сеанс: 99.

Так устроено: набор расширений и их версии фиксируются на момент старта сеанса. У платформы даже есть метод РасширенияКонфигурацииИзменены() ровно про это — он возвращает Истину, если у нового сеанса набор расширений будет другой. Но пока его никто не зовет, лекарство одно: сказать всему отделу посреди рабочего дня «выйдите и зайдите».

Мелочь, которая стоила отдельного получаса: на файловой базе Конфигуратор делает это без монополии, а ibcmd — нет. При живом внешнем соединении ibcmd infobase config import падает с «Ошибка исключительной блокировки информационной базы», и так же падает ibcmd extension list, то есть даже чтение списка расширений. Клиент-серверную не мерил. Если автоматизируете выкатку на ibcmd, готовьтесь выгонять пользователей там, где Конфигуратор бы прошел.

Платформа это проговаривает

Журнал полигона открыл ровно затем, чтобы написать «ни одной записи» уже не по памяти, а по свежим следам. Получилось наоборот, и мнение поменялось по ходу письма: за день опытов там лежат десятки записей события «Сеанс. Ошибка применения расширения конфигурации», и вот семь разных текстов оттуда:

Ошибка применения модуля "Проба ОбщийМодуль.Ядро.Модуль".
Метод "Пр_Ф1" является процедурой, а метод расширяемой конфигурации является функцией.

Ошибка применения модуля "Проба ОбщийМодуль.Ядро.Модуль".
Метод "Пр_Ф4" является процедурой, а метод расширяемой конфигурации является функцией.

Ошибка инициализации модуля: Проба2 ОбщийМодуль.Ядро.Модуль по причине:
Неправильное использование аннотации (После): Аннотацию "После" нельзя применять
к функциям [ОшибкаКомпиляцииВстроенногоЯзыка]

Ошибка расширения модуля 'ОбщийМодуль.Ядро.Модуль': расширение модуля запрещено
из-за того, что расширение 'Проба' подключено в безопасном режиме

Ошибка применения модуля "Проба5 ОбщийМодуль.Ядро.Модуль".
Текст модуля для метода "Ф9" изменился

Проба4 (1.0.0.1): Critical: Конфликт внутренних идентификаторов у объекта CommonModule.Ядро

Проба3 (1.0.0.1): Critical: Не найден объект CommonModule.НетТакого

Это шесть случаев из семи: две верхние записи про один и тот же, дальше по одной на каждый. Седьмого, про открытый сеанс, тут нет и быть не может — расширение там исправно. Платформа описала их точнее, чем это вышло у меня руками, и ровно в тот момент, когда стартовал сеанс. Имя расширения есть везде, имя модуля — в пяти записях из семи, имя метода — в четырех, считая несобравшийся модуль, где платформа называет и метод, и координаты строки. У безопасного режима, у конфликта uuid и у отсутствующего объекта метод назвать просто нечем: авария не про него.

Каналов, по которым платформа отчитывается, два. Первый — вот этот журнал, и две вещи в его записях сбивают с толку.

Первое. Уровень записи — «Предупреждение», а не «Ошибка», хотя две записи из семи несут внутри текста слово Critical: это Critical — часть комментария, который платформа положила в запись, а не уровень самой записи. Мы открываем журнал, ставим отбор по критичности «Ошибка», потому что иначе там не продохнуть. И проходим мимо единственной строки, которая объясняет нам весь день.

Второе. Имя события одно на все: «Сеанс. Ошибка применения расширения конфигурации» собирает и не вставшую одну привязку, и несобравшийся модуль, и полностью не применившееся расширение. Для отбора это удобно, для диагноза бесполезно: разбираться придется по тексту комментария.

Второй канал программный, и он удобнее: встраивается в проверку при выкатке и не требует от человека ничего:

Проблемы = РасширенияКонфигурации.ПроверитьВозможностьПримененияВсех();
Для Каждого Проблема Из Проблемы Цикл
	Сообщить(Проблема.Расширение.Имя + ": " + Проблема.Описание);
КонецЦикла;

Рядом живет РасширенияКонфигурации.ПолучитьИнформациюОПроблемахПримененияВСеансе() — он отвечает на другой вопрос: «а прямо сейчас, в этом самом сеансе, оно применилось?». Первый метод отвечает про базу, второй про сеанс, и это не одно и то же.

Списки не совпадают. В последнем прогоне первый метод выдал четыре сообщения: три про расширение Проба и одно про постороннее расширение в этой базе. Второй тоже четыре, но состав другой: две снова про Проба, а дальше конфликт uuid и несобравшийся модуль Проба2. Пересекаются частично, и ни один не назвал всего. Так что звать надо оба.

Третий метод — ПроверитьВозможностьПрименения() у самого объекта РасширениеКонфигурации. Он интересен тем, что умеет проверить не то, что уже лежит в базе, а новую версию расширения до загрузки: создаете объект расширения из двоичных данных файла и спрашиваете, встанет ли оно. Для конвейера сборки это ровно то, чего не хватает CheckConfig. В бою он пока не проверен, поэтому идет как направление, а не как рецепт.

Вот список того, что нас обмануло. Каждая строка прогнана 24.09.2026 на всех пяти пробах полигона — среди них расширение с несобравшимся модулем, расширение с конфликтом uuid и расширение с лишним заимствованием:

Последние две строки — самые издевательские. Единственная из восьми строк, где проверка вообще заметила неладное, сообщает об этом кодом возврата и не пишет в лог ни слова о том, что именно не так. А если позвать ее адресно, по имени расширения, она возвращает 0 на каждом из трех разных классов поломки, которые ей подсовывали.

И вот мой тезис, защищать его готов в комментариях: расширения не молчат — не слушаем мы. Претензии к платформе есть, и насчитал четыре: уровень записи, одно имя события на все аварии сразу, молчащий CheckConfig и CheckCanApplyConfigurationExtensions, который ругается кодом возврата и молчит в логе. Все остальное она говорит, причем заранее и по-русски. Виноват сложившийся у всех нас ритуал приемки: «обновилось без ошибок, в списке значится — значит поехали». Неважно, нажали вы это в Конфигураторе или прогнали пакетом. Этот ритуал не проверяет ровно то, ради чего расширение существует.

Минимальная замена ритуала. Шесть случаев битого расширения она закрывает, седьмой — про открытый сеанс — не закрывает никак, там расширение исправно, и ловить нечего:

1. После выкатки — ПроверитьВозможностьПримененияВсех() и ПолучитьИнформациюОПроблемахПримененияВСеансе(), результат в лог сборки. Не пусто — выкатка не удалась, чем бы ни закончились коды возврата.
2. Журнал регистрации с отбором по событию «Сеанс. Ошибка применения расширения конфигурации» и по уровню «Предупреждение» и выше.
3. Наблюдаемое следствие самого перехватчика. Не «объекты расширения на месте», а «метод вернул то, что мы подменили». Наличие объектов не доказывает ничего: на полигоне все пять расширений числились активными, при этом два не работали вовсе, а третье работало наполовину.

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

Что проверено, а что нет

Статья про доверие к проверкам, так что свои границы назову сам.

Прогнал 24.09.2026 на файловой базе, платформа 8.5, отдельная пустая конфигурация: все двенадцать мишеней, каждая дернута в живом сеансе, безопасный режим в двух положениях одного флага, обрушение модуля одним неверным перехватчиком, конфликт uuid, отсутствующий заимствованный объект, видимость нового кода в открытом сеансе, реакция LoadConfigFromFiles, UpdateDBCfg, CheckConfig, CheckCanApplyConfigurationExtensions, ibcmd extension list, оба программных метода и журнал регистрации.

Контроль на «это не мой кривой стенд» стоял там, где он вообще возможен. В опытах с аннотациями и с обрушением модуля рядом с падающим вариантом, в том же модуле, жил заведомо рабочий. В трех случаях — безопасный режим, конфликт uuid, лишнее заимствование — такого контроля быть не может, там ложится расширение целиком. Контроль там другой: до и после изменения ровно одной вещи, остальное не трогалось.

Не проверено и потому идет как мнение, а не как факт:

• Клиент-серверная база. Все замеры файловые. Про динамическое обновление в клиент-серверной знаю только то, что платформа там сама предлагает перезапуск. Своими руками не мерил.
• Профили безопасности. У свойства БезопасныйРежим тип не только булев, туда можно положить имя профиля, и тогда набор доступных расширению модулей задают настройки профиля. На полигоне были только положения «да/нет».
• Модули форм и модули объектов: все замеры по аннотациям — про общий модуль.
• Другие типы лишних заимствований: гонял отсутствующий общий модуль, не справочник и не форму.
• Поведение &ИзменениеИКонтроль при обновлении типовой: на пустом полигоне обновлять нечего, рассуждение сделано по механике контроля.
• Что будет в 8.3.28. По записи «Зазеркалья» про развитие расширений там появляется свойство «Действие при проверке свойств расширением» с вариантами «запретить подключение / подключить с предупреждением / подключить без уведомления». Похоже, часть описанного тут скоро станет настраиваемой. Читал анонс, руками не щупал.
• Возврат безопасного режима при перезагрузке. Выше писал: на 8.5 флаг не возвращался, на более ранних наблюдал обратное. Тут я скорее сомневаюсь, чем знаю.

Вместо вывода

Что останется в руках. Функцию оборачивают через &Вместо и ПродолжитьВызов(): оригинал отрабатывает внутри вашего перехватчика, и дописать свое к его результату — одна строка. Выкатку проверяют тремя вещами сразу: обоими методами РасширенияКонфигурации, журналом с отбором по уровню «Предупреждение» и наблюдаемым следствием самого перехватчика. Третье важнее первых двух, потому что только оно отвечает на вопрос, ради которого расширение вообще писали.

И забавная находка напоследок. Базу для опытов взял старую, свою же, с YaXUnit внутри. Первый же вызов ПроверитьВозможностьПримененияВсех() выдал про постороннее расширение, которое вообще не трогал: Отсутствуют метаданные для расширения конфигурации. Оно лежало там битым неизвестно сколько недель, числилось активным, и никто этого не замечал.

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

Правда интересно, у одного меня так или это общее ))

И последний вопрос, на который ответа нет. Раз платформа знает это в момент старта сеанса — почему уровень записи «Предупреждение», а не «Ошибка»? Довод вижу только один: расширение-то подключилось, просто не полностью. Но с точки зрения того, кто выкатил доработку и ушел домой, между «не подключилось» и «подключилось и ничего не делает» разницы нет.