Вывести в терминал набор аргументов для вызова указанного в консоли исполняемого файла

Обновлено: 21.11.2024

Caddy имеет стандартный unix-подобный интерфейс командной строки. Основное использование:

Укажите параметры, которые заменяются вашим вводом.

[Квадратные скобки] обозначают необязательные параметры.

Эллипсы . указывает продолжение, т. е. один или несколько параметров.

Быстрый старт: помощь кэдди

caddy адаптировать Адаптирует документ конфигурации к стандартному JSON

caddy build-info Выводит информацию о сборке

caddy environ Печать окружения

caddy file-server Простой, но готовый к работе файловый сервер

caddy fmt форматирует Caddyfile

caddy hash-password Хэширует пароль и выводит base64

caddy help Просмотреть справку по командам caddy

caddy list-modules Список установленных модулей Caddy

caddy reload Изменяет конфигурацию запущенного процесса Caddy

caddy run Запускает процесс Caddy на переднем плане

caddy start Запускает процесс Caddy в фоновом режиме

caddy stop Останавливает запущенный процесс Caddy

caddy trust Устанавливает сертификат в локальные хранилища доверия

caddy untrust Отменяет доверие к сертификату из локальных доверенных хранилищ

обновление Caddy Обновляет Caddy до последней версии

caddy add-package Обновляет Caddy до последней версии с добавлением дополнительных подключаемых модулей

caddy remove-package Обновляет Caddy до последней версии, удаляя некоторые подключаемые модули

caddy validate Проверяет правильность файла конфигурации

caddy version Распечатывает версию

Подкоманды

адаптация кэдди

Адаптирует конфигурацию к собственной структуре конфигурации JSON Caddy и записывает выходные данные в стандартный вывод вместе со всеми предупреждениями в стандартный вывод, а затем завершает работу.

--config — это путь к файлу конфигурации. Если опущено, предполагается, что Caddyfile находится в текущем каталоге, если он существует; в противном случае этот флаг обязателен.

--adapter указывает используемый адаптер конфигурации; по умолчанию — caddyfile .

--pretty отформатирует вывод с отступом для удобочитаемости.

--validate загрузит и подготовит адаптированную конфигурацию для проверки правильности (но на самом деле не запустит конфигурацию).

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

Попробуйте адаптировать его:

Выполняется без ошибок. Тогда попробуйте:

Несмотря на то, что этот Caddyfile может быть адаптирован к JSON без ошибок, фактические файлы сертификатов и/или ключей не существуют, поэтому проверка не выполняется, поскольку эта ошибка возникает на этапе подготовки. Таким образом, проверка является более надежной проверкой ошибок, чем адаптация.

Пример

Чтобы адаптировать Caddyfile к JSON, чтобы его можно было легко читать и настраивать вручную:

информация о сборке контейнера

Выводит предоставленную Go информацию о сборке (путь к основному модулю, версии пакетов, замены модулей).

окружающая среда

Распечатывает окружение так, как его видит кэдди, затем выходит. Может быть полезно при отладке систем инициализации или модулей управления процессами, таких как systemd.

файл-сервер caddy

Запускает простой, но готовый к работе статический файловый сервер.

--root указывает путь к корневому файлу. По умолчанию используется текущий рабочий каталог.

--listen принимает адрес слушателя. По умолчанию :80 , если не используется --domain , то по умолчанию будет :443.

--browse активирует списки каталогов, если запрашивается каталог без индексного файла.

--templates активирует отображение шаблонов.

--access-log включает журнал запросов/доступа.

Эта команда отключает API администрирования, упрощая запуск нескольких экземпляров на локальном компьютере для разработки.

Кадди ФМТ

Форматирует или украшает Caddyfile, затем завершает работу. Результат выводится на стандартный вывод, если не используется --overwrite.

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

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

хеш-пароль caddy

Хэширует пароль и записывает вывод в стандартный вывод в кодировке base64, а затем завершает работу.

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

--алгоритм может быть bcrypt или scrypt. По умолчанию используется bcrypt.

--salt используется только в том случае, если алгоритму требуется внешняя соль (например, scrypt).

помощь кэдди

Распечатывает текст справки CLI, при необходимости для определенной подкоманды, а затем завершает работу.

модули списка caddy

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

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

ПРИМЕЧАНИЕ. Из-за ошибки в Go информация о версии доступна только в том случае, если Caddy собран как зависимость, а не как основной модуль. Используйте xcaddy, чтобы упростить эту задачу.

Перезагрузка кэдди

Передает работающему экземпляру Caddy новую конфигурацию. Это имеет тот же эффект, что и отправка документа в конечную точку /load, но эта команда удобна для простых рабочих процессов, связанных с файлами конфигурации. По сравнению с командами stop , start и run эта единственная команда является правильным семантическим способом изменить/перезагрузить текущую конфигурацию.

Поскольку эта команда использует API, нельзя отключать конечную точку администратора.

--config — это применяемый файл конфигурации. Если - , конфиг читается со стандартного ввода. Если не указано, он попробует файл с именем Caddyfile в текущем рабочем каталоге и, если он существует, адаптирует его с помощью адаптера конфигурации caddyfile; в противном случае возникает ошибка, если нет файла конфигурации для загрузки.

--adapter указывает используемый адаптер конфигурации, если таковой имеется.

--address необходимо использовать, если конечная точка администратора не прослушивает адрес по умолчанию и если он отличается от адреса в предоставленном файле конфигурации. Обратите внимание, что в настоящее время поддерживаются только адреса TCP.

