Расширение и типовая после обновления: где искать расхождения и чем их ловить
Содержание
Сравнить расширение с основной конфигурацией 1С можно тремя способами. Быстрый — проверить применимость расширения в Конфигураторе: платформа сама сверит заимствованные объекты, контролируемые свойства и перехваченные методы с конфигурацией базы. Наглядный — выгрузить обе конфигурации в файлы и сравнить каталоги любым diff-инструментом. Автоматический — поставить такую выгрузку и проверку в скрипт, который запускается после каждого обновления типовой.
Первый способ отвечает на вопрос «встанет ли расширение». Второй и третий — «что именно поменялось и где чинить». Всё ниже относится к платформе 8.3 (расширения появились в 8.3.6) и одинаково работает в любой конфигурации: Бухгалтерии 3.0, ЗУП 3.1, УТ 11, ERP.
Зачем сверять расширение с конфигурацией
Расширение не хранит копию типовой. Оно хранит ссылки на заимствованные объекты и свой код, который встраивается в чужие модули. Пока типовая не меняется, всё работает. После обновления релиза связи рвутся тихо или громко.
Что обычно ломается:
- 🔴 Исчез или переименован метод, на который стоит
&Перед,&После,&Вместоили&ИзменениеИКонтроль. Расширение перестаёт применяться. - 🟠 Изменился текст метода под
&ИзменениеИКонтроль. Платформа это контролирует и не даст применить расширение , пока вы не перенесёте правки. - 🟡 Сменилось контролируемое свойство заимствованного объекта: тип реквизита, длина строки, состав табличной части.
- 🔵 Поменялась форма: элемент, к которому вы привязали свою кнопку или поле, переместили или удалили. Расширение применится, но форма поведёт себя иначе.
- ⚪ Логика ушла в другой модуль. Ваш
&Послесрабатывает, но уже не там, где нужно: типовая вызывает новую процедуру в обход старой.
Последние два случая проверка применимости не поймает. Их видно только при построчном сравнении.
Встроенные средства Конфигуратора
Проверка применимости
Откройте Конфигуратор, затем Конфигурация → Расширения конфигурации. В списке выделите нужное расширение и выполните команду проверки применимости из меню действий списка. Платформа выдаст в окно сообщений все конфликты: какой объект или метод не найден, какое свойство не совпадает.
Расширение применяется к конфигурации базы данных, а не к основной конфигурации, которая открыта на редактирование. Если вы загрузили новый релиз, но ещё не выполнили Конфигурация → Обновить конфигурацию базы данных, проверка покажет состояние относительно старой структуры.
Сравнение расширения с его прошлой версией
Откройте расширение двойным щелчком в том же списке. Когда открыто дерево расширения, меню Конфигурация работает с ним: можно сохранить расширение в файл .cfe, загрузить из файла и сравнить, объединить с расширением из файла. Окно сравнения такое же, как для типовой: дерево объектов с отметками отличий и построчное сравнение модулей.
Это полезно, когда нужно понять, что поменял коллега, но не отвечает на вопрос, что поменялось в типовой.
Методы с контролем изменений
Для методов под &ИзменениеИКонтроль Конфигуратор хранит в расширении копию исходного текста метода с вашими вставками #Вставка … #КонецВставки и удалениями #Удаление … #КонецУдаления. Если в типовой метод изменился, расширение не применится. Откройте модуль расширения, встаньте на метод и через контекстное меню выполните сравнение с методом расширяемой конфигурации: увидите новые строки типовой и сможете перенести их в копию.
Сторонние инструменты: какой когда брать
Встроенное сравнение хорошо для разовой проверки. Для регулярной работы удобнее выгрузка в файлы и внешние программы.
| Инструмент | Когда подходит | Ограничения |
|---|---|---|
git diff | Конфигурация и расширение уже лежат в репозитории | Нужна дисциплина выгрузки после каждого изменения |
| WinMerge | Разовое сравнение двух каталогов в Windows, бесплатно | Медленно на полной выгрузке ERP |
| KDiff3 | Трёхстороннее сравнение: старая типовая, новая типовая, расширение | Интерфейс непривычен новичку |
| Beyond Compare | Большие каталоги, фильтры по маскам, отчёты | Платная лицензия |
| 1C:EDT | Разработка расширений в проекте, навигация по заимствованиям | Требует перевода проекта в EDT |
| VS Code + BSL Language Server | Чтение модулей, поиск ссылок, диагностика кода | Не понимает метаданные как Конфигуратор |
Логика сравнения у всех одна: выгрузить типовую и расширение в одинаковом формате, затем сопоставить одинаковые относительные пути.
Выгрузка основной конфигурации в файлы
Основную конфигурацию выгружают командой Конфигурация → Выгрузить конфигурацию в файлы. Укажите пустой каталог, формат оставьте иерархическим. Получится набор XML-файлов метаданных и файлов .bsl с кодом модулей.
Из командной строки то же самое делает пакетный режим Конфигуратора:
set V8="C:\Program Files\1cv8\<версия>\bin\1cv8.exe"
set BASE="D:\Bases\Test"
%V8% DESIGNER /F %BASE% /N "Администратор" /P "" ^
/DumpConfigToFiles "D:\cmp\base" ^
/Out "D:\cmp\dump_base.log"
Пути модулей в выгрузке предсказуемы:
CommonModules/<Имя>/Ext/Module.bsl— общий модуль;Documents/<Имя>/Ext/ObjectModule.bsl— модуль объекта документа;Documents/<Имя>/Ext/ManagerModule.bsl— модуль менеджера;Documents/<Имя>/Forms/<ИмяФормы>/Ext/Form/Module.bsl— модуль формы.
Выгружайте конфигурацию той же базы, к которой подключено расширение. Выгрузка типовой из другой базы с другим релизом даст ложные расхождения.
Пакетный запуск Конфигуратора с выгрузкой не требует монопольного доступа, но на большой базе ERP работает несколько минут и заметно нагружает диск. Запускайте на копии или в нерабочее время.
Выгрузка расширения в файлы
Расширение выгружают той же командой, только с ключом -Extension и именем расширения (имя, не синоним):
%V8% DESIGNER /F %BASE% /N "Администратор" /P "" ^
/DumpConfigToFiles "D:\cmp\ext" -Extension "МоиДоработки" ^
/Out "D:\cmp\dump_ext.log"
Чтобы выгрузить все расширения базы разом, используйте -AllExtensions: каждое ляжет в свой подкаталог. Для архива подойдёт и файл: /DumpCfg "D:\cmp\МоиДоработки.cfe" -Extension "МоиДоработки".
Что вы увидите в каталоге расширения:
- 📄
Configuration.xml— свойства расширения: назначение (исправление, адаптация, дополнение), префикс имён, режим совместимости; - 📁 каталоги заимствованных объектов — в их XML есть строка
<ObjectBelonging>Adopted</ObjectBelonging>и ссылка на исходный объект<ExtendedConfigurationObject>; - 📁 собственные объекты расширения — без признака заимствования;
- 📄 файлы
.bsl— только ваш код, без кода типовой.
Список всех заимствованных объектов получается одной командой в Git Bash или WSL:
grep -rl "<ObjectBelonging>Adopted</ObjectBelonging>" /d/cmp/ext --include=*.xml
Как сравнить расширение с конфигурацией: порядок работы
Ключевое наблюдение: относительный путь модуля в выгрузке расширения совпадает с путём того же модуля в выгрузке типовой. Поэтому сравнение сводится к проходу по файлам расширения.
Шаг 1. Подготовьте две выгрузки
Выгрузите типовую в D:\cmp\base, расширение — в D:\cmp\ext, как показано выше. Проверьте логи /Out: пустой лог или строки без слова «ошибка» значат, что выгрузка прошла.
Шаг 2. Найдите перехваты, которым некуда встать
Это главная проверка. Скрипт на Python читает все модули расширения, находит аннотации перехвата и ищет целевой метод в том же модуле типовой:
import re
import sys
from pathlib import Path
base = Path(sys.argv[1]) # выгрузка типовой
ext = Path(sys.argv[2]) # выгрузка расширения
ann = re.compile(
r'^\s*&(Перед|После|Вместо|ИзменениеИКонтроль)\s*\(\s*"([^"]+)"\s*\)',
re.M)
problems = 0
for bsl in ext.rglob('*.bsl'):
rel = bsl.relative_to(ext)
targets = ann.findall(bsl.read_text(encoding='utf-8-sig'))
if not targets:
continue
src = base / rel
if not src.exists():
print(f'НЕТ МОДУЛЯ В ТИПОВОЙ: {rel}')
problems += len(targets)
continue
src_text = src.read_text(encoding='utf-8-sig')
for kind, name in targets:
pat = (r'^\s*(?:Асинх\s+)?(?:Процедура|Функция)\s+'
+ re.escape(name) + r'\s*\(')
if not re.search(pat, src_text, re.M | re.I):
print(f'НЕТ МЕТОДА: {rel} -> {name} (&{kind})')
problems += 1
print('Проблем найдено:', problems)
sys.exit(1 if problems else 0)
Запуск: python check_ext.py D:\cmp\base D:\cmp\ext. Каждая строка вывода — конкретный модуль и метод, который надо искать в новом релизе.
Шаг 3. Сравните методы, а не только их наличие
Метод может остаться на месте, но поменять параметры или смысл. Для каждого перехваченного метода откройте в diff-инструменте модуль типовой до обновления и после. Удобнее всего трёхстороннее сравнение в KDiff3: старая типовая, новая типовая, модуль расширения.
Смотрите на три вещи:
- Изменился ли список параметров.
&Вместос прежней сигнатурой вызовет ошибку во время выполнения. - Появились ли новые ветки до или после вашей точки перехвата.
&Послеможет срабатывать уже после того, как типовая записала данные. - Вызывается ли метод вообще. Поищите его имя по всей новой выгрузке: если вызовов не осталось, перехват бесполезен.
Шаг 4. Сверьте формы и метаданные
Для заимствованных форм сравните файлы Form.xml из расширения и типовой. Ищите элементы, к которым вы привязаны: если родительская группа исчезла, ваше поле окажется в другом месте формы или пропадёт.
Для заимствованных объектов сравните XML реквизитов: тип, длину, наличие. Контролируемые свойства платформа проверит сама, остальные — нет.
Шаг 5. Подтвердите в базе
Загрузите новый релиз в копию базы , обновите конфигурацию базы данных, затем проверьте применимость расширения в списке расширений. Откройте каждую доработанную форму и проведите по одному документу каждого изменённого вида.
Автоматизация: скрипт в CI/CD
Если расширений несколько, а типовая обновляется раз в месяц, ручная сверка быстро надоедает. Ту же проверку ставят в конвейер сборки: GitLab CI, Jenkins, TeamCity — что уже есть в команде.
Типичная цепочка шагов:
- Создать пустую файловую базу
:
1cv8 CREATEINFOBASE File="D:\ci\db". - Загрузить в неё новую типовую из
.cf(/LoadCfg) и обновить базу (/UpdateDBCfg). - Загрузить расширение
из файлов:
/LoadConfigFromFiles "D:\ci\ext" -Extension "МоиДоработки", затем снова/UpdateDBCfgс тем же ключом-Extension. - Проверить модули:
/CheckModulesс ключом-Extensionи нужными режимами (сервер, тонкий клиент). - Выгрузить обе конфигурации в файлы и прогнать Python-скрипт из шага 2.
- Сохранить логи
/Outкак артефакты сборки. Код возврата не 0 — сборка красная.
Готовые обёртки над пакетным режимом есть в открытых проектах сообщества, например vanessa-runner: он упрощает загрузку, обновление и проверку расширений одной командой. Для автоматических сценариев на сервере также подойдёт утилита ibcmd; её параметры для работы с расширениями смотрите в справке ibcmd help.
Храните в репозитории не только расширение, но и выгрузку типовой того релиза, под который оно написано. Тогда git diff между тегами релизов сразу покажет, какие модули типовой затронуты обновлением, и их можно пересечь со списком перехватов.
Частые ошибки при сравнении
Сравнивают с основной конфигурацией вместо конфигурации базы. В Конфигураторе загрузили новый .cf, но не обновили базу. Проверка применимости и реальная работа идут по конфигурации базы, а выгрузка показывает основную. Результаты расходятся.
Сравнивают выгрузки разного формата. Иерархическая и плоская выгрузки по-разному раскладывают файлы, и diff покажет «изменённым» всё подряд. Выгружайте обе стороны одной версией платформы и в одном формате.
Ищут метод только по имени. Методы с одинаковым именем есть в модуле объекта и модуле менеджера. Скрипт выше сверяет путь целиком; ручной поиск по всей выгрузке часто находит не тот модуль.
Путают синоним и имя расширения. Ключ -Extension принимает имя, как в свойстве «Имя». Синоним из списка расширений в режиме предприятия не подойдёт.
Проверяют расширения поодиночке. Если в базе два расширения перехватывают один и тот же метод, каждое по отдельности применится, а вместе они могут дать неожиданный результат. Порядок срабатывания зависит от назначения расширения: сначала исправления, затем адаптации, затем дополнения. Выгружайте все расширения ключом -AllExtensions и прогоняйте скрипт по каждому каталогу, а потом сведите списки перехватов: одинаковые пары «модуль — метод» в разных расширениях стоит разобрать вручную.
Можно ли сравнить расширение с конфигурацией прямо в режиме предприятия?
Почему diff показывает в расширении только часть модуля типовой?
&ИзменениеИКонтроль. Остальной текст живёт в типовой.Нужно ли сравнивать расширение после каждого исправительного релиза?
Чем `&ИзменениеИКонтроль` надёжнее `&Вместо` при обновлениях?
&Вместо молча заменит новую логику типовой вашей старой.