Здесь, кажется, есть несколько недоразумений.
Во-первых, папка 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
, связанном с путями к пакетам.