.Net Standard 2.0 Создание пакета NuGet, включая проекты в одном решении и пакеты NuGet

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

Предполагая, что у меня есть решение со следующей структурой:

  • DotNetSolution

    • DotNetProjectReferencingSubProjects (this project is the one for generating nuget package)
    • ПроектА
    • ПроектБ

    • ПроектC

      -NugetPackageInsideProjectC

Объяснение структуры

Идея этого проекта состоит в том, чтобы извлекать документы из общедоступных/частных облаков, но я хотел сделать вызов прозрачным для вызывающего абонента, поэтому я разработал такое решение:

  • CloudHandler.Library.csproj
  • CloudHandler.Services.Factory.csproj
  • CloudHandler.Plugin.Aws.csproj
  • CloudHandler.Plugin.PrivateCloud1.csproj
  • CloudHandler.Plugin.Gcp.csproj
  • CloudHandler.Plugin.PrivateCloud2.csproj

CloudHandler.Library.csproj ссылается на CloudHandler.Services.Factory.csproj

Ссылки на CloudHandler.Services.Factory.csproj

  • CloudHandler.Plugin.Aws.csproj
  • CloudHandler.Plugin.PrivateCloud1.csproj
  • CloudHandler.Plugin.Gcp.csproj
  • CloudHandler.Plugin.PrivateCloud2.csproj

CloudHandler.Plugin.Aws.csproj ссылается на AWSSDK.S3

Когда я упаковываю CloudHandler.Library или даже CloudHandler.Services.Factory, проект, использующий эту ссылку, выдает исключение, потому что не может найти ссылку AWSSDK.S3.

Как упаковать DotNetProjectReferencingSubProjects, включая все ссылки? (проекты и пакеты NuGet, на которые ссылаются эти проекты?)

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

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


.net c# nuget-package .net-standard-2.0
person Vinicius Andrade    schedule 21.10.2019    source источник
comment
можешь уточнить? он почти никогда не предназначен для DotNetProjectReferencingSubProjects непосредственно связывать ProjectA, ProjectB и ProjectC; обычно все они будут собственными nupkg, а DotNetProjectReferencingSubProjects просто рекламирует зависимость пакета от других. Это правильно и нормально. Если это не то, что вы хотите, вы можете быть более конкретным? (и, конечно же, вам нужно будет упаковать и развернуть их все)   -  person Marc Gravell    schedule 21.10.2019
comment
Я отредактировал вопрос, не знаю, поможет ли понять. обычно все они были бы их собственными nupkg. (Я тоже читал об этом, но идея состоит в том, чтобы инкапсулировать его)   -  person Vinicius Andrade    schedule 21.10.2019
comment
С этим обновлением похоже, что проблема, с которой вы боретесь, — это транзитивные цепочки зависимостей; эта проблема была в значительной степени решена полностью при переходе на проекты в стиле SDK; вы используете проект в стиле SDK? то есть csproj нового стиля? (что отлично подходит для .NET Framework, а не только для .NET Core)   -  person Marc Gravell    schedule 21.10.2019
comment
Я никогда не слышал об этом, что вы мне сказали, но я просто погуглил, и, видимо, проект основан на стиле sdk.   -  person Vinicius Andrade    schedule 21.10.2019
comment
проект, который использует эти ссылки? если да: он должен автоматически развернуть дерево зависимостей, предполагая, что вы используете что-нибудь вроде последних инструментов сборки; поэтому вы никогда не должны увидеть проблему с AWSSDK.S3, если дерево где-то берет эту зависимость   -  person Marc Gravell    schedule 21.10.2019
comment
Извините, что так долго не отвечал, я пытался загрузить его на git, github.com/viniandrade00/cloudHandler   -  person Vinicius Andrade    schedule 21.10.2019
comment
в порядке; Я клонировал это, запустил dotnet restore и dotnet build, и все работает... вы видите что-то другое?   -  person Marc Gravell    schedule 21.10.2019
comment
на данный момент нет. У меня проблема, когда я создаю пакет nuget из CloudHandler.Library и ссылаюсь на него в другом проекте. говоря, что не удалось найти ссылку AWS   -  person Vinicius Andrade    schedule 21.10.2019
comment
совет: включите проект, который действительно показывает проблему; Я создал консольный исполняемый файл с зависимостью от CloudHandler.Library, и at прекрасно видит FileStorage (который исходит от плагина AWS прямо на другом конце дерева). Итак: можете ли вы показать проект, который действительно демонстрирует проблему, с которой вы столкнулись?   -  person Marc Gravell    schedule 21.10.2019
comment
и если я смотрю на вывод бина: у меня есть AWSSDK.Core.dll и AWSSDK.S3.dll - похоже, это сработало   -  person Marc Gravell    schedule 21.10.2019
comment
но вы ссылались на проект? Или вы создали пакет nuget?   -  person Vinicius Andrade    schedule 21.10.2019
comment
Я загрузил пример проекта с ошибкой github.com/viniandrade00/cloudHandler/ капля/мастер/   -  person Vinicius Andrade    schedule 21.10.2019
comment
переход на ссылку на пакет nuget (в частное хранилище пакетов); с непосредственной зависимостью все в порядке, но вам нужен nupkg для всех остальных слоев — вам нужно создать CloudHandler.Services.Factory nupkg и т. д.; еще раз, из моего самого первого комментария: все они были бы своими собственными nupkg   -  person Marc Gravell    schedule 21.10.2019