--force вызовет перезагрузку, даже если указанная конфигурация совпадает с той, что уже запущена Caddy. Может быть полезно заставить Caddy повторно инициализировать свои модули, что может иметь побочные эффекты, например: повторная загрузка сертификатов TLS, загруженных вручную.

обратный прокси-сервер caddy

--from — адрес для прокси.

--to — это адрес для прокси.

--change-host-header заставит Caddy изменить заголовок Host с входящего значения на адрес восходящего потока.

Параметры --from и --to могут быть URL-адресами, поскольку схема и имя домена будут выводиться из предоставленного URL-адреса (пути и строки запроса игнорируются). Или это может быть простой сетевой адрес, а не полный URL.

Эта команда отключает API администрирования, чтобы упростить запуск нескольких экземпляров на локальном компьютере для разработки.

бег с кэдди

Запускает Caddy и блокирует его на неопределенный срок; то есть режим "демон".

--config указывает исходный файл конфигурации для немедленной загрузки и использования. Если - , конфиг читается со стандартного ввода. Если конфигурация не указана, Caddy будет работать с пустой конфигурацией и использовать настройки по умолчанию для конечных точек API администратора, которые можно использовать для подачи новой конфигурации. В качестве особого случая, если в текущем рабочем каталоге есть файл с именем «Caddyfile» и адаптер конфигурации caddyfile подключен (по умолчанию), то этот файл будет загружен и использован для настройки Caddy даже без каких-либо флагов командной строки.

--adapter — это имя адаптера конфигурации, используемого при загрузке исходной конфигурации, если таковая имеется. Этот флаг не нужен, если имя файла --config начинается с «Caddyfile», что предполагает адаптер caddyfile. В противном случае этот флаг требуется, если предоставленный файл конфигурации не имеет собственного формата JSON Caddy. Любые предупреждения будут напечатаны в лог, но учтите, что любая адаптация без ошибок будет сразу использована, даже если есть предупреждения. Если вы хотите сначала просмотреть результаты адаптации, используйте подкоманду caddy adapt.

--pidfile записывает PID в указанный файл.

--environ распечатывает среду перед запуском. Это то же самое, что и команда caddy environ, но она не завершается после печати.

--envfile загружает переменные среды из указанного файла.

--resume использует последнюю загруженную конфигурацию, которая была автоматически сохранена, переопределяя флаг --config (если он есть). Использование этого флага гарантирует устойчивость конфигурации при перезагрузке компьютера или перезапуске процесса. Это наиболее полезно в развертываниях, ориентированных на API.

--watch просматривает файл конфигурации и автоматически перезагружает его после изменения. ⚠️ Эта функция предназначена для использования только в локальных средах разработки!

старт кэдди

То же, что и caddy run , но в фоновом режиме. Эта команда блокируется только до тех пор, пока фоновый процесс не запустится успешно (или не запустится), а затем завершит работу.

Примечание: флаг --config не поддерживает чтение конфигурации из стандартного ввода.

Не рекомендуется использовать эту команду с системными службами или в Windows. В Windows дочерний процесс останется подключенным к терминалу, поэтому закрытие окна принудительно остановит Caddy, что не очевидно. Вместо этого рассмотрите возможность использования Caddy как службы.

После запуска вы можете использовать caddy stop или конечную точку POST /stop API для выхода из фонового процесса.

кэдди-стоп

Мягко останавливает работающий процесс Caddy (кроме процесса команды остановки) и вызывает его завершение. Он использует конечную точку POST /stop API администратора для корректного завершения работы.

Адрес этого запроса можно настроить с помощью флага --address или из заданного --config , если API администрирования работающего экземпляра не использует адрес прослушивания по умолчанию.

Если вы хотите остановить текущую конфигурацию, но не хотите выходить из процесса, используйте перезагрузку caddy с пустой конфигурацией или конечную точку DELETE /config/.

кедди траст

Устанавливает корневой сертификат ЦС, управляемого приложением Caddy PKI, в локальные хранилища доверенных сертификатов.

Caddy попытается автоматически установить свои корневые сертификаты в локальные хранилища доверенных сертификатов при их первом создании, но может произойти сбой, если у Caddy нет соответствующих разрешений на запись в хранилище доверенных сертификатов. Эта команда необходима для предварительной установки сертификатов перед их использованием, если серверный процесс запускается от имени непривилегированного пользователя (например, через systemd). Возможно, вам придется запустить эту команду с помощью sudo для систем unix.

По умолчанию эта команда устанавливает корневой сертификат для центра сертификации Caddy по умолчанию (т. е. "локального"). Вы можете указать идентификатор другого центра сертификации с помощью флага --ca.

Эта команда попытается подключиться к API администрирования Caddy для получения корневого сертификата, используя конечную точку GET /pki/ca/ /certificates. Вы можете явно указать --address или использовать флаг --config для загрузки адреса администратора из вашей конфигурации, если API администрирования работающего экземпляра не использует адрес прослушивания по умолчанию.

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

кэдди не доверяет

Отменяет доверие к корневому сертификату из локальных хранилищ доверенных сертификатов.

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

Эта команда не удаляет и не изменяет файлы сертификатов из настроенного хранилища Caddy.

Эту команду можно использовать одним из двух способов:

  • Указав прямой путь к корневому сертификату, которому нельзя доверять, с помощью флага --cert.
  • Получив корневой сертификат из API администрирования с помощью конечной точки GET /pki/ca/ /certificates. Это поведение по умолчанию, если флаги не заданы.

