Ошибка MSBuild Файл проекта msb1009 не существует

Обновлено: 21.11.2024

Впервые здесь? Ознакомьтесь с часто задаваемыми вопросами!

Попытка настроить собственную среду разработки. Я клонировал репозитории Wireshark на свой собственный сервер GitLab. Ближе к концу процесса сборки для Win64 я получаю следующую ошибку:

Я нашел этот старый пост с вопросами и ответами, но не знаю, как исправить процесс сборки.

Заранее спасибо!

1 ответ

Я подозреваю, что в вашей среде чего-то не хватает, и из-за этого не создается проект упаковки nsis.

Повторно запустите этап создания CMake и найдите отсутствующие (необязательные) элементы. В первую очередь на ум приходят сам nsis, установщик vc_redist и, возможно, инструменты сборки документации.

Если вы приложите результаты этапа генерации CMake, мы сможем что-то обнаружить.

Обратите внимание, что ваша командная строка msbuild отличается от указанной в разделе Руководства разработчика о создании установщика. Вы можете строить, как хотите, но отклонение от «единственного истинного пути» может привести к проблемам со сборкой, которые трудно отследить, потому что люди, которые пытаются вас поддержать, никогда не делают этих странных случайных вещей.

Полный надзор с моей стороны за пропуск установки NSIS. Я думаю, что увидел слово «необязательно» и просто хотел ускориться и начать создавать вещи. Я уже прошел эту часть процесса сборки.

Однако у меня возникла отдельная проблема с пакетом "wix". Он у меня установлен, но во время сборки я получаю эту ошибку:

Я сам не работаю с msi-пакетом WiX, поэтому у меня нет большого опыта работы с ним, и в выводе отсутствует часть документации, которая должна была быть создана ранее. Однако основной Wireshark GitLab CI создает его и в настоящее время доволен, поэтому я думаю, что это что-то в вашей среде. Из какой ветки вы строите?

Необязательно: создайте руководство пользователя и разработчика.
"Чтобы создать Руководство пользователя Wireshark и Руководство разработчика Wireshark, создайте цель all_guides, например, msbuild all_guides.vcxproj. Подробную информацию о создании этих руководств можно найти в файле docbook\README.adoc в исходниках Wireshark."

Я предположил, что @thehammer86 завершил сборку NSIS, и я не думал, что существуют разные требования к установщикам NSIS и WiX в отношении документации, возможно, они есть. Я никогда не собирал документы отдельно, только шаги cmake, build, xxx_package_prep и затем xxx_package.

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

Эрик Хемскерк

В Coolblue мы запускаем множество сборок и развертываний. Поскольку мы практикуем CD, все они запускаются автоматически. Это означает, что после слияния запроса на извлечение наш сервер сборки может потратить до получаса на сборку, тестирование, развертывание и проверку. Не знаю, как у вас, а у меня не хватает концентрации внимания, чтобы в течение получаса наблюдать за медленно продвигающимися полосами прогресса. Поэтому вместо этого, когда на одном из этапов сборки или развертывания происходит сбой, мы хотели бы получать об этом уведомление. Предпочтительно в Slack, нашей предпочтительной платформе обмена сообщениями, хотя эта статья может относиться к любому механизму. Конечно, большинство серверов сборки в настоящее время имеют интеграцию с большинством платформ обмена сообщениями, но что, если вы этого не сделали или не хотите полагаться на них?

Вам не нужно писать блоки try/catch повсюду, поэтому это должно быть что-то, что вы можете либо внедрить, либо просто запустить какой-то код после завершения сборки. Некоторые фреймворки сборки делают это очень просто. Для NUKE это так же просто, как переопределить метод OnBuildFinished.

Легко. Но как нам сделать это многоразовым? Мы не хотим, чтобы людям приходилось копировать и вставлять целые блоки кода. Было бы лучше, если бы его можно было просто «подключить».

Цели

В своей предыдущей статье я показал, как компоненты сборки NUKE упрощают сборку скрипта сборки, используя только те компоненты, которые вам нужны. Добавить новую цель в систему так же просто, как и связать ее с другими целями.

Поскольку мы хотим, чтобы наша цель выполнялась после завершения сборки, мы можем просто прикрепить ее к нашим «основным» целям, верно? Обратите внимание, что я упрощаю структуру типов для краткости.

К сожалению, все не так просто. Первым препятствием является обнаружение неудачной сборки. IsSuccessful не сработает, поскольку всегда возвращает false, так как сборка все еще выполняется. Вам нужно посмотреть ExecutingTargets, чтобы увидеть, не сработал ли какой-либо из них.

Однако есть гораздо более серьезная проблема.NUKE может выполнять цели в любом порядке, если только вы специально не указали ему выполнять конкретную цель до или после другой. Это означает, что если сам BuildRelease также запускает другую цель, он может в конечном итоге запуститься после NotifyFailureOnSlack. Если эта цель затем потерпит неудачу, она останется незамеченной. Это явно не правильное решение.

Атрибуты

Аспект NUKE, который вообще не задокументирован на официальном сайте, — это атрибуты расширения сборки. При настройке проекта NUKE вы заметите, что сгенерированный класс Build украшен множеством различных атрибутов.

Оказалось, что эти атрибуты являются производными от класса BuildExtensionAttributeBase, и что в NUKE есть код для распознавания атрибутов, которые наследуются от него, как расширения класса сборки. Существует также множество интерфейсов, которые представляют «события», такие как IOnBuildFinished, которые при реализации в вашей сборке или расширении сборки позволяют этому компоненту реагировать на события сборки. OnBuildFinished должно звучать знакомо. Давайте посмотрим, как это выглядит.

Сообщения об ошибках

Хотя это и работает, сообщение не очень полезно. Он не сообщает вам, в чем произошел сбой или в какой сборке он произошел. Давайте это исправим.

К сожалению, получить сообщения об ошибках от NUKE не так просто. Обычно вы делаете это (также) записывая сообщения журнала в регистратор в памяти, который позволяет вам просматривать сообщения, которые он захватил, на досуге. Однако не существует общедоступного метода или свойства, позволяющего это сделать; приемники журналов автоматически настраиваются NUKE с помощью внутреннего свойства.

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

Это должно дать нам относительно подробное описание того, что пошло не так.

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

Заключение

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

Вот настоящее уведомление (очевидно, отредактированное):

Создание многоразовых скриптов сборки с компонентами NUKE

Ленты событий: простая и надежная инфраструктура обмена сообщениями

Ленты событий – это простой механизм, позволяющий приложениям надежно, последовательно и быстро реагировать на события, происходящие в других приложениях.

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