При работе с собственными разработками на платформе 1С:Предприятие часто возникает ситуация, когда при попытке обновить информационную базу через файл .cfu система выдает ошибку: "Файл не содержит доступных обновлений". Эта проблема напрямую связана с тем, как именно был сформирован файл обновления и какие версии были указаны в качестве "базовых" в момент сборки поставки. Рассмотрим подробнее механизм работы обновлений и разберем по шагам, где именно в конфигурации задаются эти параметры.
Для начала проанализируем ситуацию: почему обычный файл конфигурации .cf принимается системой всегда, а файл обновления .cfu — нет? Дело в том, что .cfu (Configuration Update) — это дифференциальный файл. Он не содержит в себе всю конфигурацию целиком, а включает в себя только разницу ("дельту") между новой версией и набором конкретных предыдущих версий. Список этих "разрешенных" версий жестко прописывается в бинарном заголовке файла в момент его генерации. Если текущая версия вашей базы не входит в этот список, платформа 1С даже не начнет процесс сравнения, так как физически не сможет сопоставить данные.
Для самописных или сильно измененных типовых решений управление списком версий происходит в специальном интерфейсе "Поставка конфигурации". Выясним причину, почему это не всегда очевидно: данные настройки доступны только в том случае, если ваша конфигурация сама является объектом поставки (находится "на поддержке" у самой себя или стороннего вендора).
Рассмотрим по шагам процесс настройки списка версий:
FromVersions внутри .cfu.Важный момент: Если вы создаете обновление для конфигурации, которая не стоит на поддержке, или вы просто выгрузили .cf файл, то создать корректный .cfu не получится. Информация о предыдущих версиях сохраняется только в рамках настроенной системы поставки.
Часто в обсуждениях упоминается файл UpdInfo.txt. Разберем, как он связан с процессом. Этот файл является внешним по отношению к конфигурации и используется механизмом автоматического поиска обновлений (например, через интернет-ресурс или локальный сетевой каталог). Рассмотрим пример его содержимого:
Version=3.0.117.20
FromVersions=;3.0.114.23;3.0.115.15;3.0.115.19;3.0.116.24;3.0.116.26;3.0.116.27;3.0.116.32;
UpdateDate=27.07.2022
Проанализируем ситуацию: достаточно ли просто поменять версии в этом текстовом файле? Нет. Текстовый файл UpdInfo.txt лишь подсказывает платформе, какой .cfu файл стоит скачать. Если вы вручную добавите версию в UpdInfo.txt, но не укажете ее при сборке самого файла обновления в Конфигураторе, после скачивания система все равно выдаст ошибку о недоступности обновления.
В современных конфигурациях, построенных на базе БСП (Библиотека Стандартных Подсистем), например, 1С:ERP или 1С:КА, существуют дополнительные программные проверки версии. Даже если платформа приняла файл обновления, код конфигурации может заблокировать запуск, если версия не соответствует ожиданиям разработчика.
Посмотрим на пример кода, который позволяет "обмануть" систему в специфических случаях (например, при проверке совместимости с версиями движка или редакции). В общем модуле ОбщегоНазначенияКлиентСервер может находиться логика обработки номера версии. Рассмотрим фрагмент:
Функция ВерсияКонфигурацииБезНомераСборки(Знач Версия) Экспорт
Массив = СтрРазделить(Версия, ".");
Если Массив.Количество() < 3 Тогда
Возврат Версия;
КонецЕсли;
// Пример модификации для обхода проверки в 1С:ERP
Результат = "[Редакция].[Подредакция].[Релиз]";
Результат = СтрЗаменить(Результат, "[Редакция]", Массив[0]);
Результат = СтрЗаменить(Результат, "[Подредакция]", Массив[1]);
// Принудительно возвращаем 16-й релиз для совместимости
Результат = СтрЗаменить(Результат, "[Релиз]", "16");
Возврат Результат;
КонецФункции
Такие правки крайне не рекомендуются для постоянного использования, но они наглядно показывают, что помимо проверок на уровне платформы (в заголовке файла .cfu), существуют еще и прикладные проверки в коде конфигурации. Если вы разрабатываете свою подсистему, обратите внимание на регистрацию обработчиков обновления в модуле ОбновлениеИнформационнойБазы<ИмяКонфигурации>, где также могут быть жестко прописаны допустимые интервалы версий.
Если перед нами стоит задача обновить "самоделку" и мы не хотим возиться с настройками поставки и генерацией .cfu, существует более простой и надежный путь — использование полного файла конфигурации .cf. При использовании команды Конфигурация — Сравнить, объединить с конфигурацией из файла платформа игнорирует список предыдущих релизов. Это происходит потому, что .cf содержит полную структуру метаданных. Этот метод позволяет "перепрыгивать" через неограниченное количество версий (например, с версии 1.0 сразу на 5.0), что невозможно сделать с помощью .cfu без промежуточных обновлений.
Подведем итог: список предыдущих версий для обновления задается в Настройках поставки в момент создания файлов обновления. Если вы разработчик собственного решения, вам необходимо поддерживать актуальный список "Базовых версий" в мастере сборки, чтобы ваши пользователи могли беспрепятственно использовать файлы формата .cfu.