Если используется API администратора, идентификатор ЦС по умолчанию имеет значение "локальный". Вы можете указать идентификатор другого центра сертификации с помощью флага --ca. Вы можете явно указать --address или использовать флаг --config для загрузки адреса администратора из вашей конфигурации, если API администрирования работающего экземпляра не использует адрес прослушивания по умолчанию.

обновление тележки

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

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

Процесс обновления отказоустойчив; текущий двоичный файл создается первым (копируется рядом с текущим) и автоматически восстанавливается, если что-то пойдет не так. Если вы хотите сохранить резервную копию после завершения процесса обновления, вы можете использовать параметр --keep-backup.

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

дополнительный пакет caddy

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

удалить пакет caddy

Подобно caddy upgrade , заменяет текущий двоичный файл Caddy последней версией с теми же установленными модулями, но без пакетов, перечисленных в качестве аргументов, если они существовали в текущем двоичном файле. Запустите caddy list-modules --packages, чтобы просмотреть список имен пакетов нестандартных модулей, включенных в текущий двоичный файл.

проверка кэдди

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

--config — файл конфигурации для проверки. Если - , конфиг читается со стандартного ввода. По умолчанию это Caddyfile в текущем каталоге, если он есть.

--adapter — это имя используемого адаптера конфигурации, если файл конфигурации не имеет собственного формата JSON Caddy. Если файл конфигурации начинается с Caddyfile , по умолчанию используется адаптер caddyfile.

Вы также можете запустить проверку и очистку кода из командной строки.

Управление выполнением любого средства запуска тестов (MSTest, NUnit, xUnit, MSpec и т. д.), запись покрытия выполненных тестов в моментальных снимках покрытия и создание отчетов.

Объединить снимки покрытия.

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

Создавайте отчеты о покрытии в различных форматах.

Используйте команду report для создания отчетов в нужных форматах из снимков покрытия.

Установите средство запуска консоли dotCover

Существует несколько способов установить средство запуска консоли dotCover:

Использование архива - самый универсальный способ установки консольного раннера.

Использование пакета NuGet — рекомендуется, если вы хотите запустить анализ покрытия в качестве шага сборки на сервере CI/CD.

Чтобы установить бегун консоли dotCover из архива

Скопируйте архив на машину, на которой вы собираетесь установить средство запуска консоли.

Извлеките файлы из архива в каталог, из которого вы собираетесь запускать исполняемый файл запуска консоли dotCover.exe (Windows), dotCover.sh (Linux, macOS).

Чтобы установить средство запуска консоли dotCover из пакета NuGet

На сервере CI/CD добавьте этап сборки, который восстанавливает пакеты NuGet.

На сервере CI/CD добавьте этапы сборки, использующие средство запуска консоли.

Чтобы установить его как локальный инструмент:

Дальнейшие инструкции см. в официальной документации Microsoft.

Убедитесь, что проект модульного тестирования создан.

Перейдите в каталог, где находится dotCover.exe.

Введите в консоли следующую команду:

dotCover cover /TargetExecutable="D:\Program Files\NUnit 2.6\bin\nunit-console.exe" /TargetArguments="D:\Projects\TheApplication\bin\Debug\AppTests.dll" /Output="AppCoverageReport .html" /ReportType="HTML"

TargetExecutable – это путь к исполнителю среды модульного тестирования

TargetArguments — это аргументы, передаваемые исполнителю — скомпилированной сборке модульного теста. Обратите внимание, что если эти аргументы содержат пути с пробелами, их следует отделять дополнительными двойными кавычками и обратной косой чертой, например, . /TargetArguments="\"D:\Мои проекты\Мое приложение\bin\Debug\AppTests.dll""

Вывод – это имя файла отчета.

ReportType — это тип отчета (в данном случае мы создаем отчет в формате HTML)

При выходе из средства выполнения консоли файл AppCoverageReport.html должен появиться в том же каталоге, что и средство выполнения консоли dotCover. Откройте этот файл, чтобы просмотреть результаты покрытия в веб-браузере.

Кроме того, вы можете передать параметры в файле XML. Для этого введите dotCover help covercover.xml в командной строке.

Откройте сгенерированный файл cover.xml и укажите параметры конфигурации. Например, файл конфигурации может выглядеть следующим образом:

Используйте файл покрытия покрытия dotCover.xml для запуска покрытия с указанными параметрами.

Устанавливается из архива или пакета NuGet: dotCover.exe (Windows), dotCover.sh (Linux, macOS).

Откройте папку решения.

Создайте решение:

Выполнить тесты с анализом покрытия:

dotnet dotcover не поддерживает команды dotCover.exe — он всегда выполняет анализ покрытия, как если бы вы запускали dotCover.exe cover . Аргументы, указанные после dotnet dotcover, передаются не в dotcover, а в инструмент dotnet. Если вы хотите предоставить аргументы для dotCover, используйте те же аргументы, что и для стандартного исполнителя dotCover.exe, но с префиксом dc. Например, чтобы указать тип отчета, используйте --dcReportType вместо --ReportType :

Если вы настроили dotCover.exe с XML-файлом и хотите продолжить его использование, укажите путь к файлу:

Перейдите в каталог, где находится dotCover.exe / dotCover.sh.

Введите в консоли следующую команду:

dotCover.exe dotnet --output=AppCoverageReport.html --reportType=HTML -- test "C:\MyProject\MainTests.csproj"

--output — это имя файла отчета.

--reportType — это тип отчета (в данном случае мы создаем отчет в формате HTML)

