Сборка dotnet и публикация в Azure DevOps

Question

У меня консольное приложение .NET Core 2.0. Я могу успешно создать или опубликовать это приложение и запустить его локально. Я также могу успешно создать и опубликовать это приложение в DevOps Azure. Однако, если я создаю приложение в DevOps Azure, я не могу запустить результат.

В Azure DevOps я пытался создать, используя:

dotnet build -c Release -r win-x64 -o app

Это генерирует небольшое количество файлов только с файлами, связанными с проектом. Он не включает в себя все файлы System. *. Dll и т. Д., Которые кажутся чрезмерными для большинства моих случаев. Эта команда прекрасно работает, когда я запускаю ее на своем локальном компьютере, и я могу успешно щелкнуть файл MyApp.exe и запустить мое консольное приложение. Однако, если я запускаю ту же команду в Azure DevOps, генерируемый файл MyApp.exe не будет работать должным образом. Вместо этого он запускается, а затем сразу же выходит. В консольном приложении ничего не печатается. Я не вижу ошибок. Приложение очень простое, включает в себя "try-catch" вокруг всего и имеет Console.ReadLine в конце. Итак, я думал, что он останется открытым.

Когда я бегу:

dotnet publish -c Release -r win-x64 -o app

Я получаю те же файлы, но с включением всех файлов System. *. Dll и т. Д. На этот раз я заметил, что я могу успешно запустить MyApp.exe, и он ведет себя как ожидалось.

Почему dotnet build ... работает локально, но я, похоже, не получаю такого же поведения, когда запускаю dotnet build ... в DevOps Azure. Кажется, я вынужден использовать dotnet publish. Моя проблема в том, что результирующий файл .zip имеет размер от ~ 500 КБ до 30 МБ. Это большая разница.

Answer 1

Ответ лошади:

Команда сборки dotnet собирает проект и его зависимости в набор двоичных файлов.Двоичные файлы включают код проекта в файлах на промежуточном языке (IL) с расширением .dll и файлы символов, используемые для отладки с расширением .pdb.Создается файл JSON зависимостей (* .deps.json), в котором перечислены зависимости приложения.Создается файл * .runtimeconfig.json, в котором указывается общая среда выполнения и ее версия для приложения.

Если у проекта есть сторонние зависимости, такие как библиотеки из NuGet, они разрешаются из NuGetкэш и не доступны со встроенным выходом проекта.Учитывая это, продукт сборки dotnet не готов к передаче на другую машину для запуска.

dotnet build - Создает проект и все его зависимости..

dotnet publish - упаковывает приложение и его зависимости в папку для развертывания в системе хостинга.(PS - это также создает приложение перед упаковкой)

Описание на самом деле очень хорошее, учитывая, что оно пришло непосредственно от Microsoft, поэтому я не буду повторять здесь слова.

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

Команды для запуска: dotnet build dotnet publish

dotnet clean для очисткипапка bin

Кроме того, запустите ее на корневом уровне и просмотрите вывод с включенным автономным флагом:

dotnet publish -o ./output --runtime win10-x64 --self-contained

Подробнее оавтономные сборки

Answer 2

Разница между ними заключается в том, что:

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

Но для сборки приложение ссылается на пакеты, которые находятся в папке пользователя, поэтому zip-файл всего 500 КБ.

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

В противном случае вам необходимо опубликовать приложение.