Ни для кого не секрет, что при разработке в EDT больше всего раздражают незапланированные длительные операции, и очень часто появление сообщения (назовём его "печальным") вида:
может вывести из себя, в особенности если вы чётко осознаёте бессмысленность потраченного времени на неё.
Первопричины появления такого сообщения могут быть разные, но как результат его изменённая, по отношению к связанному с проектом EDT конфигурация, непосредственно в конфигураторе.
В большинстве случаев EDT корректно обрабатывает изменения, сделанные в конфигураторе и предлагает их импортировать в проект частично, но за этим всегда следует, повторная сборка проекта и обновление связанной с проектом информационной базы.
В случае, приведённом выше операция, если проект класса ERP, даже на топовом оборудовании (Core i7, SSD, >16Gb RAM) может отнять около полутора часов на полную пересборку, причём она не пройдёт полностью автоматически: после длительного импорта и конвертации в формат EDT, чтобы добиться желаемой синхронности:
нужно будет обновить конфигурацию ИБ и это будет тоже полная сборка.
Если говорить более конкретно, то моя патовая ситуация была такова, что я в EDT разрабатывал расширение для конфигурации ERP, а сама конфигурация была подключена к хранилищу 1С и была на железном, для меня, замке от того, что моя УЗ в репозитории 1С была только на чтение… Т.е. импорт то я бы сделал, но обновить конфигурацию ИБ не смог бы по определению, соответственно так как по отношению к проекту расширения основной проект не синхронизирован, сборка обновления расширения производится не будет…
Надо отметить, что злая штука здесь в том, что несмотря на то, что захват объектов в хранилище не произведён, объекты метаданных (в отличии, когда импортирована конфигурация, к примеру, на поддержке с запретом изменений) лихо редактируются в EDT и "сюрприз" может поджидать совсем неожиданно, когда нужно будет запустить отладку… Тут небольшой совет: даже если вы не собираетесь ничего изменять в основном проекте - сделайте его совместным и сделайте один коммит всего проекта в вашем локальном репо - вы всегда сможете откатить "случайные" или не очень изменения.
Возвращаясь к моему примеру, что я сделал, чтобы получить "печальное" сообщение:
- Открыл конфигуратор
- Получил изменения из хранилища, в котором было добавление предопределённого элемента в справочнике и два переименования других предопределённых элементов
- Обновил конфигурацию ИБ
- Закрыл конфигуратор
- В списке ИБ, для этой ИБ выбрал "Импортировать конфигурацию" и нажал в диалоговом окне кнопку обновить.
Что далее?
Далее всё. Выходом из этой ситуации поможет знание как устроен механизм синхронизации проекта EDT с информационной базой.
За заветную зелёную галку отвечает файл без расширения store, размещённый в служебном каталоге проекта Eclips'a:
<%1>\.metadata\.plugins\org.eclipse.core.resources\.projects\<%2>\com._1c.g5.v8.dt.platform.services.core\.default\infobase-synchronization\%3\SynchronizationData.store
Где:
- %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
- По 14ю платформу включительно:
Где:
- %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 это покажется китайской грамотой, но я очень надеюсь, что, в итоге, мои инструкции помогут вам сэкономить то, что невозможно вернуть - время.
