Как обойти проверку минимальной версии платформы в типовых конфигурациях 1С

Программист 1С v8.3 (Управляемые формы) 1C:Бухгалтерия IT и автоматизация бизнеса
← На главную

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

Механизм проверки: почему стандартные правки кода перестали помогать

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

  1. Система использует регламентное задание ОбновлениеИнформацииОВерсияхПлатформы.
  2. Это задание обращается к серверам обновлений 1С и скачивает файл (обычно в формате XML), содержащий актуальные требования для конкретного релиза конфигурации.
  3. Полученные данные кэшируются в базе данных, например, в регистре сведений ПараметрыРаботыПрограммы.
  4. При запуске система обращается не к модулю СтандартныеПодсистемыСервер, а к локализационным и переопределяемым модулям, которые считывают данные из этого кэша.

Рассмотрим подробнее способы, которые помогут нам вернуть контроль над системой.

Способ 1. Переопределение в модуле локализации

Выясним причину, по которой обычное изменение функции МинимальнаяВерсияПлатформыДляИспользования не дает результата. В современных версиях БП 3.0 проверка сместилась в сторону региональных настроек. Чтобы эффективно подменить требуемую версию, нам необходимо создать расширение и перехватить процедуру в модуле СтандартныеПодсистемыСерверЛокализация.

Разберем пример кода, который необходимо добавить в расширение:


&После("ПриОпределенииМинимальнойИРекомендуемойВерсийПлатформы")
Процедура Расш1_ПриОпределенииМинимальнойИРекомендуемойВерсийПлатформы(МинимальнаяВерсия, РекомендуемаяВерсия)
    // Устанавливаем версию, которая нас устраивает
    МинимальнаяВерсия = "8.3.22.1606";
    РекомендуемаяВерсия = "8.3.22.1606";
КонецПроцедуры

Этот метод хорош тем, что он перекрывает данные, полученные из кэша или внешних источников, непосредственно перед тем, как система примет решение о блокировке запуска.

Способ 2. Отключение проверки через параметры обновления

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

В расширении следует применить следующий подход:


&После("ПриОпределенииПараметровПолученияОбновлений")
Процедура Расш1_ПриОпределенииПараметровПолученияОбновлений(Параметры)
    // Принудительно отключаем проверку версии платформы в структуре параметров
    Если Параметры.Свойство("ПроверятьМинимальнуюВерсиюПлатформы") Тогда
        Параметры.ПроверятьМинимальнуюВерсиюПлатформы = Ложь;
    КонецЕсли;
КонецПроцедуры

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

Способ 3. Отключение регламентных заданий и очистка кэша

Если решение через расширение кода по каким-то причинам не срабатывает (например, проверка вшита глубже в ядро), стоит рассмотреть административные меры. Посмотрим на ситуацию со стороны сетевого взаимодействия. Если программа не сможет «узнать» о том, что версия платформы устарела, она продолжит работать на старой.

Выполним следующие шаги:

  1. Зайдем в раздел Обслуживание — Регламентные и фоновые задания.
  2. Найдем задание с наименованием Обновление информации о версиях платформы.
  3. Отключим его (снимем флаг «Включено»).
  4. Дополнительно можно заблокировать на уровне фаервола или файла hosts доступ к серверам downloads.1c.ru, чтобы система физически не могла скачать актуальный XML-файл с требованиями.

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

Почему 1С так настойчиво требует обновления?

Проанализируем ситуацию объективно. Иногда требование новой платформы оправдано. В новых версиях конфигураций могут использоваться методы (например, работа с HTTPСервис, новые функции криптографии или расширенная работа с PDF), которые физически отсутствуют в старых версиях платформы 8.3. В этом случае, даже если вы успешно обойдете проверку версии, программа может аварийно завершиться с ошибкой «Метод объекта не обнаружен» или вызвать «дамп» системы.

Также стоит учитывать, что начиная с платформы 8.3.27, компания 1С внедрила новые механизмы защиты и контроля лицензионности. Поэтому требование перехода на 8.3.27.1859 и выше часто связано не столько с функционалом БП, сколько с политикой безопасности самой фирмы 1С.

Рекомендации по стабильной работе

Разберем алгоритм действий, если вы решили остаться на проверенном релизе платформы (например, 8.3.22.1606 или 8.3.25):

  1. Всегда имейте под рукой расширение, корректирующее работу модулей СтандартныеПодсистемыСерверЛокализация и ПолучениеОбновленийПрограммыПереопределяемый.
  2. Перед обновлением конфигурации на новый релиз обязательно проверяйте отзывы коллег на форумах. Если в новом релизе платформы замечены критические ошибки (как это часто бывает в первые две недели после выхода), лучше повременить с обновлением «движка».
  3. Если система выдает предупреждение, но позволяет работать (как это реализовано в некоторых версиях 185-го релиза), возможно, стоит смириться с предупреждением, не прибегая к радикальным правкам кода.

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

← На главную