При эксплуатации информационных систем на базе 1С:Предприятие часто возникают ситуации, когда необходимо изменить версию используемой платформы. Однако понижение версии (откат) — процедура гораздо более рискованная, чем обновление. В этой статье мы подробно разберем ситуацию, когда после перехода с платформы 8.3.15 на 8.3.14 конфигурация (например, УНФ 1.6.20) перестает запускаться с критической ошибкой инициализации модуля. Мы выясним причину этой проблемы и рассмотрим несколько способов ее решения.
Рассмотрим типичный сценарий: база данных работала на платформе 8.3.15.1830. По определенным причинам (например, из-за некорректной работы расширений с аннотациями &Перед и &После) принимается решение откатиться на стабильную ветку 8.3.14.2095. При запуске система выдает ошибку: «Процедура или функция с указанным именем не определена (НачатьПомещениеФайлаНаСервер)» в общем модуле УправлениеНебольшойФирмойКлиент.
Выясним причину. Начиная с версии платформы 8.3.15.1489, компания 1С реализовала проект по унификации методов работы с файлами. Были введены новые асинхронные методы, такие как НачатьПомещениеФайлаНаСервер, НачатьПомещениеФайловНаСервер и другие. Проблема заключается в том, что при разработке новых релизов конфигураций (например, УНФ, БП, ERP) разработчики начинают использовать эти методы в коде Библиотеки Стандартных Подсистем (БСП).
Важно понимать: даже если в свойствах конфигурации установлен режим совместимости 8.3.14, это не гарантирует корректную работу на физической платформе 8.3.14. Платформа версии 8.3.15 «понимает» этот метод даже в режиме совместимости, а платформа 8.3.14 — нет, так как в ее «движке» этого метода просто не существует. Это приводит к ошибке компиляции модуля еще до начала выполнения кода.
Многие разработчики сталкиваются с тем, что при попытке отладить эту ошибку точка останова игнорируется. Проанализируем, почему так происходит. Ошибка Процедура или функция не определена является ошибкой компиляции. Когда 1С пытается инициализировать общий модуль, она проверяет синтаксис всего модуля целиком. Обнаружив неизвестный метод, платформа прекращает загрузку модуля. Поскольку выполнение кода процедуры даже не начиналось, отладчик не может «зацепиться» за точку останова. В таких случаях бесполезно использовать стандартные средства отладки, так как проблема лежит на уровне синтаксического разбора модуля платформой.
Если причиной отката на версию 8.3.14 послужили проблемы с расширениями (например, перестали работать перехваты методов), то наиболее правильным решением будет остаться на платформе 8.3.15, но корректно настроить свойства расширения. Рассмотрим этот механизм подробнее.
В платформе 8.3.15 появились расширенные возможности по управлению режимом совместимости. Теперь для каждого расширения в свойстве Режим совместимости можно управлять проверкой. Если ваше расширение конфликтует с режимом совместимости основной конфигурации, попробуйте следующие шаги:
Не контролировать.Это позволит платформе игнорировать расхождения в режимах совместимости между основной конфигурацией и расширением, что часто решает проблемы с аннотациями &Перед, &После и &Вместо, возникшие в ранних релизах 8.3.15.
Если вам критически необходимо запустить базу именно на платформе 8.3.14, придется «обмануть» компилятор, создав заглушки для отсутствующих методов. Рассмотрим, как это сделать по шагам:
Глобальный, Клиент (управляемое приложение).Экспорт.Пример кода для эмуляции метода:
Процедура НачатьПомещениеФайлаНаСервер(ОписаниеОповещения, АдресВременногоХранилища = "", ИмяФайла = "", УникальныйИдентификатор = "") Экспорт
// Здесь мы перенаправляем вызов на старый метод, который существовал в 8.3.14
НачатьПомещениеФайла(ОписаниеОповещения, АдресВременногоХранилища, ИмяФайла, Ложь, УникальныйИдентификатор);
КонецПроцедуры
Внимание: Вам может потребоваться эмулировать целую группу методов. Проанализируем список наиболее вероятных «кандидатов»:
НачатьПомещениеФайлаНаСерверНачатьПомещениеФайловНаСерверНачатьПолучениеФайловССервераЭтот метод является трудоемким, так как новые функции могут иметь другие параметры или возвращать другие типы данных (например, новые объекты ОписаниеПередаваемогоФайла), поэтому полную совместимость обеспечить сложно.
Если вы готовы вносить изменения в типовой код (что крайне не рекомендуется для обновляемых конфигураций), можно использовать директивы препроцессора для разделения кода под разные версии платформы. Посмотрим на пример реализации:
#Если ТонкийКлиент Или ВебКлиент Тогда
// Проверяем версию платформы
СистемнаяИнформация = Новый СистемнаяИнформация;
ВерсияПлатформы = СистемнаяИнформация.ВерсияПриложения;
Если ОбщегоНазначенияКлиентСервер.СравнитьВерсии(ВерсияПлатформы, "8.3.15") >= 0 Тогда
НачатьПомещениеФайлаНаСервер(ОписаниеОповещения,,, АдресВременногоХранилища, ИмяФайла, УникальныйИдентификатор);
Иначе
НачатьПомещениеФайла(ОписаниеОповещения, АдресВременногоХранилища, ИмяФайла, Ложь, УникальныйИдентификатор);
КонецЕсли;
#КонецЕсли
Однако помните, что даже этот код не спасет от ошибки компиляции на платформе 8.3.14, так как компилятор все равно увидит вызов НачатьПомещениеФайлаНаСервер и не найдет его определения в глобальном контексте. Поэтому использование препроцессора эффективно только в связке с созданием «заглушек» из Варианта №2.
Проанализировав ситуацию, мы видим, что наиболее стабильным и современным решением является использование платформы актуальной ветки (8.3.15 и выше). Откат на устаревшие платформы при использовании новых релизов конфигураций (БСП 3.1 и выше) чреват множественными ошибками в модулях, работающих с файлами, криптографией и фоновыми заданиями.
Основные рекомендации:
Не контролировать.Соблюдение этих правил поможет вам избежать длительных простоев системы при обновлении или изменении инфраструктуры 1С.