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

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

1 голос
/ 21 октября 2019

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

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

  • DotNetSolution

    • DotNetProjectReferencingSubProjects (этот проект предназначен для создания пакета nuget)
    • ProjectA
    • ProjectB

    • ProjectC

      -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. Думая о поддержании проекта в будущем, кому-то, не имеющему знаний, будет трудно это понять.

1 Ответ

1 голос
/ 21 октября 2019

Переходные зависимости работают нормально , но вам нужно создавать (и загружать / управлять) пакеты для каждого слоя ;недостаточно просто создать 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.

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

...