How to Create a CLI in .NET

Many companies we work for have command line applications, whether it's to access certain services or to perform specific company operations.

Here, we are going to see how to create these applications in .NET in a very simple way and without extra dependencies. 

1- What is the Command Line (CLI) and Why Should You Use It?

A CLI or command line interface is a way to interact with your system via text through the terminal, whether that's CMD, PowerShell in Windows, iTerm in Mac, or any of the 200 terminal options you might have installed in Linux. The important thing is, it is a text interface, without buttons or dropdown menus. 

The idea of every CLI is that you run programs and scripts by typing commands that the system can execute. 

I understand everyone reading this has interacted with a CLI, but this is how git or docker work, for example. Even though both have graphical interfaces, the speed and the option to automate multiple commands in scripts make their CLIs very popular not just on servers but also on desktops. 

2 - Creating a CLI Application in .NET

Within the .NET ecosystem, we have a very easy and straightforward way to create command line applications and install them on our machine or any other. 

For this, we need two things:

• The .NET CLI, which you have installed if you already have .NET on your machine

• The application you want to turn into a CLI, in our case, we will use the application from the post "Create Intuitive User Interfaces in the Console with Spectre" (https://www.netmentor.es/entrada/cli-interfaces-spectre-console)

With this, you have almost everything, because the process is very simple:

First, we need to edit the .csproj file to add three properties inside the property group

<PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <PackAsTool>true</PackAsTool> 👈
    <ToolCommandName>netmentor-deploy</ToolCommandName>👈
    <PackageOutputPath>./nupkg</PackageOutputPath>👈
</PropertyGroup>

These 3 properties mean the following:

• PackAsTool: Allows you to package the project as a tool

• ToolCommandName: We indicate the command line command that will invoke our code.

• PackageOutputPath: when we package the project, a NuGet package is created, and that package is what gets installed on your machine.

This means that in the company, we can have our command line packages as NuGet packages and install them very easily. 

To do this, the first step is to package the code with the following command:

dotnet pack

This command generates a NuGet package in the specified folder, and we could upload it to NuGet and install from there, but to simplify we will install it locally.

We just need to run this command:

dotnet tool install --global --add-source .\nupkg\ PopularLibraries.SpectreExample

//response

You can invoke the tool using the following command: netmentor-deploy
Tool 'popularlibraries.spectreexample' (version '1.0.0') was successfully installed.

If you were installing from NuGet, you wouldn’t need to specify the path property. 

In any case, we now have the program installed locally as a CLI, and now we just need to run it using the command we specified in ToolCommandName:

And we see that it runs correctly. 

Of course, to remove the CLI, just run the uninstall command:

 dotnet tool uninstall --global PopularLibraries.SpectreExample

//response
Tool 'popularlibraries.spectreexample' (version '1.0.0') was successfully uninstalled.

3 - Do I Need a CLI?

Knowing whether you need a CLI is a bit more complicated, as it depends on the type of work you need to do and how you want to accomplish it.

In many companies, the use of an internal CLI is very common; the features can vary. It might be used to access Kubernetes logs, or for more complex actions like receiving a temporary user account that allows you to connect to a database, it all depends on what you want and need to do. Every company is quite unique in this respect. 

In the case of a developer who today might be called an indie hacker, they could have a CLI to deploy each of their applications or websites, where you can store certain key information in the project folder, independent for each project, run your CLI, and deploy automatically.

You might say that doesn’t have CI/CD, etc., but it is by far the fastest way when working solo.