-- test "C:\MyProject\MainTests.csproj" в конце является аргументом, передаваемым в dotnet . На самом деле вы можете заменить его на --TargetArguments="test \"C:\MyProject\MainTests.csproj\"", но это намного дольше.

Вы, наверное, заметили, что мы используем синтаксис в стиле Unix для аргументов командной строки. Вы также можете использовать этот синтаксис в Windows. Например, следующий код взаимозаменяем в Windows (но не в macOS и Linux): /TempDir:"../myDir" и --tempDir="../myDir"

При выходе из средства выполнения консоли файл AppCoverageReport.html должен появиться в том же каталоге, что и средство выполнения консоли dotCover.Откройте этот файл, чтобы просмотреть результаты покрытия в веб-браузере.

Применить фильтры

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

Ознакомьтесь с разделом Настройка фильтров покрытия, чтобы узнать, как настроить фильтры в графическом интерфейсе dotCover. Обратите внимание, что фильтры, настроенные в графическом интерфейсе, не применяются при запуске покрытия с помощью средства запуска консоли.

Вы можете включать и исключать фильтры в любом порядке.

Независимо от порядка, средство запуска консоли сначала применяет фильтры включения, а затем фильтры исключения.

Если фильтры включения не указаны явно, средство запуска консоли сначала включает все, а затем исключает то, что указано в фильтрах исключения.

Если есть фильтр включения, то средство запуска консоли сначала исключает все, что не соответствует фильтру включения, а затем применяет явные фильтры исключения, если таковые имеются.

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

При необходимости эти фильтры по умолчанию можно отключить с помощью параметра командной строки DisableDefaultFilters.

Существует два способа указать фильтры покрытия:

Настройка фильтров покрытия с помощью файла конфигурации XML

Чтобы исключить некоторые элементы (модули, классы, методы) из отчета о покрытии, сохранив при этом все остальные, добавьте соответствующие записи в узел ExcludeFilters. Например:

Дополнительные тесты — будут исключены все тесты из соответствующего модуля. AdditionalTests здесь — имя сборки без расширения.

MainTests.Unit* — будут исключены все классы, имя которых начинается с MainTests.Unit.

MainTests.IntegrationTests TestFeature1 — будет исключен метод TestFeature1 класса MainTests.IntegrationTests. Обратите внимание, что FunctionMask всегда должен содержать короткое имя метода. Если вы пропустите какой-либо элемент в FilterEntry, dotCover будет рассматривать это как подстановочный знак. Например, если вы удалите ClassMask в этом конкретном случае, dotCover исключит все методы TestFeature1 (принадлежащие всем модулям и классам).

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

Еще один вариант — отфильтровать классы и методы на основе их атрибутов. Например, чтобы отфильтровать методы, отмеченные атрибутом System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute, мы можем добавить в файл конфигурацииcoverage.xml следующее:

Кроме того, вы можете настроить фильтры покрытия, используя аргументы командной строки dotCover.exe.

Настройка фильтров покрытия с помощью аргументов командной строки

Чтобы исключить/включить элементы из анализа покрытия, следует запустить средство запуска консоли с параметром /Filters. Например (для простоты мы опускаем параметры, относящиеся к целевому охвату):

Обложка dotCover.exe . /Filters=-:module=AdditionalTests;-:type=MainTests.Unit*; -:type=MainTests.IntegrationTests;function=TestFeature1;

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

Запись, начинающаяся с -:, отвечает за исключение, и наоборот, запись, начинающаяся с +:, - за включение.

Если вам нужно исключить/включить только модуль, вы можете опустить ключевое слово модуля:

Чтобы отфильтровать классы и методы на основе их атрибутов, следует использовать параметр /AttributeFilters. Например, чтобы отфильтровать методы, отмеченные атрибутом System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute:

Обложка dotCover.exe . /AttributeFilters=System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute;

Точка с запятой (;) служит разделителем.

Изменить область охвата результатов

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

При необходимости вы можете изменить набор сборок, информация о которых должна быть добавлена ​​в снимок. Для этого используйте параметр Scope. Например, чтобы добавить все сборки из вашего проекта в снимок, вы можете добавить в файл конфигурации следующее:

Обратите внимание, что все, что исключается с помощью фильтров, в любом случае исключается независимо от указанных областей.

Охватить несколько тестовых проектов

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

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

Предположим, что у нас есть два проекта модульного тестирования: TestProject1, использующий MSTest, и TestProject2, использующий NUnit. Чтобы запустить покрытие по обоим проектам и получить единый отчет, мы выполняем следующие шаги:

Запуск покрытия для нескольких проектов на отдельных этапах

Создайте два файла конфигурации для запуска команды cover (c) в каждом из тестовых проектов. testProject1.xml для TestProject1, использующего MSTest:

C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\MSTest.exe TestProject1.dll D:\Projects\TheApplication\bin\Debug Snapshot1.dcvr

и testProject2.xml для TestProject2, использующего NUnit:

D:\Program Files\NUnit 2.6\bin\nunit-console.exe TestProject2.dll D:\Projects\TheApplication\bin\Debug Snapshot2.dcvr

Запустите команду cover (c) на каждом из тестовых проектов, используя подготовленные файлы конфигурации: dotCover c testProject1.xml и dotCover c testProject2.xml. В результате вы получите два снимка покрытия: Snapshot1.dcvr и Snapshot2.dcvr .

Выполните команду слияния (m), чтобы объединить оба снимка:

где merge.xml — это файл конфигурации:

Чтобы создать тестовый отчет в формате HTML из объединенных снимков, выполните команду report (r)

