Лучшая практика для включения консольного приложения в NuGet

Я занимаюсь разработкой библиотеки с открытым исходным кодом, которая в основном состоит из одного проекта библиотеки классов, нацеленного на.NET Standard 2.0. Кроме того, я также реализовал консольное приложение, которое представляет собой CLI для этой библиотеки. Консольный проект (по историческим причинам) предназначен только для.NET Framework 4.6.2.

Теперь мне интересно, что было бы лучшим способом сделать это консольное приложение доступным для сообщества. На самом широком уровне я вижу две возможности:

  1. Поставьте консольное приложение как отдельный NuGet.
  2. Поставьте консольное приложение в том же NuGet, что и библиотека классов, потому что это всего лишь небольшая надстройка и не оправдывает собственный пакет.

Исторически я использовал второй подход, но, учитывая, что библиотека классов может использоваться в сценарии с множественным таргетингом, я больше не уверен. Может быть, лучше разделить консольное приложение на собственный NuGet, чтобы его зависимость от полной платформы.NET была ясной.

В любом случае, мне интересно, где находится консольная exe-структура в файловой структуре NuGet. Исторически я ставлю это под tools\net462 но комментарий о tools папка на этой странице сделала меня небезопасным:

Сценарии и программы Powershell, доступные из консоли диспетчера пакетов

Я не обязательно представляю, как кто-то использует CLI из диспетчера пакетов. Скорее это будет использоваться как отдельный exe где-то какая-то оболочка.

Источник

3 ответа

Решение

В общем, NuGet предназначен только для доставки библиотек классов (обратите внимание на формулировку "если ваша библиотека...").

Вместо этого используйте Chocolatey для развертывания приложений командной строки и графического интерфейса в Windows. Он имеет интерфейс командной строки, который можно использовать для простой установки и обновления приложений. Это не NuGet, но использует аналогичный метод для упаковки и развертывания приложения.

Есть также менеджеры пакетов для других платформ:

  1. apt-get (для Debian/Ubuntu/Mint)
  2. Заваривать (для MacOS)
  3. RPM (для Fedora/Red Hat)

ПРИМЕЧАНИЕ. Как отметил Мартин Уллрих в комментариях, теперь есть способ развертывания CLI инструмента сборки с NuGet, который в первую очередь предназначен для сценариев развертывания с непрерывной интеграцией.

Источник

Это решение, которое, кажется, соответствует вашим потребностям. Вы можете создать расширение командной строки для dotnet инструменты. подобно dotnet ef Вы можете создать dotnet myAwesomeTool команда. Единственное, что вам нужно сделать, это следующее:

Создайте консольное приложение и добавьте следующий код в ваш.csproj

<PackageId>Company.MyAwesomeTool</PackageId>
<AssemblyName>dotnet-myAwesomeTool</AssemblyName>
<PackageType>DotnetCliTool</PackageType>
<GeneratePackageOnBuild>True</GeneratePackageOnBuild>

Постройте решение, и вы найдете пакет nuget в папке bin. Этот пакет nuget можно распространять, и после его установки вы можете запустить dotnet myAwesomeTool в проектах, где установлен nuget. Работает как шарм для меня =)

Чтобы установить его на другие проекты, добавьте его в csproj:

<ItemGroup>
  <PackageReference Include="company.MyAwesomeTool" Version="1.0.0" />
</ItemGroup>
<ItemGroup>
  <DotNetCliToolReference Include="company.MyAwesomeTool" Version="1.0.0" />
</ItemGroup>

Для получения дополнительной информации: https://blog.maartenballiauw.be/post/2017/04/10/extending-dotnet-cli-with-custom-tools.html

Источник

Со временем появляются другие решения...

https://docs.microsoft.com/nl-nl/dotnet/core/tools/global-tools-how-to-create

      <PackAsTool>true</PackAsTool>
<ToolCommandName>botsay</ToolCommandName>
<PackageOutputPath>./nupkg</PackageOutputPath>
Источник
Другие вопросы по тегам