Пакет dotnet для проекта .NET Core создает файл .nupkg с исходниками - PullRequest
0 голосов
/ 05 января 2019

У меня есть простой проект библиотеки классов .NET Core 2.1, и мне нужно упаковать его как пакет Nuget. Для этого я использую эту команду:

dotnet pack <project>.csproj --output <outputFolder> /p:Configuration=Release

Но я получаю это предупреждение:

C:\Program Files\dotnet\sdk\2.1.502\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets(202,5): warning NU5100: The assembly 'obj\Release\netcoreapp2.1\<assembly>.dll' is not inside the 'lib' folder and hence it won't be added as a reference when the package is installed into a project. Move it into the 'lib' folder if it needs to be referenced.

Я понимаю, что папки lib предназначены для таргетинга на несколько фреймворков, но я этого не хочу. Я хочу использовать только .NET Core 2.1.

В конце создается мой .nupkg файл, но он имеет весь исходный код (не знаю почему), и при использовании в других проектах они не могут ссылаться на сборки, потому что они находятся в папке bin\Release\netcoreapp2.1 .

Я видел несколько руководств по созданию пакетов Nuget из проектов .Net Core, и ни в одном из них не упоминается что-либо, связанное с папками lib.

Мне нужно понять, если чего-то не хватает или я что-то не так делаю.

Спасибо.

Редактировать: добавлен файл проекта и файл .nuspec

Файл проекта:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <Company>xxx</Company>
    <RootNamespace>xxxx</RootNamespace>
    <Product>xxxx</Product>
    <Authors>xxxx</Authors>
    <NuspecFile>xxxxx.nuspec</NuspecFile>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="AutoMapper.Extensions.Microsoft.DependencyInjection" Version="5.0.1" />
    <PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.1.4" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Relational" Version="2.1.4" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.1.4" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="2.0.3" />
  </ItemGroup>

</Project>

.nuspec Файл:

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
  <metadata>
    <id>xxxxxx</id>
    <version>1.0.0</version>
    <title>xxxx</title>
    <owners>xxxx</owners>
    <description>xxxx</description>
    <authors>xxxx.</authors>
    <copyright>Copyright 2019 xxxx.</copyright>
    <summary>xxx is a common code library for internal projects.</summary>
  </metadata>
</package>

1 Ответ

0 голосов
/ 05 января 2019

Здесь, кажется, есть несколько недоразумений.

Во-первых, папка lib в nupkg предназначена не для многоцелевого таргетинга, а для всех библиотек, входящих в сборку. Если ваш пакет поддерживает только один целевой псевдоним (TFM), тогда ваша nupkg будет иметь только одну папку в lib, например lib/netstandard2.0/MyLib.dll или, возможно, lib/netcoreapp2.1/MyLib.dll, если ваше приложение использует API, которые являются частью Среда выполнения .NET Core 2.1, но не стандартная. Если в вашем проекте используются только API-интерфейсы, являющиеся частью netstandard, то нет смысла ориентироваться на netcoreapp, и у него есть потенциальные проблемы, которые могут вызвать проблемы в будущем, даже если сегодня он работает нормально.

Во-вторых, простая библиотека классов (для меня это означает, что проект содержит только файлы .cs и не содержит файлов содержимого, нет файла сборки, пакет будет содержать только файлы DLL и собственные файлы NuGet) не должен знать ничего о том, что внутри nupkg. Еще более сложным проектам, которые многоцелевые, не нужно заботиться о папке lib при использовании проекта в стиле SDK. Просто укажите ваши целевые TFM в элементе <TargetFrameworks> и позвольте SDK упаковать сам nupkg. Он знает, что делать. Если вы что-то сделали в своем csproj, чтобы попытаться перевести выходную dll в другое место внутри nupkg, это скорее вызовет проблему, чем улучшит ситуацию.

Не видя вашего .csproj, я не могу догадаться, что вы могли бы сделать, чтобы получить это предупреждающее сообщение на упаковке, но, как я уже сказал, совершенно новый dotnet new classlib упаковывается просто отлично, и если ваш проект содержит только файлы кода вам не нужно ничего в csproj, связанном с путями к пакетам.

...