Файл configdumpinfo xml не найден в директории выгрузки xml файлов
Мы продолжаем развивать механизм выгрузки / загрузки конфигурации в файлы XML. Некоторое время назад мы уже рассказывали о том, что реализовали частичную загрузку конфигурации. Теперь мы реализовали обратную операцию – частичную (инкрементальную) выгрузку конфигурации.
В результате этих двух изменений групповая разработка больших конфигураций должна стать легче и быстрее.
Частичная загрузка конфигурации из файлов XML
Мы реализовали возможность загружать из файлов XML не всю конфигурацию, а только её часть. В первую очередь эта возможность востребована в новой среде разработки 1C:Enterprise Development Tools. Ведь Development Tools ориентированы на работу с крупными конфигурациями, а частичная загрузка помогает ускорить процесс разработки, сократить цикл «редактирование - отладка».
Однако вы можете использовать эту возможность и независимо от Development Tools. Потому что для загрузки отдельных файлов конфигурации используется запуск конфигуратора из командной строки в пакетном режиме. А значит, используя частичную загрузку, вы можете:
- изменять свойства конфигурации,
- добавлять, изменять и удалять объекты конфигурации,
- загружать только некоторые свойства объектов конфигурации без загрузки самих объектов. Например, модули объектов, формы, модули форм, роли и так далее.
Мы сразу хотим обратить ваше внимание на то, что мы реализовали только частичную загрузку, и только из командной строки. Частичной выгрузки нет так же, как нет интерактивных команд конфигуратора, позволяющих загружать часть конфигурации.
Поэтому загрузить только модуль справочника Номенклатура вы можете, например, следующей командой:
"C:\Program Files (x86)\1cv8\8.3.7.1759\bin\1cv8.exe" DESIGNER /IBName "TestBase" /LoadConfigFromFiles "C:\dump" -Files "C:\dump\Catalogs\Номенклатура\Ext\ObjectModule.bsl"
Для частичной загрузки используется прежний параметр LoadConfigFromFiles, и две новых опции: Files и ListFiles. Files позволяет вам перечислить через запятую те файлы, которые нужно загрузить, если таких файлов немного. А если их много, тогда вы можете использовать опцию ListFiles. Она указывает на файл, в котором перечислены XML файлы, которые нужно загрузить.
Кроме этого, для повышения удобства работы, мы разрешили совместное использование в одной строке параметров LoadConfigFromFiles и UpdateDBCfg. Таким образом, теперь за один вызов вы можете загрузить изменения и принять их (обновить конфигурацию базы данных).
Получение «патча» для конфигурации
И, наконец, последний сценарий использования частичной выгрузки конфигурации в файлы XML позволяет создавать своеобразные «патчи» из XML файлов конфигурации.
Например, есть конфигурация, которая хранится и распространяется в виде XML выгрузки. Известно, что эта конфигурация изменяется мало. В некоторый момент в конфигурации были выявлены ошибки.
Тогда прежде, чем исправлять ошибки, вы фиксируете (сохраняете) XML выгрузку, соответствующую этому состоянию конфигурации, как эталонную. После этого исправляете ошибки, и выгружаете только изменения, относящиеся к исправлению ошибок. Например, такой командой:
Здесь C:\xml_source\ConfigDumpInfo.xml это файл версий эталонной конфигурации, а C:\xml_patch – каталог, в который будут выгружены только те XML файлы, которые исправляют обнаруженные ошибки.
configDumpInfoForChanges это новый ключ, который позволяет указать конкретный файл версий, от которого нужно «отсчитывать» изменения.
Если же вы хотите не только выгрузить файлы, но и получить список измененных объектов, содержащихся в вашем «патче», то нужно выполнить такую команду:
Тогда информация об изменениях будет записана в файл C:\diff.txt.
The text was updated successfully, but these errors were encountered:
Автоматическая модификация или контроль конфигурации
Существует целый ряд задач, когда выгрузка конфигурации в файлы XML используется для автоматической проверки конфигурации или для выполнения «регламентных» действий, не связанных с прикладной логикой. Это может быть, например, автоматизированная проверка конфигурации на соответствие стандартам разработки, принятым в компании. Или автоматическая модификация ролей для новых объектов.
Общим в этих задачах является то, что конфигурацию предварительно нужно выгрузить в файлы XML. А иногда ещё и загрузить обратно. И тут, конечно, инкрементальная выгрузка конфигурации позволит сэкономить значительное количество времени в цепочке выгрузка – обработка – загрузка.
khorevaa commented Nov 2, 2020
Я не возражаю! Жду ПР )
Выгрузка/загрузка внешних отчётов и обработок в/из XML
В версии 8.3.8 мы добавили возможность выгружать в XML и загружать внешние отчёты и обработки:
Более того, при работе в конфигураторе вы можете сохранять их сразу в формате XML (Файл - Сохранить как. ). То же самое относится и к открытию:
Также мы добавили возможность сравнить внешний отчёт или обработку с XML выгрузкой. Все эти изменения мы сделали в первую очередь для того, чтобы в новой среде разработки 1C:Enterprise Development Tools обеспечить полноценную работу с внешними отчётами и обработками. Однако и отдельно от Development Tools эти возможности могут быть вам полезны для любых автоматизированных изменений выгруженных XML файлов.
Выгрузить/загрузить внешние отчёты/обработки вы можете не только интерактивно, но и автоматически, запуская конфигуратор в пакетном режиме. Для этого мы добавили два новых параметра: DumpExternalDataProcessorOrReportToFiles и LoadExternalDataProcessorOrReportFromFiles.
при редактировании справки 1С при добавлении ссылки на объект в текст добавляется GUID объекта (справка которого потом открывается по ссылке).
Подскажите, можно ли как-нибудь получить ссылку на этот объект или метаданные этого объекта, зная этот GUID?
Это повтор темы отсюда , решение не найдено, а тема актуальна.
(3) Более простых способов не знаю, но можно выгрузить конфигурацию в файлы и там есть идентификаторы объектов конфигурации, см. картинку:
А вот в файле ConfigDumpInfo.xml что лежит в корне папки в которую вы сделали выгрузку конфигурации, вообще все ID лежат, в том числе форм. Так же вам возможно стоит посмотреть в сторону EDT.
(2) программно определить битые ссылки в справке. Чтобы это сделать, нужно программно сравнить ссылку из справки
с ссылкой на реальный объект метаданных конфигурации.
(4) Ему надо проверить ссылки в справке, а не саму конфигурацию. Тест конфигурации не делает тест ссылок в справке.
(3) Более простых способов не знаю, но можно выгрузить конфигурацию в файлы и там есть идентификаторы объектов конфигурации, см. картинку:
А вот в файле ConfigDumpInfo.xml что лежит в корне папки в которую вы сделали выгрузку конфигурации, вообще все ID лежат, в том числе форм. Так же вам возможно стоит посмотреть в сторону EDT.
А вот в файле ConfigDumpInfo.xml что лежит в корне папки в которую вы сделали выгрузку конфигурации, вообще все ID лежат, в том числе форм. Так же вам возможно стоит посмотреть в сторону EDT.
Да, это решение вопроса. Спасибо!
Ссылки в справочной информации и есть уникальные идентификаторы объектов, которые можно получить либо читая выгрузку в файлы, либо обращением к таблицам в СУБД напрямую. Надо будет написать какую-то функцию, которая решит эту задачу и можно будет проверить битые ссылки или нет.
Немного о работе механизма синхронизации информационной базы с проектом EDT и как эти знания можно использовать для экономии времени. Или как объяснить, что проект в рабочей области эквивалентен конфигурации информационной базы, связанной с ним.
может вывести из себя, в особенности если вы чётко осознаёте бессмысленность потраченного времени на неё.
В большинстве случаев EDT корректно обрабатывает изменения, сделанные в конфигураторе и предлагает их импортировать в проект частично, но за этим всегда следует, повторная сборка проекта и обновление связанной с проектом информационной базы.
В случае, приведённом выше операция, если проект класса ERP, даже на топовом оборудовании (Core i7, SSD, >16Gb RAM) может отнять около полутора часов на полную пересборку, причём она не пройдёт полностью автоматически: после длительного импорта и конвертации в формат EDT, чтобы добиться желаемой синхронности:
нужно будет обновить конфигурацию ИБ и это будет тоже полная сборка.
Если говорить более конкретно, то моя патовая ситуация была такова, что я в EDT разрабатывал расширение для конфигурации ERP, а сама конфигурация была подключена к хранилищу 1С и была на железном, для меня, замке от того, что моя УЗ в репозитории 1С была только на чтение… Т.е. импорт то я бы сделал, но обновить конфигурацию ИБ не смог бы по определению, соответственно так как по отношению к проекту расширения основной проект не синхронизирован, сборка обновления расширения производится не будет…
Надо отметить, что злая штука здесь в том, что несмотря на то, что захват объектов в хранилище не произведён, объекты метаданных (в отличии, когда импортирована конфигурация, к примеру, на поддержке с запретом изменений) лихо редактируются в EDT и "сюрприз" может поджидать совсем неожиданно, когда нужно будет запустить отладку… Тут небольшой совет: даже если вы не собираетесь ничего изменять в основном проекте - сделайте его совместным и сделайте один коммит всего проекта в вашем локальном репо - вы всегда сможете откатить "случайные" или не очень изменения.
- Открыл конфигуратор
- Получил изменения из хранилища, в котором было добавление предопределённого элемента в справочнике и два переименования других предопределённых элементов
- Обновил конфигурацию ИБ
- Закрыл конфигуратор
- В списке ИБ, для этой ИБ выбрал "Импортировать конфигурацию" и нажал в диалоговом окне кнопку обновить.
Что далее?
Далее всё. Выходом из этой ситуации поможет знание как устроен механизм синхронизации проекта 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, что проект, лежащий в рабочей области точно соответствует конфигурации связанной с ним ИБ, если всё же конфигурация была изменена, в проект мы изменения импортировали, а обновлять ИБ не желаем или не можем.
- Получить из новой ИБ файл ConfigDumpInfo.xml . Сделать это можно следующим образом:
- По 14ю платформу включительно:
%4\1cv8.exe" DESIGNER /AppAutoCheckMode /S %5 | /F %5 [/WA -] [/N %6] [/ConfigurationRepositoryF %7 [/ConfigurationRepositoryN %8] /DumpConfigToFiles %9 /Out %10 - Начиная с 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 - лог, посмотреть если что не так пошло
- Положить полученный ConfigDumpInfo.xml в служебный каталог эклипса
- Заменить файл store на ранее сохранённый.
- Запустить EDT и убедиться, что имплант прижился.
Где ещё это может быть полезно?
В групповой разработке. Ситуация, один разработчик начал работать над проблемой, но . Потребовалось быстро передать промежуточные результаты работы другому, который, естественно живёт в другом рабочем пространстве…
Надо отметить, что для проекта в групповой разработке местонахождения файлов синхронизации отлично:
Т.е. в этом случае наша последовательность действий следующая:
- Если у первого (передающего) разработчика ИБ синхронизирована с рабочей областью, то он все результаты работы коммитит в ветку исправления/фичи и отправляет в совместный репозиторий. И передаёт ИБ другому разработчику (преемнику технического долга :)
- Помимо этого, первый разработчик закрывает EDT, архивирует содержимое каталога %3 включая структуру и так же передаёт второму разработчику
- Второй разработчик извлекает ту ветку, где были остановлены работы создаёт локальную ветку и присоединяет к ней в редакторе проекта информационную базу.
- Дожидается окончания обновления вторичных данных в прогрессе после извлечения (чекаута), после чего гасит EDT, находит каталог с присоединённой ИБ %3 у себя (идентификатор у нег естественно другой) и заменяет его содержимое на то, что отдал первый разработчик.
- Запускает EDT и проверяет - зеленогалка в редакторе проекта должна быть и при запуске отладки сборки проекта производиться не будет. Возможна некоторая задержка на сверку ConfigDumpInfo из присоединённой ИБ с тем, что подсунули в служебный каталог Эклипса… Небольшая для ERP на не топовом оборудовании (Core i3, HDD, 8 Gb RAM) - около 5 минут, на топовом и того меньше… Но это будет в десятки раз быстрее, чем полная сборка…
Вот собственно и всё, для многих, кто только начал работать с EDT это покажется китайской грамотой, но я очень надеюсь, что, в итоге, мои инструкции помогут вам сэкономить то, что невозможно вернуть - время.
Автоматическое обновление XML выгрузки
Это вариация предыдущего сценария, когда изменения, выполненные вами за день, автоматически сохраняются в XML выгрузке. Тут вам понадобится написать скрипт, который запускается после окончания рабочего дня, и выполняет, например, такую команду:
В результате в каталог выгрузки (C:\xml) будут сохранены только те изменения (-update), которые сделаны с момента предыдущей выгрузки, то есть в течение дня.
update это новый ключ, который позволяет обновить выгрузку, то есть выгрузить только те файлы, версии которых отличается от версий в каталоге выгрузки.
yukon39 commented Nov 2, 2020
Так подразобрался, с помощью @marmyshev. Одним ConfigDumpInfo.xml не отделаться - надо, чтобы плагин инкремента дополнял список объектов к выгрузке "обязательными" объектами, например, Языками.
Если добавить это функционал к плагину инкремента, то на больших проектах можно значительно ускорить этап конвертации. В ГК это реализовано в функции КонвертацияХранилища.ПолучитьСписокОбъектовДовыгрузки
Изменение логики выгрузки
Главное изменение заключается в том, что при выгрузке конфигурации в файлы XML теперь формируется (или обновляется) специальный служебный файл ConfigDumpInfo.xml, который называется файлом версий. Он хранится в каталоге выгрузки вместе с остальными файлами XML, и содержит информацию о формате выгрузки, о версии выгрузки, и о версиях всех объектов, которые были выгружены.
Таким образом теперь, проанализировав этот файл, платформа точно знает, какие версии каких объектов содержатся в выгрузке. На основании этой информации она выгружает только те объекты, которые были изменены по отношению к уже выгруженным.
На практике это выглядит следующим образом.
Если выгрузка выполняется в первый раз (или если в каталоге выгрузки отсутствует файл версий), то выполняется полная выгрузка, генерируется файл версий.
Если в каталоге выгрузки уже есть файл версий, то выгружаются только изменения конфигурации по отношению к файлу версий, файл версий обновляется.
В качестве примера фрагмент файла версий может выглядеть следующим образом:
Работа с системами контроля версий
- Получить обновления (Update) выгрузки конфигурации из системы контроля версий (если они есть);
- Выгрузить измененные объекты из локальной информационной базы, например, такой командой:
- Зафиксировать изменения (Commit) выгрузки конфигурации в системе контроля версий.
После этого другие разработчики смогут обновить (Update) свои копии XML выгрузки конфигурации.
Оптимизация работы 1C:Enterprise Development Tools
Эта возможность не требует от вас каких-либо усилий, потому что реализуется на уровне платформы. Конечно же, инкрементальную выгрузку в файлы XML мы, прежде всего, задействуем в новой среде разработки. Это должно ускорить работу с большими конфигурациями, на которые эта среда и рассчитана. Благодаря тому, что теперь есть возможность выгружать только изменённые объекты, должны ускориться операции получения изменений из информационной базы.
Сценарии использования
Интересным моментом является то, что частичная выгрузка конфигурации в файлы XML предоставляет вам сразу несколько новых возможностей, которые отсутствовали ранее, или были сложны в реализации.
yukon39 commented Nov 2, 2020 •
@sfaqer Похоже не надо - edt import уже может работать с частичной выгрузкой. Надо только дополнить список объектов для платформенной выгрузки. Между сессиями сохранять кроме самого проекта ничего не нужно.
В папке проекта останется ConfigDumpInfo.xml - коммитить его в репу или нет уже другой вопрос.
В общем виде так:
- Полная выгрузка - как сейчас
- Инкрементная:
2.1. дополняем список объектов к выгрузке (increment)
2.2. выгружаем (increment)
2.3. конвертируем (edtExport)
2.4. копируем результат конвертации в папку проекта (поверх уже существующих файлов) (edtExport/increment ?)
Я собственно споткнулся на п. 2.3 - вываливалась ошибка, т.к. не был выполнен п. 2.1.
У меня основной режим запуска "по одному коммиту", т.к. хранилища уже сконвертированы, и сейчас в них добавляются новые коммиты по текущим изменениям.
Для выгрузки конфигурации в XML мы добавили новый формат, - Иерархический. Теперь это стандартный формат, который предлагает платформа. Чтобы выгрузить файлы в прежнем формате, нужно это указать в явном виде:
В отличие от старого формата, линейного, в котором полное имя объекта конфигурации содержалось в имени результирующего файла .
. новый формат выгрузки, иерархический, формирует структуру каталогов с файлами:
Иерархическая выгрузка позволяет избавиться от проблем, связанных с очень длинными именами файлов. Такие проблемы могли возникать раньше как при выгрузке, так и при переносе файлов между разными файловыми системами (FAT, NTFS, EXT).
Сам по себе иерархический формат выгрузки не гарантирует того, что в выгрузке не появится очень длинных имён, или очень длинных путей. Поэтому мы ввели ряд ограничений и рекомендаций. Например, в конфигураторе нельзя создавать имена объектов длиннее 80 символов, не рекомендуется использовать подсистемы большой вложенности, каталог выгрузки следует располагать как можно ближе к корню устройства и так далее.
Вы можете управлять форматом выгрузки при запуске конфигуратора в пакетном режиме. Для этого прежнему параметру DumpConfigToFiles мы добавили новую опцию Format. Если вы хотите выгрузить в старом, линейном формате, это нужно указать в явном виде:
"C:\Program Files (x86)\1cv8\8.3.7.1759\bin\1cv8.exe" DESIGNER /IBName "TestBase" /DumpConfigToFiles "C:\dump" -Format Plain
Без указания этой опции выгрузка выполняется в иерархическом формате. А при загрузке формат определяется автоматически, и никаких дополнительных опций не требуется.
sfaqer commented Nov 2, 2020
@yukon39 тут надо определить ответственность, все таки это нектороый "стык" между инкрементом и едт экспортом.
Вероятно если там все сильно замудренно то надо всю функциональность в edt export выносить, правда если нужно хранить состояния прошлой выгрузки, то это ещё и выгрузку конфигуратора надо в реп пихать, что не айс, можно подумать в сторону инкреиентов в рамках одной операции sync, типа каждый новый запуск как с чистого листа, но если грузим 500 версий скопом то инкременткльно. Что скажешь?Контроль изменений в конфигурации
Этот сценарий удобен в том случае, когда над одной конфигурацией работают сразу несколько разработчиков. При этом имеется XML выгрузка, которая является эталонным состоянием конфигурации. Задача состоит в том, чтобы при каждом изменении конфигурации сохранять информацию о том, что изменилось. В этом случае разработчик может выполнить, например, такую команду:
В результате будет сформирован файл (C:\diff.txt), содержащий изменения конфигурации (-getChanges) относительно эталонной выгрузки(C:\xml). Если изменений нет, то файл diff.txt будет пустым.
getChanges это новый ключ, который позволяет вывести в указанный далее файл изменения текущей конфигурации относительно той выгрузки, каталог которой указан перед этим ключом.
Интерактивная выгрузка
Этот сценарий позволяет вам в процессе разработки периодически сохранять конфигурацию в виде файлов XML. Раньше для больших конфигураций этот сценарий был практически неприемлем, потому что каждый раз выгружалась вся конфигурация. А это могло занимать много времени.
Теперь же полная выгрузка конфигурации потребуется вам только в первый раз. Дальше вы модифицируете конфигурацию и в некоторый момент просто вызываете диалог выгрузки, указываете каталог, и нажимаете ОК. В результате будут выгружены только те изменения, которые вы произвели в конфигурации с прошлой выгрузки в XML.
Читайте также:
- По 14ю платформу включительно: