. net ядро ​​3.1 pack dll с Azure Devops

Question

Я пытаюсь упаковать веб-интерфейс, который я сделал. net core 3.1 с Azure Pipeline.

  - task: DotNetCoreCLI@2
displayName: Package NuGet
inputs: 
  command: 'pack'
  projects: '**/*.csproj'
  arguments: '--configuration $(BuildConfiguration)'
  outputDir: '$(Build.ArtifactStagingDirectory)/packages'

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

Моя единственная проблема в том, что он дает несколько файлов .nupkg вместо одного и что пакеты веб-API не имеют зависимостей dll.

Также я создал Файл .nuspe c, но мне, кажется, не удается правильно его использовать с Azure Конвейером. Я попробовал то, что объяснено здесь: https://docs.microsoft.com/fr-fr/nuget/reference/msbuild-targets#packing -using-a-nuspe c

или просто путем нацеливания на файл .nuspe c, как описано в подсказке к конвейеру

Если кто-нибудь мог поставьте меня на правильный путь, который будет очень ценен:)

РЕДАКТИРОВАТЬ: Я хочу упаковать все в nupkg, чтобы затем развернуть его для сайта IIS.

Это мой файл nuspe c:

   <?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
    <metadata>
        <id>WebAPI</id>
        <version>1.0.0</version>
        <authors>Kevin Pinero</authors>
        <requireLicenseAcceptance>false</requireLicenseAcceptance>
        <description>WebAPI</description>
    </metadata>
    <files>
        <file src=".\bin\Release\*\*.dll" target="lib" />
        <file src=".\bin\Release\*\*.exe" target="lib" />
        <file src=".\bin\Release\*\*.json" target="lib" />
       <!-- <file src=".\bin\Release\*\Properties\*.json" target="lib" /> -->
        <file src=".\bin\Release\*\*.pdb" target="lib" />
        <file src=".\bin\Release\*\*.config" target="lib" />
    </files>
</package>

И эта ошибка, которую я получаю по конвейеру:

Ошибка MSB4068: Элемент Nt не распознается или не поддерживается в этом контексте.

Использование этой задачи:

  - task: DotNetCoreCLI@2
    inputs:
      command: 'pack'
      packagesToPack: '**/*API.nuspec'
      nobuild: true
      versioningScheme: 'off'

Я знаю, на веб-сайте Microsoft я мог бы потенциально использовать эту команду тоже

dotnet pack ~/projects/app1/project.csproj -p:NuspecFile=~/projects/app1/project.nuspec -p:NuspecBasePath=~/projects/app1/nuget

Но я не уверен, как перевести это в конвейер AZ ...

Answer 1

ОБНОВЛЕНИЕ

---

---

Поскольку вы пытаетесь упаковать проект веб-API для доставки в IIS, вам следует прекратить попытки использовать nuget в качестве этого механизма и вместо этого использовать команду dotnet publish , Если вы хотите продолжать использовать задачу DotNetCoreCLI@2 (в отличие от использования комбинации клавиш script для непосредственного вызова dotnet cli) , то я бы указал на документацию Сборка, тестирование и развертывание. Net Основные приложения .

Эта документация не написана специально для проектов Web API, но представляет собой набор общих c рекомендаций по работе с. Net Базовые приложения - Azure DevOps Pipelines. Ниже приведен пример (выделено мной) :

После того, как вы создали и протестировали свое приложение (не специально для веб-API) , вы можете загрузить выходные данные сборки в Azure Pipelines или TFS, создать и опубликовать sh пакет NuGet, или упаковать выходные данные сборки в файл .zip для развертывания в веб-приложение .

Когда вы читаете в разделе Пакет и доставьте свой код , что publish to a NuGet feed является допустимым вариантом доставки кода, это так. Однако этот метод доставки должен использоваться для результатов библиотечного типа. Команда dotnet publish предназначена для упаковки проекта веб-API и всех его зависимостей в .zip (или папку, если вы укажете эту опцию) при подготовке к командам Web Deploy для экземпляра IIS.

---

---

Оригинальный ответ

---

---

Не вдаваясь в детали того, почему вы хотите создать .nupkg из вашего проекта API.

Вы упоминаете:

Моя единственная проблема с этим заключается в том, что он дает несколько файлов .nupkg вместо одного и что пакеты веб-API не имеют зависимостей dll

Это было MO из dotnet pack в течение некоторого времени в отношении ссылок от проекта к проекту (P2P).

Документация для do tnet pack утверждает это поведение.

