Ссылочная библиотека зарегистрирована как другая ссылка на nuget в Nuspec с использованием VS 2017 - PullRequest
Новая
       33

Ссылочная библиотека зарегистрирована как другая ссылка на nuget в Nuspec с использованием VS 2017

0 голосов
/ 08 марта 2019

Итак, у меня есть ссылка на проект B на проект A. Обе они являются стандартными библиотеками .net. Я хочу создать пакет nuget, используя VS 2017. Я просто заполнил Свойства-> Настройки пакета, установив флажок «Создать пакет Nuget при сборке» в проекте А.

Я даже добавил для проекта B 

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <IsPackable>false</IsPackable>
  </PropertyGroup>

Но как только я соберу и создаю пакет nuget для проекта А. Он отображается как Project B - еще одна ссылка на пакет nuget. если я распакую файл nupkg, то в nuspec я смогу увидеть следующие строки 

 <dependencies>
      <group targetFramework=".NETStandard2.0">
        <dependency id="ProjectB" version="1.0.0" exclude="Build,Analyzers" />
        <dependency id="NETStandard.Library" version="2.0.3" exclude="Build,Analyzers" />        
      </group>
    </dependencies>

вы можете видеть, что projectB берется как ссылка на пакет nuget. При установке не удается также сказать "не удается найти ProjectB nuget" Почему это происходит? это ошибка в VS 2017? Я даже добавил ниже настройки в ProjectA, что он должен включать ProjectB как DLL, который работает нормально. Но несмотря на это он также регистрируется как зависимость nuget 

<Target Name="IncludeP2PAssets">
    <ItemGroup>
      <BuildOutputInPackage Include="..\ProjectB\bin\Release\netstandard2.0\ProjectB.dll" />
    </ItemGroup>
  </Target>

мой проект Файл csproj не имеет ссылки на пакет как Project B, как показано ниже, как Projectreference 

  <ItemGroup>
    <ProjectReference Include="..\ProjectB\ProjectB.csproj" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="NETStandard.Library" Version="2.0.3" />
  </ItemGroup>

1 Ответ

0 голосов
/ 09 марта 2019

При упаковке проекта проект со ссылками на проект по умолчанию считается ссылками пакета nuget .Я могу подумать о двух причинах, почему это хорошо.

  1. рекомендуется упаковать одну сборку на пакет
  2. , чтобы упростить процесс разработки для авторов пакетов

Давайте рассмотрим эти две причины

  1. Рекомендуется упаковать одну сборку на пакет

Представьте, что есть какая-то утилита сборки Утилита.dll, и я использую ее в своем пакете, PackageA,Если я добавлю в свой пакет и PackageA.dll, и utlity.dll, но позже создам PackageB, который также содержит utility.dll, возникнут конфликты, если в одном проекте будут использованы как PackageA, так и PackageB, поскольку будут две разные утилиты.dll.,При наличии одной сборки на пакет будут существовать PackageA и PackageB, которые зависят от разных версий пакета утилит, и NuGet может использовать свои правила управления версиями, чтобы выбрать одну.

для упрощения процесса разработки для авторов пакетов

Представьте, что у меня есть PackageB, который зависит от PackageA, и я хочу внести изменение, которое требует изменений как PackageA, так и PackageB.Если PackageB имеет PackageReference на PackageA, это означает, что я должен угадать, какие изменения мне понадобятся в PackageA, чтобы завершить изменения в PackageB, изменить, зафиксировать, упаковать и опубликовать PackageA, а затем изменить PackageB для использования новой версии PackageA.,Однако, если мои предположения о необходимых изменениях в PackageA оказались неверными, мне нужно будет снова изменить, зафиксировать, упаковать, опубликовать PackageA и затем изменить PackageB для использования новой, новой версии.Медленно и мучительно создавать функцию нескольких пакетов при использовании ссылок на пакеты.

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

...