При разработке или обновлении конфигураций на платформе 1С:Предприятие 8.3 разработчики часто сталкиваются с ситуацией, когда расширение отказывается подключаться, выдавая ошибку о различии режимов совместимости. Даже если в настройках расширения установлены параметры, кажущиеся верными, система может блокировать запуск. В этой статье мы подробно разберем, почему возникает эта ошибка, как работает логика совместимости и какие шаги необходимо предпринять для устранения проблемы.
Первое, что мы должны проанализировать — это понимание значения настройки Режим совместимости: Не использовать в контексте расширения. Существует распространенное заблуждение, что этот режим заставляет расширение автоматически подстраиваться под основную конфигурацию. На самом деле это работает иначе.
Когда мы устанавливаем в расширении значение Не использовать, это означает, что расширение будет использовать максимальные возможности текущей версии платформы, на которой запущен сеанс. Например, если ваша платформа версии 8.3.12, то расширение в режиме Не использовать будет работать по правилам 8.3.12.
Проанализируем ситуацию: если основная конфигурация имеет установленный режим совместимости (например, Версия 8.3.10), а в расширении стоит Не использовать, возникает конфликт. Возможности расширения (8.3.12) оказываются выше возможностей основной конфигурации (8.3.10). Система 1С строго придерживается правила: режим совместимости расширения должен либо полностью совпадать с режимом основной конфигурации, либо быть ниже его. Использование режима Не использовать в расширении допустимо только в том случае, если в основной конфигурации он также отключен.
Если простое изменение значения в свойствах не помогает (система продолжает «видеть» старое значение), нам необходимо выполнить процедуру принудительного обновления метаданных. Рассмотрим пошаговый алгоритм, который помогает очистить внутренние ссылки расширения:
Режим совместимости точно такой же, какой указан в свойствах основной конфигурации..cfe).Этот метод позволяет полностью избавиться от «фантомных» связей в кэше метаданных, которые часто мешают корректному применению настроек после обновления платформы или основной конфигурации.
В современных конфигурациях, таких как Управление торговлей 11, ERP или Бухгалтерия предприятия 3.0, за проверку версий отвечает не только платформа, но и программный код Библиотеки стандартных подсистем (БСП). Даже если в конфигураторе режимы совпадают, код при запуске может вызывать исключение.
Выясним причину: в модулях БСП часто жестко прописана минимально необходимая версия платформы. Если мы пытаемся использовать возможности новых версий расширений, нам может потребоваться скорректировать программные ограничения. Проанализируем, где это находится.
Как правило, проверка происходит в общем модуле СтандартныеПодсистемыСервер. Нам необходимо найти процедуру, отвечающую за запуск программы (например, ПередЗапускомПрограммы) или функцию определения версии. Рассмотрим пример изменения кода:
// В модуле СтандартныеПодсистемыСервер
Процедура ПередЗапускомПрограммы()
// Изначально может быть установлено:
// ПоддерживаемаяВерсияПлатформы = "8.3.10";
// Для обхода ошибки принудительно укажем версию платформы,
// соответствующую актуальному режиму:
ПоддерживаемаяВерсияПлатформы = "8.3.12";
КонецПроцедуры
Важно: для внесения таких изменений основную конфигурацию придется снять с поддержки (или разрешить изменения с сохранением поддержки). Делайте это только в том случае, если понимаете последствия и другие методы не помогли.
Иногда ошибка «Различие режимов» сохраняется из-за кэширования структуры расширений на стороне сервера. Проанализируем ситуацию с кэшем: 1С сохраняет скомпилированные модули и структуру метаданных в специальных директориях. Если база работает в клиент-серверном варианте, простым перезапуском конфигуратора проблему не решить.
Рекомендуется выполнить следующие действия:
snccntx в каталоге сервера (это очистит кэш сеансовых данных).Если ваша база является узлом Распределенной Информационной Базы (РИБ), ситуация усложняется. Изменение режима совместимости в главном узле может не передаться корректно в периферийный узел через стандартный обмен. В этом случае в периферийной базе расширение может «застрять» в старом состоянии. Единственным надежным решением здесь будет полное удаление расширения в узле и его повторная загрузка после успешного обмена.
Рассмотрим специфику платформы 8.3.12, упомянутую в проблеме. В этой версии были существенно изменены механизмы работы с заимствованными объектами. Если в вашем расширении заимствованы формы, макеты или объекты, формат хранения которых изменился между режимами совместимости (например, составные типы или механизмы нумерации), платформа может блокировать расширение даже при формально правильных настройках.
В такой ситуации попробуем выполнить диагностику:
Также не забывайте про параметр запуска /DisableStartupChecks. Использование этого флага позволяет временно пропустить первичные проверки при запуске 1С, что может быть полезно, чтобы дать системе возможность завершить фоновые процессы обновления метаданных расширения при первом запуске после обновления.
Подводя итог, отметим, что решение проблемы всегда кроется в строгом соответствии настроек Режим совместимости между основной конфигурацией и всеми подключенными расширениями, а также в чистоте кэша метаданных системы.