Зависимости NuGet упакованного проекта добавляются в файл .nuspe c, поэтому они правильно разрешены при установке пакета. Ссылки между проектами не упакованы внутри проекта. В настоящее время у вас должен быть пакет для проекта, если у вас есть зависимости от проекта к проекту.

Если вы вы хотите иметь больше контроля над файлами, включенными в ваш .nupkg, тогда вам нужно будет вручную создать файл .nuspec и предоставить его команде dotnet pack, как указано в последнем примере в страница документации.

Использование задачи Azure DevOps для do tnet core cli DotNetCoreCLI@2 позволит вам просто указать путь к файлу .nuspec во входных данных. Если вам это не поможет, по вашему вопросу потребуется дополнительная информация.

Answer 2

Моя единственная проблема в том, что он дает несколько файлов .nupkg вместо одного и что пакеты веб-API не имеют зависимостей dll.

I Предположим, у вас есть несколько проектов в одном решении. Давайте назовем проект Web Api A , другие проекты B , C и D ...

1. Так что, если вы хотите упаковать A в пакет nuget, вместо использования projects: '**/*.csproj', мы можем использовать что-то вроде projects: '**/A.csproj'. Тогда он больше не будет упаковывать несколько пакетов nuget.

2. Для зависимостей dll, я думаю, вы имеете в виду ссылки на проекты, такие как Jo sh Gust , упомянутые выше. Для этого это все еще одна открытая проблема о команде dotnet pack. Вы можете отследить эту проблему, чтобы получать уведомления об обновлениях.

Сейчас нам нужно внести изменения в A.csproj, чтобы использовать магию msbuild в качестве обходного пути. Вы можете попробовать Мартина или Звиря обходные пути там. На мой взгляд, они оба помогают в вашей проблеме.

Надеюсь, все вышеперечисленное поможет:)

Update1:

Для редактирования, если вы хотите перевести его в конвейер AZ, вы можете использовать custom команда для вызова пакета. Примерно так:

- task: DotNetCoreCLI@2
  displayName: 'dotnet custom'
  inputs:
    command: custom
    projects: '**/ProjectName.csproj'
    custom: pack
    arguments: '-p:NuspecFile=~/projects/app1/project.nuspec -p:NuspecBasePath=~/projects/app1/nuget'

Вы можете проверить журнал, чтобы убедиться, что он действительно выполнил команду: "C:\Program Files\dotnet\dotnet.exe" pack D:\a\1\s\xxx\xxx.csproj -p:NuspecFile=~/projects/app1/project.nuspec -p:NuspecBasePath=~/projects/app1/nuget. Надеюсь, это то, что вам нужно.

И я не уверен, что мы можем использовать ~ в этой команде, но если она работает локально, вы можете перевести ее в Azure Devops Pipeline, используя мой способ ...

Answer 3

Я бы порекомендовал использовать онлайн-редактор Azure DevOps. Замечательно использовать и набрать скорость (автозаполнение, синтаксис c просмотр, прямой коммит / pu sh).

То, чего вы пытаетесь достичь, можно сделать с помощью шагов:

• do tnet build
• do tnet pack -> укажите нужные проекты для упаковки здесь

- task: DotNetCoreCLI@2
displayName: 'Create packed NuGet files'
inputs:
  command: 'pack'
  packagesToPack: '**/*Api.csproj;!**/*Tests.csproj'
  versioningScheme: 'off'

• nuget pu sh

Нет необходимости в файле nuspe c, если вы добавите несколько полей в свой csproj.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard2.1</TargetFramework>
    <AssemblyName>Withywoods.Selenium</AssemblyName>
    <RootNamespace>Withywoods.Selenium</RootNamespace>
    <ProjectGuid>{08D9DDB8-BF5B-4E45-8E0C-D9AC85ABF020}</ProjectGuid>
    <Authors>devprofr</Authors>
    <Description>Library to ease the use of Selenium web driver and provide testing best practices.</Description>
    <RepositoryUrl>https://github.com/devpro/withywoods</RepositoryUrl>
    <PackageProjectUrl>https://github.com/devpro/withywoods</PackageProjectUrl>
  </PropertyGroup>

У меня есть короткий пример, если вы хотите : pkg.yml

. NET Core и Azure DevOps - отличная комбинация, не стесняйтесь комментировать, если у вас есть какие-либо проблемы!

(На моем Кроме того, я упаковываю проекты библиотек, но не Api, я делаю tnet publi sh на Api, чтобы использовать их как артефакт в конвейерах выпуска.)