Ответы (1)


arrow_upward
1
arrow_downward

Транзитивные зависимости работают нормально, но вам нужно создавать (и загружать/управлять) пакеты для каждого уровня; недостаточно просто создать nupkg для CloudHandler.Library — он нужен для всего в дереве.

При этом это делается локально с использованием частного кеша пакетов, который имеет:

  • CloudHandler.Domain.Plugins.Aws.1.0.0.nupkg
  • CloudHandler.Domain.Plugins.Azure.1.0.0.nupkg
  • CloudHandler.Domain.Plugins.Gcp.1.0.0.nupkg
  • CloudHandler.Domain.Providers.1.0.0.nupkg
  • CloudHandler.Infrastructure.Contracts.Plugin.1.0.0.nupkg
  • CloudHandler.Infrastructure.Contracts.Provider.1.0.0.nupkg
  • CloudHandler.Library.1.0.0.nupkg
  • CloudHandler.Services.Factory.1.0.0.nupkg

то я могу создать тестовый проект с:

  <ItemGroup>
    <PackageReference Include="CloudHandler.Library" Version="1.0.0"/>
  </ItemGroup>

и все работает корректно. Выходные данные сборки включают, среди прочего, AWSSDK.Core.dll и ASWWDK.S3.dll. В тестовом проекте видны все типы в расширенном дереве зависимостей, несмотря на то, что он имеет прямую зависимость только от CloudHandler.Library.

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

person Marc Gravell    schedule 21.10.2019
comment
Спасибо, Марк. Я попытаюсь изменить свой проект и рабочий процесс devops, чтобы следовать вашим рекомендациям. - person Vinicius Andrade; 21.10.2019
comment
Есть ли у вас лучший подход к созданию пакетов nuget для такого проекта в devops? - person Vinicius Andrade; 30.01.2020
comment
@ViniciusAndrade с проектами в стиле SDK (csproj в новом стиле), все это происходит автоматически... - person Marc Gravell; 30.01.2020
comment
у вас есть какие-либо документы или статьи по этому поводу? - person Vinicius Andrade; 30.01.2020
comment
@ViniciusAndrade пакет dotnet , или <GeneratePackageOnBuild>true</GeneratePackageOnBuild> и dotnet build; или посмотрите в левом меню на этой странице, как сделать то же самое с MSBuild - person Marc Gravell; 30.01.2020