Различия между nuget-упаковкой csproj vs. nuspec

Недавно я начал упаковывать пакеты nuget из нескольких моих проектов. Сначала я начал с приложения Package Explorer. Это хороший инструмент, но он менее полезен, если вы выполняете непрерывную интеграцию. Затем я просмотрел спецификацию файла шаблона nuspec и передачу измененных данных, например. номер версии, в качестве аргументов командной строки. Позже я задавался вопросом, как определить зависимости пакета nuget. Как выясняется, nuget.exe уже делает это на основе package.config, если вы укажете csproj. Кроме того, он извлекает релевантные данные, такие как "Автор", "Версия", "Авторское право" прямо из информации о сборке. Сейчас мне не хватает возможности указать licenseUrl в командной строке. Но я хотел, чтобы этот вопрос был более общим. И поэтому я спрашиваю:

Каков предпочтительный способ упаковки пакетов nuget?

Ответы

Ответ 1

Вот малоизвестный факт: вы можете комбинировать оба! Направьте файл csproj и убедитесь, что в одном каталоге есть файл nuspec с тем же именем, что и файл csproj. NuGet объединит их во время создания пакета.

Итак, кратко: target <ProjectName>.csproj, необязательно добавьте соответствующий файл tokenized <ProjectName>.nuspec, который будет использоваться в качестве метаданных NuGet.exe.

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

Ответ 2

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

https://docs.nuget.org/create/creating-and-publishing-a-package

Вы можете указать любое из свойств, включая licenseUrl, используя параметр Properties для nuget pack

nuget pack -properties licenseUrl=http://blah

Ответ 3

С .csproj для Visual Studio 2017 вам не нужен файл .nuspec. Фактически вы можете добавлять значения непосредственно к вашему csproj, и он их поднимет.

Щелкните правой кнопкой мыши проект в Visual Studio, Edit xxxxx.csproj. Блокнот отлично работает.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <Version>1.0.1</Version>
    <authors>Subtracts</authors>
    <TargetFrameworks>netstandard1.6;net452</TargetFrameworks>
    <AssemblyName>Checkout.net</AssemblyName>
    <PackageId>Checkout.net</PackageId>

...

</Project>

p.s. Поскольку у меня нет достаточной репутации для комментариев, я оставляю ответ вместо комментария к ответу Ксавьера.:)

Ответ 4

С .NET Core по состоянию на февраль 2018 года вам нужно будет предоставить файл .nuspec для чего-то большего, чем основные свойства файла спецификации.

Но dotnet pack не будет использовать файл .nuspec если вы не добавите <NuspecFile>relative path to nuspec</NuspecFile> в файл .csproj.

См. Https://github.com/dotnet/cli/issues/2170.

Большинство пакетов теперь можно сделать без файла .nuspec. То, что нужно посмотреть, это зависимости. Вам может понадобиться добавить элемент PrivateAssets к некоторым инструментам, таким как msbump и um, например SpecFlow.

<PackageReference Include="msbump" Version="2.3.2">
  <PrivateAssets>all</PrivateAssets>
</PackageReference>

Это останавливает "зависимость" пакета от зависимостей вашего пакета.

Также стоит прочитать об указании версий наиболее гибким способом.

https://docs.microsoft.com/en-us/nuget/consume-packages/dependency-resolution#floating-versions

И синтаксис диапазона.

https://docs.microsoft.com/en-us/nuget/reference/package-versioning#references-in-project-files-packagereference