Выпуск пакетов nuget, имеющих ссылку на другие сборки

Question

Выпуск пакетов nuget, имеющих ссылку на другие сборки

2

Я пишу API, с некоторыми сборками, я бы хотел, чтобы эти сборки были опубликованы в виде пакетов nuget (это на самом деле сделано).

Это разделено на:

ChickenAPI.Core("ядро", связанное с приложением, логгером, контейнером IoC, некоторыми математическими утилитами, абстрактным конвейером событий...)
ChickenAPI.Data (все уровни доступа к данным, DTO и абстрактный "репозиторий")
ChickenAPI.Enums (все игровые перечисления)
ChickenAPI.Game (все связанные с игрой вещи, игровые объекты, компоненты, события...)
ChickenAPI.Packets (все структуры пакетов, используемые в игре)

Я хотел бы выпустить каждый из них на nuget, но некоторые зависят от некоторых других (например, Game зависит от Core, Data, Enums и Packets, Data зависит от Enums...)

Должен ли я связать их с локальной ссылкой или я должен связать каждую из их ссылок с соответствующими "удаленными пакетами"? Вот ссылка на соответствующий API: https://github.com/BlowaXD/ChickenAPI/

Blowa 19 март 2019, в 02:02

Источник

Теги:

c#

.net

nuget

nuget-package

2 ответа

0

Мне удалось сделать это с помощью файлов Nuget.nuspec.

Вот XML, который я использую, чтобы построить его

<?xml version="1.0" encoding="utf-16"?>
<package xmlns="http://schemas.microsoft.com/packaging/2011/08/nuspec.xsd">
  <metadata>
    <id>ChickenAPI.Game.Extensions</id>
    <version>$(VERSION_OF_CHICKEN_API)</version>
    <authors>BlowaXD</authors>
    <projectUrl>http://github.com/BlowaXD/ChickenAPI</projectUrl>
    <iconUrl>https://raw.githubusercontent.com/BlowaXD/ChickenAPI/develop/docs/_media/logo_256.png</iconUrl>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>ChickenAPI.Game.Extensions is an collection of useful methods to manage game objects</description>
    <summary>ChickenAPI is an API for Nostale Private Servers</summary>
    <copyright>Copyright  BlowaXD 2019</copyright>
    <language>en-US</language>
    <dependencies>
      <dependency id="ChickenAPI.Game" version="$(VERSION_OF_CHICKEN_API)" />
    </dependencies>
  </metadata>
</package>

и вот командная строка, которую я использую для сборки пакета:

dotnet pack -c Release src/ChickenAPI.Core --output nupkgs /p:NuspecFile=chickenapi.core.nuspec /p:NuspecBasePath=.

Благодаря этому объявляются пакеты nuget, которые зависят друг от друга в одном решении другого вопроса.

Этот запрос на извлечение покажет, как я решил проблему (с каждой деталью): https://github.com/BlowaXD/ChickenAPI/pull/96

Blowa 19 март 2019, в 07:23

Ещё вопросы

Jon Skeet · Accepted Answer · 2019-03-19T06-05-00.000Z

Для этого вам не нужно использовать файл nuspec - обычные файлы проекта .NET Core SDK работают нормально.

Используйте <ProjectReference> для ссылки на один проект из другого, и это будет частью зависимостей в пакете NuGet.

Например:

ChickenApi.Core.csproj

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <!-- TODO: Extra NuGet properties, e.g. Description, Authors -->
    <Version>1.0</Version>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>
</Project>

ChickenApi.Game.csproj

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <!-- TODO: Extra NuGet properties, e.g. Description, Authors -->
    <Version>1.0</Version>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="..\ChickenApi.Core\ChickenApi.Core.csproj" />
  </ItemGroup>
</Project>

Если вы запустите dotnet pack -c Release для решения, это создаст два файла nupkg, по одному для каждого проекта. Просто опубликуйте оба пакета, и все будет хорошо.

Однако следует помнить одну вещь: если вы измените ChickenApi.Core и затем ChickenApi.Core от этих изменений в ChickenApi.Game, вы должны опубликовать оба пакета (с обновленными номерами версий). Легко забыть изменить версию ChickenApi.Core и опубликовать новую версию ChickenApi.Game которая утверждает, что она все еще ссылается на 1.0, но зависит от изменений, которых нет в опубликованной версии 1.0.

Оба работают, однако ваше решение гораздо проще в управлении. (Было так очевидно, что я даже не пробовал) Спасибо!