где report.xml — это файл конфигурации:

Найти файлы символов (PDB)

Нахождение файлов символов (PDB) для целевых двоичных файлов жизненно важно для расчета покрытия. Если вы охватываете модульные тесты или запускаемый проект, dotCover легко находит файлы символов, используя структуру текущего решения.

По умолчанию dotCover ищет файлы символов в следующих местах:

в том же каталоге, где находится двоичный файл;

в каталоге отладки, указанном внутри двоичного файла;

во всех каталогах, указанных в переменной окружения _NT_SYMBOL_PATH и в реестре;

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

Используйте параметр AllowSymbolServerAccess, чтобы разрешить dotCover доступ к серверам символов, указанным либо в параметре SymbolSearchPaths, либо в переменной среды _NT_SYMBOL_PATH.

Выполняет системную команду. Если указан атрибут os, команда выполняется только при запуске Apache Ant в одной из указанных операционных систем.

Обратите внимание, что вы не можете взаимодействовать с разветвленной программой, единственный способ отправить ей входные данные — через атрибуты input и inputstring. Также обратите внимание, что, начиная с Ant 1.6, любая попытка чтения ввода в разветвленной программе будет получать EOF (-1). Это изменение по сравнению с Ant 1.5, где такая попытка блокировалась.

Если вы хотите запустить исполняемый файл, используя путь относительно базового каталога проекта, вам может потребоваться использовать vmlauncher = false в некоторых операционных системах, но даже это может привести к сбою (сообщается, что Solaris 8/9 вызывает проблемы). Атрибут resolveexecutable должен быть более надежным, например,

Пользователи Windows

Обратите внимание, что файлы .bat, как правило, не могут выполняться напрямую. Обычно необходимо выполнить исполняемый файл командной оболочки cmd с помощью переключателя /c.

Распространенной проблемой является отсутствие исполняемого файла в PATH . Если вы получили сообщение об ошибке Невозможно запустить программу ".": CreateProcess error=2. Система не может найти указанный путь. взгляните на свою переменную PATH. Просто введите команду прямо в командной строке, и если Windows найдет ее, Ant тоже должен это сделать. (В противном случае обратитесь за помощью в список рассылки пользователя.) Если Windows не может выполнить программу, добавьте каталог программы в PATH ( установите PATH=%PATH%;dirOfProgram ) или укажите абсолютный путь в атрибуте исполняемого файла в вашем файле сборки. .

Пользователи Cygwin

Задача не понимает такие пути, как /bin/sh для исполняемого параметра. Это связано с тем, что JVM, в которой работает Ant, является стандартным исполняемым файлом Windows и не знает о среде Cygwin (т. е. не загружает cygwin1.dll). Единственный обходной путь для этого — скомпилировать JVM под Cygwin (на свой страх и риск). См., например, инструкции по сборке OpenJDK для cygwin.

Пользователи OpenVMS

Обратите внимание, что JVM, предоставленная HP, не соответствует правилам кодов выхода OpenVMS. Если вы запустите JVM с этой задачей, задача может ложно заявить, что произошла ошибка (или молча проигнорировать ошибку). Не используйте эту задачу для запуска JAVA.EXE , вместо этого используйте задачу с атрибутом fork, установленным в значение true, так как эта задача будет следовать интерпретации кодов выхода JVM.

Пользователи RedHat S/390

В linux-390 сообщалось, что сценарии оболочки, вызываемые с помощью задачи Ant Exec, должны иметь указанный интерпретатор, т. е. сценарии должны начинаться примерно так:

или задача не будет выполнена следующим образом:

Запуск Ant в качестве фонового процесса в Unix-подобных системах

Если вы запускаете Ant в качестве фонового процесса (например, ant & ) и используете задачу с параметром spawn, установленным на false , вы должны указать явные входные данные для разветвленного процесса, иначе Ant будет приостановлен, поскольку он попытается прочитать из стандартного ввода.

Параметры

