В практике разработки и сопровождения 1С мы часто сталкиваемся с необходимостью переноса доработок между базами, работающими на разных версиях технологической платформы. Одна из самых распространенных и неприятных ситуаций возникает при попытке подключить расширение конфигурации (файл *.cfe), созданное на более новой версии платформы, в базу, работающую на более старой версии.
Давайте подробно разберем ситуацию, с которой столкнулся автор темы. При попытке установить расширение в конфигураторе появляется сообщение об ошибке:
"Для работы с этим расширением конфигурации необходима версия платформы не меньше 8.3.27. Текущая версия платформы 8.3.22.xxxx".
Мы проанализируем причины этого поведения, рассмотрим альтернативы в виде патчей (исправлений), разберем ловушку настройки РежимСовместимости и рассмотрим несколько способов решения проблемы, включая тот, который помог автору.
На первый взгляд кажется, что требование обновить платформу — это просто формальная проверка цифр версий. Однако за этим стоит техническая несовместимость форматов и структуры метаданных.
Когда мы разрабатываем расширение на платформе версии 8.3.27, платформа записывает внутреннюю структуру файла расширения (сериализует объекты) в формате, соответствующем этой версии. Если мы попытаемся скормить этот файл платформе 8.3.22, она просто не поймет часть инструкций или структуру файла, так как формат мог измениться.
Ключевую роль здесь играет свойство расширения РежимСовместимости и дерево свойств объектов. Давайте выясним, как оно влияет на переносимость.
В ходе обсуждения выяснилось важное обстоятельство: в свойствах проблемного расширения параметр РежимСовместимости был установлен в значение "Не использовать".
Многие разработчики ошибочно полагают, что "Не использовать" означает "без ограничений", то есть расширение должно подходить ко всему. На самом деле логика работы платформы 1С прямо противоположна:
РежимСовместимости значение "Версия 8.3.22".Это заставляет платформу при сохранении файла перестроить его структуру под формат старой версии. Однако просто изменить это свойство в текущей (старой) базе невозможно, так как мы даже не можем загрузить туда расширение для редактирования.
Если у вас есть доступ к компьютеру с установленной новой платформой (той, которую требует расширение), мы рекомендуем выполнить следующие действия для корректной адаптации файла. Это наиболее надежный метод.
Давайте пройдем этот алгоритм по шагам:
РежимСовместимости.Теперь полученный файл будет иметь правильный заголовок версии и понятную для старой платформы структуру.
Иногда даже смена режима совместимости не помогает. Автор темы столкнулся с тем, что просто понижение версии не решало проблему или вызывало ошибки. В итоге решением стало удаление конкретного объекта метаданных.
Давайте проанализируем сообщение автора:
"В общем объект 'Регламентные задания' мешал, добавлю его по-другому". — для такой диагностики пригодится инструментарий анализа метаданных и структуры объектов.
Почему именно РегламентноеЗадание? Дело в том, что в версиях платформы между 8.3.23 и 8.3.25 произошли существенные изменения в механизме работы фоновых и регламентных заданий. Были добавлены новые возможности управления расписанием, параметры перезапуска и свойства, связанные с кластером серверов.
Когда старая платформа 8.3.22 пытается прочитать XML-описание регламентного задания, созданного в 8.3.27, она видит незнакомые теги и свойства, которых в ее структуре базы данных просто не существует. Это вызывает ошибку чтения потока или ошибку проверки метаданных.
Если вы столкнулись с подобной ситуацией, мы рекомендуем действовать методом исключения:
РегламентныеЗадания, HTTPСервисы, Беты-интеграции или объекты, использующие новые возможности интерфейса (например, СервисИнтеграции).Это именно то решение, к которому пришел автор обсуждения и которое часто является единственным рабочим вариантом, если разрыв между версиями слишком велик.
Суть метода заключается в отказе от файла *.cfe, созданного в новой версии. Вместо этого мы:
Почему это работает? Когда вы создаете объект РегламентноеЗадание вручную в конфигураторе версии 8.3.22, платформа создает его сразу с правильной структурой, понятной ей самой. Вы не приносите "чужеродные" свойства из новой версии.
Даже если вам удалось загрузить расширение (понизив режим совместимости или перенеся объекты вручную), расслабляться рано. Мы должны помнить о различиях во встроенном языке 1С.
В версии 8.3.27 могут использоваться методы, которых нет в 8.3.22. Например, новые функции для работы со строками, асинхронные методы работы с файловой системой или расширенные функции JSON.
Рассмотрим пример. В новых версиях могли появиться методы для работы со строками, упрощающие форматирование. Если такой код попадет на старую платформу:
// Код, работающий на 8.3.27
СтрокаРезультат = СтрШаблон("Привет, %1", ИмяПользователя);
// (СтрШаблон есть давно, но представим более новую функцию)
При попытке сохранить модуль на старой платформе вы можете получить синтаксическую ошибку. Но коварство заключается в том, что расширения часто не проходят полную проверку при подключении, и ошибка вылетит у пользователя в момент нажатия кнопки — для поиска причин есть инструмент отладки кода 1С в режиме Предприятие.
Поэтому, после успешной загрузки расширения обязательно выполните следующие действия:
Подводя итог обсуждению, сформулируем правильный порядок действий при ошибке "необходима версия платформы не меньше...":
РежимСовместимости. Если он стоит в "Не использовать" на новой платформе — это гарантия проблем. Поменяйте его на конкретную версию целевой платформы (например, 8.3.22) и пересохраните файл.РегламентныеЗадания, СервисыИнтеграции и сложные роли часто меняют свою внутреннюю структуру. Их лучше пересоздать вручную в целевой базе.В случае автора проблема решилась комбинацией методов: он выяснил, что простым изменением свойств вопрос не решается, и применил ручное пересоздание проблемного объекта РегламентноеЗадание, что позволило обойти ограничение версии.