← На главную

При разработке тиражных решений на платформе 1С:Предприятие часто возникает ситуация, когда один и тот же функционал должен существовать и развиваться параллельно: как в виде отдельной самописной конфигурации (файл .cf), так и в виде расширения (файл .cfe) для встраивания в типовые базы. Основная сложность заключается в том, что стандартный конфигуратор 1С не умеет напрямую сравнивать объекты разных типов. Разберем детально, как решить эту задачу, используя современные инструменты разработки и технические хитрости.

Использование Enterprise Development Tools (EDT)

На сегодняшний день EDT (Enterprise Development Tools) является наиболее мощным и официальным инструментом для решения подобных задач. Платформа EDT построена на базе Eclipse и предлагает совершенно иной подход к работе с метаданными. В отличие от стандартного конфигуратора, EDT оперирует проектами, которые представляют собой наборы XML-файлов.

Рассмотрим, как организовать процесс сравнения в EDT:

1. Создадим в среде EDT два отдельных проекта: один для основной конфигурации, импортировав его из .cf, и второй — для расширения, импортировав его из .cfe.
2. Воспользуемся встроенным механизмом Compare With. Проанализируем возможности этого инструмента: он позволяет сравнивать не только проекты целиком, но и отдельные файлы модулей, форм и макетов.
3. Благодаря тому, что в EDT все объекты представлены в виде структурированных файлов, мы можем выполнять слияние (merge) изменений. Проанализируем ситуацию: если в конфигурации была добавлена новая процедура в общем модуле, мы можем простым перетаскиванием или через панель сравнения перенести её в соответствующий модуль проекта расширения.

Важно отметить, что механизм сравнения в EDT понимает структуру объектов 1С и корректно подсвечивает различия в свойствах метаданных, что практически невозможно сделать в обычном текстовом diff.

Конвертация через модификацию XML-файлов

Если использование EDT по каким-то причинам невозможно, мы можем прибегнуть к методу «обмана» конфигуратора через подмену заголовков в файлах выгрузки. Этот способ требует внимательности, но он крайне эффективен для разовых сравнений большого объема метаданных.

Разберем этот метод по шагам:

1. Выгрузим обе конфигурации (основную и расширение) в файлы XML через стандартную команду конфигуратора Выгрузить конфигурацию в файлы.
2. Найдем в папке выгрузки основной конфигурации главный файл описания — Configuration.xml. Нам нужно изменить его структуру так, чтобы конфигуратор воспринял эти файлы как расширение.
3. Откроем Configuration.xml в текстовом редакторе. Нам необходимо заменить корневой тег Configuration на Extension. Рассмотрим пример структуры:
   Скопировать код

   
   <?xml version="1.0" encoding="UTF-8"?>
   <Extension xmlns="http://v8.1c.ru/8.3/MDClasses" ...>
      <Name>МоеРасширение</Name>
      <Purpose>Customization</Purpose>
      <UsePurposes>
         <v8:Value>PlatformApplication</v8:Value>
      </UsePurposes>
   </Extension>
   

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

   Применение специализированных утилит (cfe2cf)

   Для автоматизации процесса существуют сторонние инструменты, такие как cfe2cf. Это консольные утилиты, часто написанные на языке OneScript, которые выполняют трансформацию файлов расширения в формат основной конфигурации и наоборот.

   Проанализируем сценарий работы с такой утилитой:

   1. Утилита берет файл .cfe и распаковывает его содержимое.
   2. Происходит программная корректировка файлов описания метаданных (удаление специфичных для расширений свойств, таких как MDObject.Existence или ExtendedObject).
   3. Содержимое упаковывается в формат .cf.

   После такой конвертации мы получаем два файла .cf, которые можно сравнить любым стандартным способом, включая встроенный в 1С механизм или внешние инструменты сравнения файлов (например, WinMerge или Beyond Compare), предварительно выгрузив их в исходные коды.

   Сравнение программного кода модулей

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

   Рассмотрим алгоритм действий:

   1. В конфигураторе откроем нужный модуль (например, ОбщийМодуль.РаботаСКлиентами) в основной конфигурации.
   2. Сохраним текст модуля в файл .bsl или .txt через меню Файл — Сохранить как.
   3. Повторим операцию для того же модуля в расширении.
   4. Используем встроенную функцию платформы: Файл — Сравнить файлы. Выберем два полученных текстовых файла.

   Платформа подсветит добавленные, измененные и удаленные строки кода. Этот метод особенно удобен, если вы используете директивы компиляции или специфические аннотации расширений (например, &перед, &вместо, &после), так как они будут наглядно видны при сравнении с чистым кодом основной конфигурации. Для автоматизации этой задачи можно использовать инструмент для переноса изменений и генерации кода модулей расширений.

   Проблема уникальных идентификаторов (UUID)

   При синхронизации расширения и конфигурации важно помнить о UUID (уникальных идентификаторах) объектов. Если вы просто копируете объекты между базами, их идентификаторы могут различаться, даже если имена совпадают.

   Проанализируем последствия:

   1. Если расширение заимствует объект из конфигурации, оно хранит ссылку на UUID оригинального объекта.
   2. При ручном создании объекта в «самописке» и последующем его создании в расширении (без заимствования), это будут два абсолютно разных объекта для платформы.
   3. При использовании EDT система старается сопоставлять объекты по именам, что нивелирует проблему UUID при сравнении, но при загрузке обратно в конфигуратор об этом стоит помнить.

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

   Резюме и рекомендации

   Выясним, какой метод лучше выбрать в зависимости от ситуации:

   1. Для постоянной разработки: Однозначно выбираем EDT. Это позволит держать оба проекта в одной рабочей области и мгновенно переносить изменения между ними.
   2. Для быстрого разового сравнения: Используем метод подмены тегов в XML или конвертацию через cfe2cf.
   3. Для контроля только кода: Достаточно выгрузки модулей в текстовые файлы и их последующего сравнения.

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