Обновлено: 07.07.2024

Задача - выгрузить один объект метаданных (обработку) конфигурации в файлы и загрузить его обратно на платформе 8.3.10.

Вот код для обоих вариантов (отличие в закомментированной строке)

ТекстовыйДокумент = Новый ТекстовыйДокумент;
ТекстСпискаОбъектовКонфигурации = "";
//ТекстСпискаОбъектовКонфигурации = ТекстСпискаОбъектовКонфигурации + Метаданные.ПолноеИмя() + Символы.ПС; // Тут добавляется корень конфигурации
ТекстСпискаОбъектовКонфигурации = ТекстСпискаОбъектовКонфигурации + Метаданные.Обработки.ирПлатформа.ПолноеИмя();
ИмяФайлаСпискаВыгрузки = ПолучитьИмяВременногоФайла("txt");
ТекстовыйДокумент.УстановитьТекст(ТекстСпискаОбъектовКонфигурации);
ТекстовыйДокумент.Записать(ИмяФайлаСпискаВыгрузки);
КаталогВыгрузкиКонфигурации = ПолучитьИмяВременногоФайла();
СоздатьКаталог(КаталогВыгрузкиКонфигурации);
ТекстЛога = "";
Успех = ирОбщий.ВыполнитьКомандуКонфигуратораЛкс("/DumpConfigToFiles """ + КаталогВыгрузкиКонфигурации + """ -listFile """ + ИмяФайлаСпискаВыгрузки + """ -Format Plain",
СтрокаСоединенияИнформационнойБазы(), ТекстЛога, , "Выгрузка конфигурации в файлы");
УдалитьФайлы(ИмяФайлаСпискаВыгрузки);
Если Не Успех Тогда
УдалитьФайлы(КаталогВыгрузкиКонфигурации);
Сообщить(ТекстЛога);
Перейти

Конец;
КонецЕсли;
ФайлыДляЗагрузки = НайтиФайлы(КаталогВыгрузкиКонфигурации, "*.xml");

ИменаФайлов = Новый Массив;
Для Каждого Файл Из ФайлыДляЗагрузки Цикл
ИменаФайлов.Добавить(Файл.ПолноеИмя);
КонецЦикла;
СтрокаИменФайловЗагрузки = ирОбщий.ПолучитьСтрокуСРазделителемИзМассиваЛкс(ИменаФайлов, ",");
Успех = ирОбщий.ВыполнитьКомандуКонфигуратораЛкс("/LoadConfigFromFiles """ + КаталогВыгрузкиКонфигурации + """ -Files """ + СтрокаИменФайловЗагрузки + """ -Format Plain", , ТекстЛога,
, "Загрузка конфигурации из файлов");

УдалитьФайлы(КаталогВыгрузкиКонфигурации);
Если Не Успех Тогда
Сообщить(ТекстЛога);
КонецЕсли;

может вывести из себя, в особенности если вы чётко осознаёте бессмысленность потраченного времени на неё.

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

В случае, приведённом выше операция, если проект класса ERP, даже на топовом оборудовании (Core i7, SSD, >16Gb RAM) может отнять около полутора часов на полную пересборку, причём она не пройдёт полностью автоматически: после длительного импорта и конвертации в формат EDT, чтобы добиться желаемой синхронности:

нужно будет обновить конфигурацию ИБ и это будет тоже полная сборка.

Если говорить более конкретно, то моя патовая ситуация была такова, что я в EDT разрабатывал расширение для конфигурации ERP, а сама конфигурация была подключена к хранилищу 1С и была на железном, для меня, замке от того, что моя УЗ в репозитории 1С была только на чтение… Т.е. импорт то я бы сделал, но обновить конфигурацию ИБ не смог бы по определению, соответственно так как по отношению к проекту расширения основной проект не синхронизирован, сборка обновления расширения производится не будет…

Надо отметить, что злая штука здесь в том, что несмотря на то, что захват объектов в хранилище не произведён, объекты метаданных (в отличии, когда импортирована конфигурация, к примеру, на поддержке с запретом изменений) лихо редактируются в EDT и "сюрприз" может поджидать совсем неожиданно, когда нужно будет запустить отладку… Тут небольшой совет: даже если вы не собираетесь ничего изменять в основном проекте - сделайте его совместным и сделайте один коммит всего проекта в вашем локальном репо - вы всегда сможете откатить "случайные" или не очень изменения.

1. Открыл конфигуратор
2. Получил изменения из хранилища, в котором было добавление предопределённого элемента в справочнике и два переименования других предопределённых элементов
3. Обновил конфигурацию ИБ
4. Закрыл конфигуратор
5. В списке ИБ, для этой ИБ выбрал "Импортировать конфигурацию" и нажал в диалоговом окне кнопку обновить.

Что далее?

Далее всё. Выходом из этой ситуации поможет знание как устроен механизм синхронизации проекта EDT с информационной базой.

За заветную зелёную галку отвечает файл без расширения store, размещённый в служебном каталоге проекта Eclips'a:

• %1 - путь к вашему workspace
• %2 - имя вашего проекта как вы его видите в списке проектов панели навигатора 1С
• %3 - UUID информационной базы, связанной с проектом %2, как он числится в файле
  • "%USER PROFILE%\AppData\Roaming\1C\1CEStart\ibases.v8i"

  Содержимое файла, соответствующее зелёной галке, если его посмотреть в Notepad++ выглядит так:

  
  

  • Если вы в EDT измените какие-либо объекты метаданных, затем закроете EDT и посмотрите содержимое, то пути к изменённым объектам, и связанных с ними для инкрементального обновления будут размещены через semicolon справа от последнего NUL, но запись SYNCHRONIZED будет на месте.
  • А вот если справа от последнего NUL не будет ничего, а вместо SYNCHRONIZED будет UNSYNCHRONIZED, то при попытке обновить конфигурацию ИБ у вас будет в любом случае полная выгрузка проекта в XML и полная сборка CF.

  Надо отметить, что и в первом и во втором случае в редакторе проекта вместо зелёной галки будет жёлтая *

  До окончания сеccии EDT список изменённых объектов храниться в файле log, лежащим рядом со store, по закрытии сесcии EDT, данные из log'a переносятся в store, а сам файл удаляется.

  Наверное, вы сейчас подумали: "Ха, так достаточно заменить это файл store на сохранённый и будет всё тип топ - прощай унылая звезда и здравствуй зелёная галка!" Да, если погасить EDT, заменить этот файл, затем запустить снова, то заветный статус синхронизации в редакторе проекта будет присутствовать… Но, не всё так просто…

  Подобная махинация вас спасёт, если структура метаданных не была затронута, а именно - правки в модулях и возможно в текстах запросов СКД, возможно что-то ещё, но это что-то должно однозначно не изменять файл ConfigDumpInfo.xml который является неотъемлемой частью этого механизма.

  Общее размещение файлов на картинке:

  
  

  После первоначального импорта ИБ "на замке" или подключенной к хранилищу я Вам настоятельно рекомендую запаковать содержимое каталога %3 (см описание выше) и положить в укромное местечко. Как только появится унылое окно, они вас спасут :)

  Однако, вернёмся к насильственным методам убеждения EDT, что проект, лежащий в рабочей области точно соответствует конфигурации связанной с ним ИБ, если всё же конфигурация была изменена, в проект мы изменения импортировали, а обновлять ИБ не желаем или не можем.

  1. Получить из новой ИБ файл ConfigDumpInfo.xml . Сделать это можно следующим образом:
     1. По 14ю платформу включительно:
        %4\1cv8.exe" DESIGNER /AppAutoCheckMode /S %5 | /F %5 [/WA -] [/N %6] [/ConfigurationRepositoryF %7 [/ConfigurationRepositoryN %8] /DumpConfigToFiles %9 /Out %10
     2. Начиная с 15й платформы добавился ещё параметр:
        %4\1cv8.exe" DESIGNER /AppAutoCheckMode /S | /F %5 [/WA -] [/N %6] [/ConfigurationRepositoryF %7 [/ConfigurationRepositoryN %8] /DumpConfigToFiles %9 -configDumpInfoOnly /Out %10
     • %4 - Путь к выполнимому файлу 1С
     • %5 - путь к ИБ в виде сервер\ИБ для модификатора /S или путь в файловой ИБ если использован модификатор /F
     • %6 - пользователь ИБ
     • %7 - путь к репозиторию 1С, если ИБ подключена к нему
     • %8 - пользователь репозитория
     • %9 - каталог куда положить CofigDumpInfo
     • %10 - лог, посмотреть если что не так пошло
     1. Положить полученный ConfigDumpInfo.xml в служебный каталог эклипса
     2. Заменить файл store на ранее сохранённый.
     3. Запустить EDT и убедиться, что имплант прижился.

     Где ещё это может быть полезно?

     В групповой разработке. Ситуация, один разработчик начал работать над проблемой, но . Потребовалось быстро передать промежуточные результаты работы другому, который, естественно живёт в другом рабочем пространстве…

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

     
     

     Т.е. в этом случае наша последовательность действий следующая:

     1. Если у первого (передающего) разработчика ИБ синхронизирована с рабочей областью, то он все результаты работы коммитит в ветку исправления/фичи и отправляет в совместный репозиторий. И передаёт ИБ другому разработчику (преемнику технического долга :)
     2. Помимо этого, первый разработчик закрывает EDT, архивирует содержимое каталога %3 включая структуру и так же передаёт второму разработчику
     3. Второй разработчик извлекает ту ветку, где были остановлены работы создаёт локальную ветку и присоединяет к ней в редакторе проекта информационную базу.
     4. Дожидается окончания обновления вторичных данных в прогрессе после извлечения (чекаута), после чего гасит EDT, находит каталог с присоединённой ИБ %3 у себя (идентификатор у нег естественно другой) и заменяет его содержимое на то, что отдал первый разработчик.
     5. Запускает EDT и проверяет - зеленогалка в редакторе проекта должна быть и при запуске отладки сборки проекта производиться не будет. Возможна некоторая задержка на сверку ConfigDumpInfo из присоединённой ИБ с тем, что подсунули в служебный каталог Эклипса… Небольшая для ERP на не топовом оборудовании (Core i3, HDD, 8 Gb RAM) - около 5 минут, на топовом и того меньше… Но это будет в десятки раз быстрее, чем полная сборка…

     Вот собственно и всё, для многих, кто только начал работать с EDT это покажется китайской грамотой, но я очень надеюсь, что, в итоге, мои инструкции помогут вам сэкономить то, что невозможно вернуть - время.

     1С:ГитКонвертер

     Конфигурация предназначена для односторонней синхронизации хранилища конфигурации "1С:Предприятия" с репозиторием Git и последующим переходом на разработку в 1C:Enterprise Development Tools (1C:EDT) с сохранением истории.

     Основные возможности

     • Конвертирование существующего хранилища конфигурации "1С:Предприятия" в репозиторий Git в формате 1C:EDT .
     • Обновлять изменения из хранилища "1С:Предприятия" в репозиторий Git.
     • Параллелизировать загрузку истории хранилища из копий хранилища.
     • Ограничение нагрузки на сервер с помощью очередей.
     • Возможно "сращивать" историю в Git, если хранилище конфигураций "1С:Предприятия" обрезалось или начиналось заново.
     • Создание корректной истории переименования объектов метаданных (см. Как это работает).

     Выгружать только изменения конфигурации.

     Доступно для Платформы 8.3.10 и выше, для версий ниже 8.3.15 требуется использовать "очереди".

     Поддержка конвертации хранилищ расширений конфигураций. Возможность связи с базовым проектом 1С:ГитКонвертера или независимо.

     Необходимые компоненты

     • Конфигурацию можно запустить, используя 1C:Enterprise Development Tools 2020.6 (https://releases.1c.ru/project/DevelopmentTools10)
     • Платформа "1С:Предприятие" версии 8.3.12 и выше (https://releases.1c.ru/project/Platform83)
     • СУБД, поддерживаемая "1С:Предприятием"
     • OS Windows 7 или выше, ОС Linux и macOS - в бета-режиме.

     Начальная настройка

     Настройка базы ГитКонвертера

     Настройка сервера "1С:Предприятия"

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

     Для легкого удаления и архивирования журнала регистрации можно переключить его формат на старый режим. Для этого необходимо в каталог журнала регистрации информационной базы скопировать пустой файл с именем: 1Cv8.lgf .
     Для больших проектов рекомендуется выполнить такую настройку (удаление/резервное копирование файлов журнала регистрации).

     Также рекомендуется переключить регистрацию событий - только ошибки. Для этого следует выбрать команду в Конфигураторе Администрирование - Настройка журнала регистрации. = Регистрировать ошибки и в открывшемся диалоге установить минимально необходимую вам периодичность.

     Настройка конвертации хранилища "1С:Предприятия"

     Рекомендуется использовать сервер хранилищ конфигураций "1С:Предприятия".

     Для оптимальной работы сервера хранилищ настройте Размер глобального кэша в "Администрировании" в 1,5-2 раза больше количества параллельных потоков (если используются "копии хранилища") получения версий * размер одной версии, Мб .

     Параметры конвертации

     Дополнительная настройка репозитория Git

     По умолчанию создается файл исключений .gitignore , в который добавляются файлы DumpFilesIndex.txt и ConfigDumpInfo.xml - не требуемые для работы с исходными файлами конфигурации "1С:Предприятия".

     Если репозиторий был создан с помощью кнопки в карточке хранилища, в локальный конфиг репозитория добавляются настройки для более комфортной работы:

     
     Символы окончания строк

     Если разработчики, работающие с репозиторием, используют разные операционные системы (Microsoft Windows, Linux, macOS), нужно настроить конвертацию символов окончания строк при чтении из репозитория. Следующие команды настраивают Git таким образом, что в рабочей копии разработчика будут использоваться "родные" для его операционной системы символы, а в репозитории всегда будет использоваться LF.

     Для операционной системы Microsoft Windows:

     git config --global core.autocrlf true
     git config --global core.safecrlf true

     Для операционных систем Linux и macOS:

     git config --global core.autocrlf input
     git config --global core.safecrlf true

     Git LFS

     Если используется сервер репозиториев Git, необходимо убедиться, что он поддерживает это расширение и включить настройки для проекта. Например, GitLab, GitHub, BitBucket - поддерживают.

     Выполнить начальную настройку репозитория до выполнения первого коммита:

     git lfs install

     Включить отслеживание бинарных файлов конфигурации:

     git lfs track "*.cf"
     git lfs track "*.bin"
     git lfs track "*.jpg"
     git lfs track "*.jpg"
     git lfs track "*.bmp"
     git lfs track "*.jpg"
     git lfs track "*.zip"

     В этом примере - все файлы конфигураций поставщиков, файлы макетов с "Двоичными данными" и картинки из конфигурации попадут в lfs.

     Например, чтобы переносить в LFS только некоторые типы файлов с расширением "*.bin" можно включить отслеживание только шаблонов и модулей без исходного кода по маске:

     git lfs track "*/Ext/Template.bin"
     git lfs track "*/Ext/Module.bin"

     Копии хранилища

     Копии хранилища используются для ускорения получения версий из хранилища.

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

     Укажите другой адрес архивной копии хранилища, если в текущем хранилище конфигураций выполнялось сокращение версий, и установите ограничение номеров версий в этой копии.

     Укажите расписание получения версий из этой копии. Если в "копии" указан адрес основного хранилища, необходимо в расписании учесть возможность работы разработчиков с хранилищем - запуски на получение выполнять с промежутками, обеспечивающими комфортную работу разработчиков.

     Очереди выполнения

     Если включена константа "Использовать очереди выполнения", то для каждого хранилища конфигураций необходимо указать 2 очереди:

     • Выгрузка метаданных . Начиная с версии Платформы версии 8.3.10 возможно использовать выгрузку изменений - для этого необходимо выгружать версии строго последовательно и не рекомендуется создавать более одной очереди на выгрузку.
     • Загрузка метаданных .

     Можно указать диапазоны количества версий для каждой очереди для разграничения "рабочей зоны".

     Укажите ограничение количества версий обрабатываемых очередью за один запуск и расписание запусков.

     Очередь может быть общей на всю базу или привязанной к конкретному хранилищу. Для очереди общего типа выбор версий для обработки выполняется по дате версии - это следует учитывать при конвертации проектов с длинной историей и более "молодых" проектов в одной базе ГитКонвертера.

     Информация пользователей

     Хранилище конфигураций "1С:Предприятия" использует для идентификации Пользователя , а в репозитории Git основным идентификатором является email и имя пользователя. Для этих целей предназначен регистр сведений Информация пользователей , позволяющий указать соответствие пользователей хранилищ пользователям репозитория Git.

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

     Пользователи могут быть указаны общие для всех хранилищ или с уточнением по хранилищам.

     Обновление с версии 1.0.4

     Внимание! Конвертация хранилища 1С в формат выгрузки xml 1С:Предприятия является устаревшей функциональностью и не доступна для новых настроек конвертации хранилища. Текущие настройки синхронизации хранилища, конвертирующие в формат выгрузки xml 1С:Предприятия будут работать корректно, но рекомендуется выполнить разовую конвертацию в формат 1C:EDT (см. тут) и продолжить синхронизацию в этом формате.

     Функциональность конвертирования в формат xml 1С:Предприятия будет удалена в 1.0.6 .

     Если что-то пошло не так (FAQ)

     Расписание конвертации включено, но список версий пуст

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

     Версии в списке ИБ 1С:ГитКонвертера есть, но конкретная версия зависла (зациклилась) на этапе выгрузки конфигурации в xml

     • Можно посмотреть в лог пакетной операции для этой версии /каталог выгрузки версий/ХХХ/log.txt - пакетная операция Конфигуратора может сообщить что-то полезное.
     • Если база версии "развалилась" в контекстном меню формы списка версий сбросить состояние версии - она будет получена заново из хранилища.

     Версии обрабатываются, но не коммитятся в Git

     Коммиты не появляются на сервере Git

     • Адрес Git-сервера был добавлен после создания хранилища? Нужно нажать кнопку "Установить адрес репозитория Git" чтобы настройки появились в config-файле.
     • Откройте гит-клиент - проверьте, есть ли коммиты в локальном репозитории.
     • Посмотрите лог коммита на Git-сервер, расположенные /каталог выгрузки версий/gi_log_ver_XXX.txt.
     • Выполните команду git push -u origin <branch name> в консоли, чтобы проверить push вручную.
     • Проверьте права доступа для пользователя, от имени которого запущен сервер "1С:Предприятия" - от его имени выполняется запуск скриптов *.bat/*.sh и глобальные настройки Git для этого пользователя.

     В какой-то версии произошел сбой и файлы версии закоммичены не полностью

     Т.е. в этой версии часть файлов или все были сначала удалены в репозитории, а следующая версия добавила файлы заново - сквозная история была потеряна:

     • Можно установить контроль минимального количества файлов в выгрузке, чтобы такого не случалось в будущем.
     • Т.к. это "односторонняя синхронизация" - то можно беспрепятственно откатить изменения git reset --hard <commit> на версию, до проблемной.
       • Далее в карточке хранилища установить поле "Версия в Git" на текущую в Git.
       • Для всех версий, начиная с "проблемной" и последующих, выполнить команду в контекстном меню "Сбросить состояние".
       • В каталоге src удалить файлы DumpFilesIndex.txt и ConfigDumpInfo.xml, т.к. они не хранятся в репозитории и не откатились.
       • Проверить что командные файлы *.bat (или *.sh ) удалены для всех версий, начиная с проблемной.
       • Если была установлена настройка Git-сервера, необходимо на сервере отключить защиту ветки (если есть такое) и выполнить git push -u -f origin <branch name> принудительную передачу данных с заменой репозитория на сервере.

       В хранилище версия есть, а в Git она пропущена

       • Хранилище конфигураций "1С:Предприятия" позволяет сохранять новую версию без фактического изменения содержимого файлов, если меняется внутренняя версия объекта метаданных. Для Git в этом случае нечего коммитить.
       • Откройте файлы логов и убедитесь в том, что версия была обработана корректно.

       Файл конфигурации GitConverter находится в каталоге \1CITS\EXE\GitConverter

       После перехода на новую платформу поменялась (появилась) проверка на дублирование внутренних идентификаторов объектов метаданных. Возможная ошибка при обновлении "Для одного ссылочного кода существует более одной таблицы в базе данных". Лечится изменением идентификатора объекта метаданных.

       Отказ от ответственности: автор не несет ответственность за использование приведенного алгоритма действий

       Для изменения UUID объекта

       Специальные предложения

       
       

       
       

       
       

       
       

       
       

       
       

       
       

       Чем же решение по ссылке корректней (правильней) ?

       (2) В данном решение предложено поменять UUID на произвольный . Не на правильный (которого -то и нет, т.к. проблема не в UUID), а на какой-то там любой.
       Тем более сомнительна рекомендация "В файле "ConfigDumpInfo" UUID объекта можно не менять.". Т.е. в одном месте конфигурации у документа будет один идентификатор, а в другом - другой. На мой взгляд так получаем битую конфигурацию. То, что метод сработал на одной базе скорее всего является следствием лишь того, что в ней указанный документ не использовался.

       В указанной ссылке приведены несколько решений, как сложных (с заменой номеров объектов), так и простых и 100% безопасных (временное добавление объекту реквизита).

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

       В процессе обновления информационной базы произошла критическая ошибка
       по причине:
       Ошибка SDBL:
       Ошибка обновления конфигурации базы данных. Для одного ссылочного кода существует более одной таблицы в базе данных.

       Имена таблиц с кодом 1: CKinds1, CKindsDN605
       Имена таблиц с кодом 2: CKinds2, CKindsDN639
       Для исправления проблемы вы можете обратиться в службу технической поддержки.

       Реструктуризацию провести не смог, вываливается. База большая, около 500Г. Возможно из-за этого.

       CKinds - это план видов расчета. Какой именно я не стал определять (можете поиграться со структурой, кому интересно). Я просто добавил КАЖДОМУ из плана видов расчета (у меня их всего 6) новый реквизит и ошибка исчезла. Затем Все эти реквизиты убрал за ненадобностью.

       Читайте также:

         
       • Как подать объявление на юле бесплатно с компьютера
         
       • Не удалось получить данные с сервера возможно антивирус или блокировщик рекламы мешает zona
         
       • Подготовка файлов к установке steam долго
         
       • Создать правило dr web
         
       • Управление фифа 20 ps4