.NET Core's Command Line

Don't Bore Us Get to the Chorus

For those who are like me and might want to skip over to the things you want, here's a quick jump list.

Topic	Section Heading
Accessing the CLI	Shell? Like Powershell, Right?
First steps in the command line	All Right, I opened it, now what?
The .NET CLI vs. plain command line	So this is the .NET CLI?
How to use --help and the .NET CLI	HELP! I NEED SOMBODY!
Where do I go from Here?	Great! Am I coding now?

The Command Line

When I first started to learn how to write code, there was this unshaken sense that I would never be able to do it for real. So many preconceptions about how developers work exist, and they exist for a reason. One of the major barriers to my journey was an absolute, unwarranted, but very real fear of the command line. Why can't I just use my File Explorer? How come I can't click "File => New => C# Class" in Visual Studio and have it show up magically? It turned out, it's absolutely possible to never use the command line to develop .NET. It's been a few years since I got started, and since then I've realized that the command line, is a wonderful place to work, even for scaredy cats like me.

What changed was how much I used Linux. While Ubuntu and related distros have made incredible strides to being an out of the box best in class experience, for most users the command line will still become a part of your day to day life. (sudo apt-get update anyone?) While I still use file system explorers like Finder, File Explorer, and Nautilus, often times it's just far, far simpler to reach out and touch something with a shell. (I got dad jokes. Not sorry. 🧀🧀)

Shell? Like Powershell, Right?

Right! And not right, sort of. Powershell is a command line shell application. On a Mac, the most common is "Terminal". If you're on Linux, chances are you know what your shell is, but if you're new to it, it's probably also called "Terminal" or "Konsole".

What these application have in common is that you don't click around to get work done. You type everything out. It sounds exhausting, but trust me, the process becomes and absolute treat after a while and will feel faster than using your mouse. It may not make you a 10x developer though. Or maybe it will, I don't know, green text on a black screen makes me feel more productive.

All Right, I opened it, now what?

Jumping right in! I love it!

I by no means am a CLI expert, but these commands I use every day, all day.

• mkdir
  • mkdir NewDirectory
  • Make directory. Makes a new folder for you to store all your cool new things in.
  • Works in Powershell as well, but if you really want to get fancy, PowerShell's New-Item is very flexible. It's done using the same thing we id before, but using parameters.
    • New-Item -Name NewDirectory -ItemType Directory
    • In CLIs, it is common to express a command (New-Item) and then pass parameters (-Name, -ItemType) with values (NewDirectory, Directory). For mkdir, the parameter and the value of it are NewDirectory.
• cd
  • cd .\NewDirectory
  • cd in most shells means "change directory". In CLIs, folders are termed "directories". The above will change directory, using the location you're currently at (.) and looking for the directory dev (because of the \dev telling it where to go).
  • Also works in Powershell!
• touch
  • touch NewFile.txt
  • Tells your system to make a new file. It's used like
  • If you're in Powershell, it's a little different. New-Item NewFile.txt will get you sorted.
