Ссылка на проект упаковки в nuget: .net core

В настоящее время у меня есть требование, когда у нас есть отдельные сборки для контракта и реализации. После создания пакета nuget и попытки использовать пакет nuget происходит сбой, поскольку диспетчер пакетов не может найти зависимую (контрактную) сборку.

Кажется, это открытая проблема в ядре .net.

https://github.com/dotnet/cli/issues/3959

Не могу понять, почему такая простая вещь не будет работать в ядре .net. Ищем обходной путь для этой проблемы.


.net c# asp.net-core nuget nuget-package-restore
person Signcodeindie    schedule 07.12.2017    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Это просто решить. У вас есть 2 варианта:

A) Упакуйте и опубликуйте все свои проекты как пакеты Nuget:

Вы просто добавляете свои зависимости как ProjectReference в свои основные проекты. И продолжайте разработку, используя ссылки на проекты. Также необходимо упаковать все проекты зависимостей. Если вы хотите опубликовать свои пакеты, используя ту же версию, просто запустите:

dotnet pack -p:PackageVersion=2.1.0 также может добавлять любые другие pack аргументы.

Поскольку во время pack все ProjectReference будут преобразованы в зависимости пакета. И номер version распространяется на весь пакет.

В этом случае исходный основной проект и все его зависимости будут упакованы в Nuget. Теперь вы должны опубликовать ВСЕ. И когда вы захотите установить свой пакет Nuget, он также установит все его зависимости с той же указанной версией.

B) Упакуйте все выходные библиотеки DLL в один пакет Nuget:

Вы можете опубликовать только один проект как пакет Nuget и упаковать все остальные библиотеки DLL в этот пакет. Сначала подавите pack, чтобы преобразовать зависимость от проекта к пакету. Найдите свой ProjectReference и добавьте к нему PrivateAssets="All". Должно выглядеть так:

<ProjectReference Include="yourproj.csproj" PrivateAssets="All" />

И добавьте следующий раздел в свой файл .csproj (в проект, который должен быть упакован), чтобы упаковать DLL-зависимости, измените имя DLL и версия платформы в <PackagePath>.

<ItemGroup>
  <_PackageFiles Include="$(OutputPath)\yourproj.dll">
    <BuildAction>None</BuildAction>
    <PackagePath>lib\net5.0</PackagePath>
  </_PackageFiles>
</ItemGroup>
person Major    schedule 10.10.2020
comment
Б) Теги ‹BuildAction› и ‹PackagePath› не распознаются IDE - person Roman Prykhodko; 16.10.2020
comment
У вас есть проект .Net Core? У меня отлично работает с .Net Core и .Net5. - person Major; 16.10.2020
comment
у меня ядро ​​3.1 - person Roman Prykhodko; 16.10.2020
comment
Что касается метода А - в чем ключевой момент этого метода? Я может и не понял, но дотнет пак не включает ссылку(( - person Roman Prykhodko; 16.10.2020
comment
Я попробовал это с проектом .NET Core 3.1 с использованием VS 2019, и вариант B) отлично работал. У вас есть VS 2019? Также вы можете добавить дубликат ProjectReference или скопировать узлы XML в неправильные места... Я думаю, вы пропустили часть «ItemGroup»! - person Major; 16.10.2020
comment
Да, «пакет dotnet» не будет включать в себя ссылки на проекты. Но он АВТОМАТИЧЕСКИ преобразует ProjectReference в PackageReference. Таким образом, вместо использования вывода проекта ваш пакет будет зависеть от другого пакета Nuget. Таким образом, вы должны УПАКОВАТЬ все упомянутые проекты и ПУБЛИКОВАТЬ все. И когда вы захотите установить исходный пакет Nuget, он загрузит все зависимые пакеты. Локально это ссылки на проекты. Итак, вариант А) — это совершенно другой подход! Мое решение поможет с версией. Поскольку ссылка на пакет также зависит от конкретной версии. - person Major; 16.10.2020
comment
Давайте продолжим это обсуждение в чате. - person Major; 16.10.2020

arrow_upward
1
arrow_downward

Прочитав документацию, я понял, что ядро ​​.net не рекомендует ссылаться на проект, вместо этого советует использовать ссылку на пакет. Это упоминается в заголовке описания в следующем документе.

https://github.com/dotnet/docs/blob/master/docs/core/tools/dotnet-pack.md

Я опубликовал свою контрактную сборку в пакете nuget и использовал ее в реализации как пакет nuget.

person Signcodeindie    schedule 08.12.2017