Best practice to include console app in NuGet

Question

I'm developing an open-source library which mainly consists of one class-library project targeting .NET Standard 2.0. On top of that, I've also implemented a console app which is the CLI to this library. The console project (for historic reasons) only targets .NET Framework 4.6.2.

Now I wonder what would be the best practice in order to make this console app available to the community. On the broadest level, I see two possibilities:

1. Ship the console app as a separate NuGet.
2. Ship the console app in the same NuGet as the class library because it's just a minor add-on and does not justify an own package.

Historically, I've been using the second approach but considering that the class library can be used in a multi-targeting scenario, I'm not sure anymore. Maybe it's cleaner to separate the console app in a NuGet of its own so that it's dependency on the full .NET framework is clear.

Either way I wonder where the console exe belongs to in the file structure of the NuGet. Historically, I've been putting it under tools\net462 but a comment about the tools folder on this page made me insecure:

Powershell scripts and programs accessible from the Package Manager Console

I'm not necessarily imagining someone using the CLI from the Package Manager Consoler. Rather it would be used as stand-alone exe somewhere is some shell.

Answer 1

In general, NuGet is meant only for delivering class libraries (note the wording "if your library...").

Use Chocolatey instead for deploying command-line and GUI apps to Windows. It has a CLI that can be used to easily install and update applications. It is not NuGet, but uses a similar method to package and deploy the app.

There are also package managers to target other platforms:

1. apt-get (for Debian/Ubuntu/Mint)
2. Brew (for MacOS)
3. RPM (for Fedora/Red Hat)

NOTE: As Martin Ullrich pointed out in the comments, there is now a way to deploy build tool CLIs with NuGet, which is primarily meant for continuous integration deployment scenarios.

Answer 2

When time pass by, other solutions come available...

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

<PackAsTool>true</PackAsTool>
<ToolCommandName>botsay</ToolCommandName>
<PackageOutputPath>./nupkg</PackageOutputPath>

Answer 3

Ther is a solution that seems to fit your needs. You can create a command line extension for the dotnet tools. Like dotnet ef you can create a dotnet myAwesomeTool command. The only thing that you need to do is the Following:

Create a console application and add the following code to your .csproj

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

Build the solution and you will find a nuget package in your bin folder. This nuget package can be distributed and when you have installed it, you can run dotnet myAwesomeTool in the projects where the nuget is installed. Works like a charm for me =)

To install it on other projects, add this to the csproj:

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

For more infos: https://blog.maartenballiauw.be/post/2017/04/10/extending-dotnet-cli-with-custom-tools.html