< tr>
Атрибут Описание Обязательный
command команда для выполнения со всеми аргументами командной строки. Устарело, вместо этого используйте исполняемые и вложенные элементы. Точно один из двух
executable команда для выполнения без аргументов командной строки.
dir каталог, в котором находится команда должен быть выполнен. Нет; если vmlauncher имеет значение true , по умолчанию используется текущий рабочий каталог, в противном случае список операционных систем, основанных на проекте
os , в которых может выполняться команда. Если имя текущей ОС содержится в этом списке, команда будет выполнена. Имя ОС определяется JVM и устанавливается в системном свойстве os.name. Нет
osfamily Семейство ОС как используется в условии. начиная с Ant 1.7 Нет
spawn независимо от того, хотите ли вы, чтобы команда запускалась
Если вы порождаете команду, Ant не регистрирует ее выходные данные.
Настройки свойств input , output , error и result не активны при порождении процесса.
поскольку Ant 1.6 		Нет; по умолчанию false
output Имя файла, в который нужно записать вывод. Если поток ошибок также не перенаправляется в файл или свойство, он появится в этом выводе. Нет
error Файл, в который следует перенаправить стандартную ошибку команды. начиная с Ant 1.6 Нет
logError Этот атрибут используется, когда вы хотите увидеть ошибку вывод в журнале Ant, и вы перенаправляете вывод в файл/свойство. Вывод ошибки не будет включен в выходной файл/свойство. Если вы перенаправляете ошибку с помощью атрибутов error или errorProperty, это не будет иметь никакого эффекта. начиная с Ant 1.6 Нет
append Должны ли выходные файлы и файлы ошибок добавляться к или перезаписывается. Нет; по умолчанию false
outputproperty Имя свойства, в котором должны храниться выходные данные команды. Если поток ошибок не перенаправляется в отдельный файл или поток, это свойство будет включать вывод ошибки. Нет
errorproperty Имя свойства, в котором должна храниться стандартная ошибка команды. начиная с Ant 1.6 Нет
input Файл, из которого берется стандартный ввод выполняемой команды. взятый. Этот атрибут является взаимоисключающим с атрибутом inputstring. начиная с Ant 1.6 Нет
inputstring Строка, которая служит входным потоком для выполненная команда. Этот атрибут является взаимоисключающим с входным атрибутом. начиная с Ant 1.6 Нет
resultproperty имя свойства, в котором код возврата команды должны быть сохранены. Представляет интерес только в том случае, если failonerror = false . Нет
timeout Остановить команду, если она не завершается в течение указанного время (указано в миллисекундах). Нет
failonerror Остановить процесс сборки, если команда завершается с кодом возврата, сигнализирующим неудача. Нет; по умолчанию false
failifexecutionfails Остановить сборку, если мы не можем запустить программу. Нет; по умолчанию true
newenvironment Не распространять старую среду при указании новых переменных среды. Нет; значение по умолчанию — false
vmlauncher Выполнить команду, используя средства выполнения JVM, где это возможно. Если установлено значение false, будет использоваться базовая оболочка ОС, либо напрямую, либо через сценарии antRun. В некоторых операционных системах это дает доступ к средствам, обычно недоступным через JVM, в том числе в Windows возможность выполнять сценарии, а не связанный с ними интерпретатор. Если вы хотите указать имя исполняемого файла как относительный путь к каталогу, заданному атрибутом dir, может также потребоваться установить для vmlauncher значение false. Нет; значение по умолчанию — true
resolveexecutable Когда этот атрибут имеет значение true , имя исполняемого файла сначала разрешается относительно проекта на основеir, и если он не существует, против каталога выполнения, если он указан. В системах Unix, если вы хотите разрешить выполнение команд только по пути пользователя, установите для этого параметра значение false . начиная с Ant 1.6 Нет; значение по умолчанию false
searchpath Если этот атрибут имеет значение true , то при разрешении местоположения исполняемого файла будут выполняться поиск переменных среды системного пути. начиная с Ant 1.6.3 Нет; значение по умолчанию false
discardOutput Должен ли вывод полностью отбрасываться. Этот параметр несовместим с любым параметром, который перенаправляет вывод в файлы или свойства.
Если вы установите значение true, вывод ошибок также будет игнорироваться, если только вы не перенаправите вывод ошибок в файлы, свойства или включите logError . Начиная с Ant 1.10.10 		Нет; по умолчанию false
discardError Должен ли вывод ошибки полностью отбрасываться. Этот параметр несовместим с любым параметром, который перенаправляет вывод ошибок в файлы или свойства, а также logError . Начиная с Ant 1.10.10 Нет; по умолчанию false

Примеры

Параметры, указанные как вложенные элементы

Аргументы командной строки должны быть указаны как вложенные элементы. См. Аргументы командной строки.

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

Атрибут Описание Обязательный
key Имя переменной среды.
Примечание: начиная с Ant 1.7, для Windows имя нечувствительно к регистру. 		Да
value Буквальное значение переменной среды. Ровно один из этих
path Значение переменной среды, подобной PATH. Вы можете использовать ; или : как разделители путей, и Ant преобразует их в локальные соглашения платформы.
файл Значение переменной среды. Будет заменено абсолютным именем файла на Ant.

перенаправитель

Можно указать вложенный перенаправитель ввода-вывода. Как правило, атрибуты перенаправителя ведут себя как соответствующие атрибуты, доступные на уровне задачи. Наиболее примечательная особенность связана с сохранением атрибутов для обратной совместимости. Любое сопоставление файлов выполняется с использованием нулевого исходного файла; поэтому не все типы Mapper будут возвращать результаты. Когда результаты не возвращаются, спецификации перенаправления возвращаются к атрибутам уровня задачи. На практике это означает, что для входных, выходных файлов и файлов вывода ошибок можно указать значения по умолчанию.

Ошибки и коды возврата

По умолчанию код возврата игнорируется; когда вы устанавливаете для failonerror значение true, тогда любой сбой сигнализации кода возврата (зависит от ОС) приводит к сбою сборки. Кроме того, вы можете установить для свойства result имя свойства и назначить его коду результата (конечно, за исключением неизменяемости).

Если попытка запустить программу не удалась с кодом ошибки, зависящим от ОС, сборка останавливается, если только для параметра failifexecutionfails не задано значение false . Вы можете использовать его для запуска программы, если она существует, но в остальном ничего не делать.

Что означают эти коды ошибок? Ну, они зависят от ОС. На коробках Windows вы должны посмотреть документацию; error=2 означает «нет такой программы», что обычно означает, что ее нет на пути. Всякий раз, когда вы видите такую ​​ошибку в любой задаче Ant, обычно это не ошибка Ant, а какая-то проблема с конфигурацией вашего компьютера.

Примеры

Запустите emacs на дисплее 1 системы X Window.

Добавьте $/bin в PATH системной команды.

Начните $ с указанного $ и завершите процесс Ant. Браузер останется.

Отправьте строку blah before blah исполняемому файлу cat, используя для замены before на after по пути. Вывод отправляется в файл redirector.out и сохраняется в свойстве с тем же именем. Точно так же выходные данные об ошибках отправляются в файл и свойство с именами redirector.err .

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

