Версии расширений в 1С 8.3: служебный справочник БСП, номера в свойствах и контроль совместимости
Содержание
Справочник ВерсииРасширений в типовых конфигурациях 1С 8.3 (Бухгалтерия 3.0, ЗУП 3.1, УТ 11 и другие на БСП) не хранит номера версий ваших расширений. Это служебный объект: каждый его элемент соответствует одному набору подключённых расширений, с которым работали сеансы. А номер версии конкретного расширения смотрят в другом месте — в списке Администрирование → Печатные формы, отчеты и обработки → Расширения или в свойстве «Версия» в конфигураторе.
Путают эти вещи постоянно. Администратор открывает справочник через «Все функции», видит десятки безликих элементов и решает, что это «история обновлений» доработок. На деле это кэш, который программа ведёт сама. Руками его не правят.
Как устроен справочник версий расширений и зачем он нужен
Расширение меняет состав метаданных: добавляет реквизиты, формы, роли, перехватывает методы. Значит, у двух сеансов с разным набором расширений программа фактически разная. Библиотеке стандартных подсистем (БСП) нужно это различать, чтобы не путать кэшированные данные.
Схема такая:
- 🧩 при входе пользователя платформа применяет все активные расширения;
- 🔑 БСП вычисляет «отпечаток» получившегося набора и ищет его в справочнике
ВерсииРасширений; - ➕ если такого набора ещё нет, создаётся новый элемент;
- 📌 ссылка на элемент записывается в параметр сеанса
ВерсияРасширений; - 🗂 под эту ссылку в регистре сведений
ПараметрыРаботыВерсийРасширенийхранятся вычисленные параметры: идентификаторы объектов расширений, данные о ролях, служебные настройки.
Рядом живёт справочник ИдентификаторыОбъектовРасширений. Он делает для объектов расширений то же, что ИдентификаторыОбъектовМетаданных для основной конфигурации: даёт им постоянные ссылки, на которые можно сослаться в настройках прав, вариантах отчётов и рассылках.
Что из этого следует на практике
| Действие администратора | Что происходит в справочнике |
|---|---|
| Подключили новое расширение | При следующем входе появится новый элемент |
| Обновили расширение до новой сборки | Тоже новый элемент: набор изменился |
| Отключили расширение | Новый элемент для набора без него |
| Ничего не меняли | Новые элементы не появляются |
| Прошло время после изменения | Старые элементы удаляет регламентное задание |
Отсюда простое правило: число элементов растёт вместе с частотой изменений расширений, а не с числом пользователей.
Если в справочнике сотни элементов, а расширения меняют раз в месяц, проверьте, работает ли очистка (о ней ниже). Обычно в нём единицы или десятки записей.
Где посмотреть текущие версии расширений
Номер версии расширения — это строка в его свойстве «Версия». Её заполняет разработчик. Платформа её не проверяет и сама не увеличивает. Если разработчик забыл поменять номер, две разные сборки будут выглядеть одинаково.
В пользовательском режиме
В БП 3.0, ЗУП 3.1 и УТ 11 путь одинаковый:
- Откройте
Администрирование → Печатные формы, отчеты и обработки. - Включите флажок «Расширения», если он выключен.
- Перейдите по ссылке «Расширения».
- В списке видны имя, версия и признак, подключено ли расширение.
Здесь же расширения добавляют из файла .cfe, обновляют и отключают. Для этого нужна роль с полными правами.
Через стандартную обработку платформы
Если типовой формы нет (самописная конфигурация без БСП), используйте Все функции → Стандартные → Управление расширениями конфигурации. Команда «Все функции» включается в Сервис и настройки → Параметры → Отображать команду «Все функции».
В конфигураторе
- Меню
Конфигурация → Расширения конфигурации. - Выделите расширение, откройте его конфигурацию.
- В корне дерева вызовите свойства: поле «Версия», а рядом «Режим совместимости», «Назначение», «Безопасный режим».
Программно
Когда баз много, список удобнее получить кодом. Метод выполняется на сервере:
&НаСервере
Процедура ПоказатьРасширенияНаСервере()
Расширения = РасширенияКонфигурации.Получить();
Для Каждого Расширение Из Расширения Цикл
Сообщить(СтрШаблон("%1 | версия %2 | активно: %3",
Расширение.Имя, Расширение.Версия, Расширение.Активно));
КонецЦикла;
КонецПроцедуры
Этот код можно положить во внешнюю обработку
и запускать в любой базе. Для сверки сборок полезно ещё свойство ХешСумма: оно отличается у разных сборок даже при одинаковом номере версии.
А сам служебный справочник проще всего оценить запросом в консоли запросов:
ВЫБРАТЬ
КОЛИЧЕСТВО(*) КАК ЧислоВерсий
ИЗ
Справочник.ВерсииРасширений КАК ВерсииРасширений
Совместимость расширения с конфигурацией при обновлении
Расширение привязано к конкретной структуре основной конфигурации. Оно ссылается на объекты, формы и методы по именам. После обновления типовой что-то из этого могло исчезнуть или поменяться.
Что проверяют перед обновлением типовой:
- 📋 режим совместимости расширения не выше, чем у основной конфигурации;
- 🔗 заимствованные объекты и формы ещё существуют под теми же именами;
- 🎯 перехваченные методы (
&Перед,&После,&Вместо,&ИзменениеИКонтроль) остались в модулях и не поменяли параметры; - 🧱 у заимствованных форм не разошлась структура элементов, которые расширение меняет.
Если расширение нельзя применить, платформа не запустит его вместе с базой. Пользователь получит сообщение об ошибке применения, а функции расширения пропадут, хотя сама база откроется.
Порядок действий при обновлении
- Сделайте копию базы и обновите типовую в ней.
- Откройте расширение в конфигураторе копии и проверьте его применимость.
- Исправьте ошибки: перезаимствуйте изменившиеся объекты, поправьте перехватчики.
- Увеличьте номер в свойстве «Версия».
- Сохраните расширение в
.cfeи загрузите в рабочую базу после обновления типовой.
Методы с аннотацией &ИзменениеИКонтроль платформа проверяет строже: если исходный текст метода в типовой изменился, расширение не применится. Это защита, а не сбой. Сравните новый текст метода с вашей копией и перенесите правки.
После загрузки нового .cfe сеансы, открытые раньше, продолжат работать со старым набором. Чтобы пользователи получили новую версию, им нужно перезапустить программу. Обновляйте расширения в рабочей базе вне рабочего времени или предупреждайте людей заранее: перезапуск оборвёт несохранённую работу.
Конфликты версий расширений и как их снять
Конфликты бывают двух видов: между расширениями и вокруг служебного справочника.
Два расширения правят одно и то же
Если два расширения перехватывают один метод или меняют один элемент формы, итог зависит от порядка их применения. Одно может «перебить» другое без ошибок, и это хуже всего: в журнале пусто, а печатная форма работает по чужой логике.
Как найти такие пересечения:
- Откройте каждое расширение в конфигураторе.
- Выпишите заимствованные объекты, у которых есть изменения или перехваты.
- Сравните списки. Совпадение по одному методу или форме — кандидат на конфликт.
- Объедините правки в одном расширении или разнесите их по разным методам.
Блокировки при входе после обновления
После смены набора расширений первый сеанс создаёт элемент справочника и заполняет параметры в регистре. Если в эту минуту в базу входят 50–100 человек, они могут ждать друг друга на одной записи. Снаружи это выглядит как долгий вход или ошибка блокировки при запуске.
Что помогает:
- 🌙 менять расширения вечером или до начала рабочего дня;
- 🚪 первым после обновления войти самому, чтобы элемент и параметры создались до прихода пользователей;
- 🔁 не перезаливать одно расширение по несколько раз за день.
Справочник разросся
Устаревшие элементы удаляет регламентное задание БСП. Чтобы проверить его:
- Откройте
Администрирование → Обслуживание → Регламентные операции → Регламентные и фоновые задания. - Найдите задание по слову «расширен» через поиск в списке.
- Убедитесь, что оно включено и в журнале нет ошибок.
В файловой базе регламентные задания выполняются только при открытом сеансе клиента, поэтому на редко открываемых базах очистка запаздывает. Удалять элементы справочника вручную не стоит: на них ссылаются параметры живых сеансов.
Автоматизация контроля версий в крупных проектах
Когда расширений пять, а баз двадцать, сверять версии глазами уже нельзя. Нужен один источник правды и сборка без ручных шагов.
Исходники в системе контроля версий
Расширение выгружают в файлы и хранят в Git. Из конфигуратора это делается командой выгрузки в файлы, из пакетного режима — так:
"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe" DESIGNER /F "D:\Bases\Test" /N "Admin" /P "" ^
/DumpConfigToFiles "D:\src\MyExt" -Extension MyExt
Путь к платформе подставьте свой. Пароль в командной строке храните в переменной окружения сборочного сервера, а не в скрипте.
Сборка и загрузка в базы
Для выкладки в рабочие базы используют связку из двух команд:
"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe" DESIGNER /F "D:\Bases\Work" /N "Admin" /P "%PWD1C%" ^
/LoadCfg "D:\build\MyExt.cfe" -Extension MyExt /UpdateDBCfg -Extension MyExt /Out "D:\build\log.txt"
Загрузка .cfe и обновление конфигурации базы данных для расширения — два отдельных действия. Без /UpdateDBCfg новая версия не вступит в силу. Лог из /Out разбирайте скриптом: строка об ошибке применения должна останавливать выкладку.
Сверка версий по всем базам
Удобная схема для парка баз:
- Внешняя обработка с кодом из раздела выше выгружает имя, версию и хеш расширений в файл.
- Планировщик раз в сутки запускает её по списку баз.
- Скрипт сравнивает результат с эталоном из Git и пишет расхождения.
В проектах на EDT принцип тот же, меняется только формат исходников. Главное — номер версии и хеш собираются автоматически, а не вписываются руками.
Как вести документацию по версиям расширений
Без документации через год никто не скажет, зачем в базе расширение Доработка_Петров_v2. Минимальный набор правил:
- 🏷 Имя и префикс. Латиница, смысловое имя, префикс в именах новых объектов (
мр_,pr_): так новые реквизиты не столкнутся с будущими объектами типовой. - 🔢 Номер версии. Схема из трёх-четырёх чисел:
1.4.2. Первое число — несовместимые изменения, второе — новые функции, третье — исправления. - 🧾 Журнал изменений. Файл
CHANGELOGв репозитории: дата, версия, что изменено, для какого релиза типовой проверено. - 🎯 Назначение. Свойство «Назначение» ставьте честно: «Исправление» для срочных правок, «Адаптация» для доработок под учёт, «Дополнение» для новых функций.
- 🛡 Безопасный режим. Включайте его для расширений сторонних авторов, если они не требуют обратного.
- 🔗 Привязка к релизу. В описании расширения указывайте, на каком релизе типовой оно проверено.
Что проверить перед выкладкой новой версии
Когда отдельное расширение не нужно
Не каждую правку стоит оформлять новым расширением. Если доработка касается тех же объектов, что и существующее расширение, лучше выпустить его новую версию. Десять мелких расширений — это десять точек отказа при каждом обновлении типовой и больше элементов в справочнике ВерсииРасширений.