• rm
  • rm NewDirectory
  • This removes things. For most systems, it will not remove directories that have things inside of them, instead asking you to confirm. If you want to skip confirming it, you can use -rf as a parameter. This adds two flags for "recursive" and "force", which will tell the system "Yes, I know there's stuff inside there, and there are nested folders, just get rid of it". And poof, files are gone forever. (To make this work, you'll need to cd .., which will move directories to the parent directory.)

What are those dots all about?
As you become accustomed to the command line, you wil find out that typing a lot is a real pain. You can be way more efficient using a command line, but there is a lot more typing. The dots are designed to help you out. A single dot means the current directory. Double dots will mean the parent directory. If you use something like cd ..\..\, you will move "up" two directories.

So this is the .NET CLI?

Not quite, but this will be helpful. But, now you know enough to get started for sure.

So, while you're at your terminal, go ahead and check out if the .NET CLI is installed. Put on your favorite hacker shades/hater blockers and run the following (type it in the command line and press enter):

dotnet --version

If .NET Core is installed, this will print the version of what is installed. If you get an error, PANIC right away. Then breathe and head over to Microsoft's page here and they will get you sorted out. I'll wait, I have time. I'd tell you how to install it, but frankly they do a better job anyway. You might even like their tutorials better, they've gotten quite good.

If, however, numbers printed in the output (that bit under where you entered your commands) got some numbers then you're all set and it's installed. One of the things that will really help in your journey with the command line is knowing that help is only five keystrokes away with most commands. Let's see what I mean.

HELP! I NEED SOMBODY!

Run the following:

dotnet --help

Look at everything that printed out. That's a lot of information, and I'm assuming you're following along. We're a few steps away from being able to finally work with this tool, but let's take a deep breath and look at what it just spit out for us because this is one of the things that I've found that this team does really, really well.

I'm going to do a little skipping here because there are a boatload and a half of tools available in this tool. Let's focus on the SDK commands for now.

A few lines down, you should see the following:

Usage: dotnet [sdk-options] [command] [command-options] [arguments]

This is how the application is telling you to run the various commands that make the operation work and the order in which you need to input them. First, you enter any options you will need, then the command, the command options, and any arguments the command options will need.

Under this line is a series of useful things that are broken out into sections. sdk-options has a list of what you can put in front of your commands to have them do a few extra things on top of what they already will do. Under that is a section labelled SDK Commands that lists the commands that can be run. "But where are the command options? Where's the arguments? What do these things all need to run?" Well, this is where the --help command really does it's work. If you head back over to the command line, you can call any of the commands for the SDK with --help, and the application will let you know what you need to run it.

For example:

dotnet new --help

Will run the application dotnet, with the command new with the option --help and print out instructions on how to use the command as well as a list of solutions that you can make right out of the tool. These templates are built into Visual Studio, so if you're like me you might see some old friends and some new ones.

Great! Am I coding now?

Well, if we're not careful we're going to make a mess. Let's put this all together into something interesting, after all you've been reading a lot of boring stuff that may not have been fun.

Now, maybe you're like me and you've been copying and pasting things so far. That's fine, but let's really, really work on not doing that for this next part. It will help you get used to how the CLI works if you're typing now. It's a lot to ask, but give it a shot.

First, let's figure out where we are:

ls

A new command appeared! I know, I didn't tell you about this one. This one is extremely helpful. It's a listing command. It looks where you're at and shows you all of the directories and files that are listed within the directory you're in. More than likely, it's in your "home" folder and probably has a ton of things in it. Let's get out of here and go somewhere else to do work.

Make a directory called newtoys.

mkdir newtoys

List the files in the directory you're currently in and you should see a new directory.

ls

Let's switch to it and start doing something.

cd newtoys

If you list what's in there right now, there's nothing in it. It's a blank canvas for your new masterpiece.

dotnet new console

Using the dotnet cli, you're asking for it to create a new application using the template console. By default, since no arguments are sent in, the dotnet tool will use the folder that you're working in as a cue for what the application should be named. Listing the files shows Program.cs, newtoys.csproj, and an obj directory.

I use VS Code for my editing, so for me, we can run that from the CLI as well. If you have it installed, run the following:

code Program.cs

This will open the file for editting. It isn't really essential to have anything special in there right now, but I went ahead and changed what it prints like so:

using System;

namespace newtoys
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello Dev.to!");
        }
    }
}

Now, we have an application. We can run it in VS Code, Visual Studio, Rider, or whatever you want. But let's press on.

dotnet build

Since you're working in the same directory as the newtoys.csproj, running the build command will search that directory for any project files (.csproj) that describe an pplication. since it found the newtoys.csproj file, it went ahead and compiled everything, reporting back success and giving a breakdown of the process. If, like me, you're curious about how things work, you can pass in a few more options and have the application's logging enhanced.

dotnet build -v d

This will re-run the build process with the "verbosity" (-v) set to "d[etailed]". This is a moment-to-moment list of the oeprations that dotnet build ran. This can be helpful if you run into something not working quite as expected and most CLIs will have some option that will let you set how verbose of feedback to give you.

ls

There is a new folder now, \bin. This directory is the default directory that dotnet will build out into. "Bin" is short for "binaries", and holds all of the compiled pieces of your application.

dotnet run

While you're here, this will re-build the application, compile all the binaries and copy them to the \bin directory and execute the application.

Now What?

Now, we've covered a few basics of the CLI. With this, you can navigate directory trees, start a new project, make new files, wire them up and build them. However, here's the deal, cards on the table so to speak. I'm relatively new to blogging. This article is something that I wish existed three years ago when I was grinding away, bound to Visual Studio and hopelessly uncomfortable with what I felt was how a "real developer" worked.

So, with that in mind, let's make this a collaborative effort.

Folks who found this article to be too basic: what should I have added? What are the killer commands that you wish someone had sat you down and explained?

Y'all who are wondering how to take next steps: where do you want this to go? What are you working with? Where do you need help? I can't promise I have all the answers, but here's what I do love: finding cool new things that others will benefit from. Maybe you're like me and don't want to ask a question "because it's somewhere on Stack Exchange". Well, ask anyway.

Next Steps

I'll be building this into a full application! It's going to be a little quirky, but the goal is to showcase the .NET command line parsing tools. Having built a tool or two that uses nothing but console applications, I have learned to love the level of support that it's getting with recent Core developments. If you want a peak in advance, here's the tooling I'll be using to start this application: https://github.com/dotnet/command-line-api . (Trust me, it's awesome!)