Тайм-ауты: если указан тайм-аут, когда он достигается, подпроцесс останавливается, а сообщение печатается в журнале. Возвращаемое значение выполнения будет -1 , что остановит сборку, если failonerror = true , но в противном случае будет проигнорировано.

Указываемые параметры выполнения зависят от типа проекта и комплекта, с помощью которого вы создаете и запускаете проект.

Qt Creator автоматически создает конфигурации запуска для вашего проекта. Чтобы просмотреть и изменить их, выберите «Проекты» > «Создать и запустить» > «Выполнить».

Чтобы запретить Qt Creator автоматически создавать конфигурации запуска, выберите Инструменты > Параметры > Сборка и запуск, а затем снимите флажок Автоматически создавать подходящие конфигурации запуска.

Управление конфигурациями запуска

Доступные конфигурации запуска перечислены в поле «Конфигурация запуска». Чтобы добавить конфигурации запуска для проекта, выберите Добавить. Чтобы добавить конфигурацию запуска, основанную на текущей, выберите Клонировать.

Чтобы переименовать текущую конфигурацию запуска, выберите "Переименовать".

Чтобы удалить текущую конфигурацию запуска, выберите Удалить.

Конфигурации запуска для проектов qmake получают свой исполняемый файл из проанализированных файлов .pro. Дополнительные сведения о построении команд см. в разделе Запуск внешних процессов.

Выбор цели выполнения по умолчанию

Если в проекте несколько исполняемых файлов, вам нужно указать Qt Creator, какой из них следует запустить.

CMake Run Targets

При использовании CMake можно отфильтровать список целей выполнения, установив qtc_runnable в качестве значения свойства FOLDER в файле CMakeLists.txt для проекта. Например:

Если вы не укажете qtc_runnable для какого-либо проекта, Qt Creator автоматически добавит конфигурации запуска для всех целей, указанных в CMakeLists.txt.

qmake Run Targets

При использовании qmake вы можете запретить Qt Creator автоматически создавать конфигурации запуска для подпроектов, указав переменную qtc_runnable в файлах .pro проектов приложений ( TEMPLATE=app ), которые вы хотите запустить. Например

Если ни в одном из ваших проектов приложений не указано qtc_runnable , Qt Creator создает конфигурации запуска для всех проектов приложений.

Если какой-либо из ваших проектов приложений указывает qtc_runnable , Qt Creator создает конфигурации запуска только для подпроектов, в файлах .pro которых также установлен параметр CONFIG += qtc_runnable.

Дополнительную информацию о шаблонах проектов qmake см. в разделе ШАБЛОН.

Цели запуска мезонов

Qt Creator автоматически добавляет конфигурации запуска для всех целей, объявленных с помощью функции executable() в описаниях сборок Meson.

Указание параметров запуска для типов настольных устройств

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

Для консольных приложений установите флажок Запускать в терминале. Чтобы указать терминал для использования в Linux и macOS, выберите Инструменты > Параметры > Среда > Система.

Для запуска со специальными настройками переменных среды выберите их в разделе "Выполнение среды". Дополнительные сведения см. в разделе Выбор среды выполнения.

При создании приложения Qt Creator создает список каталогов, в которых компоновщик будет искать библиотеки, на которые ссылается приложение. По умолчанию связанные библиотеки становятся видимыми для исполняемого файла, который пытается запустить Qt Creator. Обычно эту опцию следует отключать только в том случае, если она вызывает нежелательные побочные эффекты или если вы используете этапы развертывания, такие как make install , и хотите убедиться, что развернутое приложение найдет библиотеки даже при запуске без Qt Creator.< /p>

Чтобы отключить связывание библиотек для текущего проекта, снимите флажок Добавить путь поиска библиотеки сборки к PATH. Чтобы отключить связывание библиотек для всех проектов, выберите «Инструменты» > «Параметры» > «Сборка и запуск», а затем снимите флажок «Добавить пути поиска библиотеки компоновщика для запуска среды».

Параметр Использовать отладочную версию фреймворков (DYLD_IMAGE_SUFFIX=_debug) (доступен только в macOS) позволяет отлаживать (например, переходить в) связанные фреймворки, такие как сам фреймворк Qt. Вам не нужен этот параметр для отладки кода вашего приложения.

В Linux установите флажок «Запуск от имени пользователя root», чтобы запустить приложение с разрешениями пользователя root.

Вы также можете создавать настраиваемые конфигурации запуска исполняемого файла, в которых можно настроить исполняемый файл для запуска. Дополнительные сведения см. в разделе «Указание пользовательского исполняемого файла для запуска».

Указание настроек Valgrind

Qt Creator интегрирует инструменты анализа кода Valgrind для обнаружения утечек памяти и профилирования выполнения функций. Вы можете настроить инструменты в соответствии со своими потребностями.

Вы можете указать настройки Valgrind либо глобально для всех проектов, либо отдельно для каждого проекта.

Чтобы указать настройки Valgrind для текущего проекта:

  1. В разделе "Настройки Valgrind" выберите "Пользовательские".
  2. Укажите настройки Valgrind для проекта.

Для получения дополнительной информации о настройках CallGrind и MemCheck см.:

Нажмите «Восстановить глобальные», чтобы вернуться к глобальным настройкам.

Чтобы задать глобальные настройки Valgrind, выберите Инструменты > Параметры > Анализатор.

Включение отладки

Чтобы выбрать языки для отладки, установите флажки Включить C++ и Включить QML.

