← На главную

Часто в процессе разработки возникает необходимость сравнить файл расширения .cfe с основной конфигурацией .cf, чтобы получить точный список измененных объектов — по аналогии с классическим механизмом «Сравнить, объединить с конфигурацией из файла». Проанализируем эту ситуацию и разберем все доступные способы решения задачи.

Сразу отметим важное ограничение платформы: в классическом Конфигураторе 1С прямое сравнение файла расширения и файла основной конфигурации штатным инструментом не поддерживается. Платформа не позволяет напрямую сопоставить эти файлы из-за разницы в структуре хранения их метаданных. Также, если вы планируете дорабатывать базовые версии конфигураций с помощью расширений — это невозможно, платформа не поддерживает работу с расширениями в базовых версиях.

Рассмотрим подробнее, какие способы обхода этого ограничения существуют.

Способ 1: Сравнение через создание вспомогательного расширения (в Конфигураторе)

Если нет возможности использовать сторонние инструменты, разберем базовый обходной путь, предложенный разработчиками:

1. Создайте в базе новое (пустое) расширение.
2. Добавьте в это новое расширение ровно те же самые объекты, которые присутствуют в вашем рабочем расширении (захватите их из основной конфигурации).
3. Выполните штатное сравнение вашего рабочего расширения с этим новым созданным расширением.

Таким образом, новое расширение будет содержать типовые объекты основной конфигурации в том виде, в каком они существуют до ваших доработок, что позволит наглядно увидеть внесенные изменения.

Способ 2: Использование среды разработки 1C:EDT

Посмотрим на более современный подход. В отличие от стандартного Конфигуратора, среда разработки 1C:EDT (Enterprise Development Tools) штатно поддерживает функционал сравнения и объединения проектов.

Механизмы 1C:EDT умеют напрямую сравнивать проекты конфигураций с проектами расширений (а также с проектами внешних отчетов и обработок). При таком сравнении разработчик получает детальное отображение списков измененных объектов и удобный инструмент для разрешения конфликтов.

Способ 3: Сравнение через выгрузку в исходные файлы XML

Если необходимо детально проанализировать программный код, этот способ является наиболее точным и удобным для построчного анализа в заимствованных модулях. Выясним, как это сделать:

1. Выгрузите основную конфигурацию в исходные файлы в отдельный каталог на жестком диске.
2. Выгрузите расширение в исходные файлы (в другой каталог).
3. Используйте специализированные внешние программы для сравнения текста и папок. Подойдут такие утилиты, как KDiff3, Araxis Merge, WinMerge или их аналоги.

Сравнивая каталоги, вы наглядно увидите разницу в модулях и метаданных в формате XML-файлов.

Способ 4: Конвертация расширения (.cfe) в конфигурацию (.cf)

Чтобы воспользоваться стандартным механизмом сравнения в Конфигураторе, файл расширения можно искусственно превратить в обычную конфигурацию. Разберем по шагам, как это реализовать:

1. Выгрузите расширение в исходные файлы в формате XML.
2. Найдите главный конфигурационный файл (обычно он называется Configuration.xml).
3. В этом файле измените или удалите тег, который указывает платформе на то, что данные метаданные являются именно расширением.
4. Загрузите измененные исходные файлы в новую (абсолютно пустую) информационную базу.
5. Сохраните из этой пустой базы обычный файл конфигурации с расширением .cf.
6. Теперь вы можете выполнить стандартное «Сравнение, объединение с конфигурацией из файла» с вашей основной конфигурацией.

Примечание: Для этого метода существуют готовые сторонние консольные утилиты, которые умеют автоматизировать процесс конвертации CFE в CF.

Способ 5: Использование скриптов автоматизации

Для регулярных и более сложных задач разработчики применяют внешние скрипты, которые работают через движки исполнения кода на языке 1С без запуска самой платформы Конфигуратора. Проанализируем алгоритм их работы:

1. Скрипты принимают на вход предварительно выгруженные в XML каталоги конфигурации и расширения.
2. Автоматически анализируют переопределенные методы и проверяют расхождения в структуре метаданных.
3. Формируют итоговый отчет (например, в формате HTML) с подробным списком всех измененных объектов.

Такие скриптовые анализаторы также могут проверять корректность вызова глобальных функций основной конфигурации из заимствованных модулей расширения, что значительно повышает качество и стабильность разрабатываемого решения.