Примечание. Открытие сокета на известном порту представляет угрозу безопасности. Любой человек в Интернете может подключиться к отлаживаемому приложению и выполнить любые функции JavaScript. Поэтому необходимо убедиться, что порт должным образом защищен брандмауэром.

Дополнительную информацию об отладке см. в разделе Отладка.

Указание параметров запуска для устройств Android

Чтобы запускать и отлаживать приложение на устройстве Android, необходимо создать подключения от хоста разработки к устройству, как указано в разделе "Подключение устройств Android".

Набор параметров запуска Android Activity Manager (am) по умолчанию применяется при запуске приложений. Вы можете указать дополнительные параметры запуска в поле Аргументы запуска менеджера активности. Однако если параметры по умолчанию конфликтуют с добавленными параметрами, приложение может не запуститься.

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

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

Например, чтобы запустить приложение от имени определенного пользователя, введите параметр запуска --user 10 , где 10 – идентификатор пользователя учетной записи пользователя.

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

Введите следующие команды в команды оболочки Post-quit на устройстве, чтобы вернуться к пользователю по умолчанию, 0 , и разблокировать экран после выхода из приложения:

Указание параметров запуска для устройств на базе Linux

Чтобы запускать и отлаживать приложение на устройстве под управлением Linux, необходимо создать подключения от хоста разработки к устройству и добавить конфигурации устройства в комплекты. Нажмите «Управление комплектами», чтобы добавить устройства в комплекты. Дополнительные сведения см. в разделе «Подключение общих удаленных устройств Linux».

Когда вы запускаете приложение, Qt Creator копирует файлы на подключенное устройство.

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

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

Указание параметров запуска для устройств QNX

Для запуска и отладки приложения на устройстве QNX необходимо создать соединения с ПК для разработки на устройстве. Щелкните Управление конфигурациями устройств, чтобы создать подключение. Дополнительные сведения см. в разделе «Подключение устройств QNX».

Указание параметров запуска для устройств QNX Neutrino очень похоже на указание параметров запуска для устройств на базе Linux.

Указание параметров запуска для устройств Boot2Qt

Для запуска и отладки приложения на устройстве Boot2Qt (только коммерческое) необходимо создать соединения с узла разработки на устройстве и добавить конфигурации устройства в комплекты. Выберите «Управление комплектами», чтобы добавить устройства в комплекты. Для получения дополнительной информации см. Руководство по установке в документации Qt для создания устройств.

В настройках запуска отображается путь к исполняемому файлу на хосте разработки и на устройстве.

Дополнительную информацию об этапах развертывания см. в разделе Развертывание приложений на устройствах Boot2Qt.

Выбор среды запуска

Qt Creator автоматически выбирает среду, используемую для запуска приложения, в зависимости от типа устройства. Вы можете изменить среду или выбрать другую среду в разделе «Среда запуска».

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

При запуске на рабочем столе по умолчанию используется среда сборки, но вы также можете использовать системную среду без дополнений, внесенных в среду сборки. Дополнительные сведения см. в разделах «Среда сборки» и «Указание параметров среды».

Для запуска в чистой системной среде выберите Чистая среда.

При запуске на мобильном устройстве, подключенном к хосту разработки, Qt Creator получает информацию о среде устройства с устройства.Обычно нет смысла редактировать среду устройства.

Чтобы изменить значения переменных среды для среды выполнения, выберите «Пакетное редактирование». Дополнительную информацию см. в разделе Пакетное редактирование.

Указание пользовательского исполняемого файла для запуска

Если вы используете CMake, Meson или общий тип проекта в Qt Creator или хотите запустить собственный исполняемый файл для рабочего стола, создайте конфигурацию запуска пользовательского исполняемого файла для своего проекта. Например, при работе с библиотекой вы можете запустить тестовое приложение, связывающееся с библиотекой.

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

Указание параметров запуска для проектов Qt Quick UI

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

  • В поле Средство просмотра QML укажите используемое средство просмотра Qt QML.
  • В поле Аргументы командной строки укажите аргументы, которые необходимо передать исполняемому файлу.
  • В основном файле QML выберите файл, с которым будет запущена программа просмотра Qt QML.

Указание параметров запуска для проектов Python

Вы можете указать параметры для запуска приложений Qt для Python:

  • В поле "Интерпретатор" укажите путь к исполняемому файлу Python.
  • Установите флажок «Буферизованный вывод», чтобы буферизовать вывод. Это повышает производительность вывода, но вызывает задержки вывода.
  • В поле "Сценарий" вы можете увидеть путь к основному файлу проекта, который будет запущен.
  • В поле Аргументы командной строки укажите аргументы командной строки, которые будут переданы в исполняемый файл.

Если вы хотите запустить какой-либо файл Python, отличный от main.py , создайте пользовательскую конфигурацию запуска исполняемого файла:

  1. Выберите «Добавить» > «Пользовательский исполняемый файл».
  2. В поле «Исполняемый файл» укажите путь к исполняемому файлу Python.
  3. В поле Аргументы командной строки выберите файл Python для запуска.

© 2021 The Qt Company Ltd. Права на документацию, включенную в настоящий документ, принадлежат их соответствующим владельцам. Предоставленная здесь документация распространяется под лицензией GNU Free Documentation License версии 1.3, опубликованной Free Software Foundation. Qt и соответствующие логотипы являются товарными знаками The Qt Company Ltd в Финляндии и/или других странах мира. Все остальные товарные знаки являются собственностью соответствующих владельцев.

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