Scott Hanselman

Command line "tab" completion for .NET Core CLI in PowerShell or bash

March 27, '18 Comments [10] Posted in DotNetCore
Sponsored By

Lots of people are using open source .NET Core and the "dotnet" command line, but few know that the .NET CLI supports command "tab" completion!

You can ensure you have it on .NET Core 2.0 with this test:

C:\Users\scott>  dotnet complete "dotnet add pac"
package

You can see I do, as it proposed "package" as the completion for "pac"

Now, just go into PowerShell and run:

notepad $PROFILE

And add this code to the bottom to register "dotnet complete" as the "argument completer" for the dotnet command.

# PowerShell parameter completion shim for the dotnet CLI 
Register-ArgumentCompleter -Native -CommandName dotnet -ScriptBlock {
    param($commandName, $wordToComplete, $cursorPosition)
        dotnet complete --position $cursorPosition "$wordToComplete" | ForEach-Object {
           [System.Management.Automation.CompletionResult]::new($_, $_, 'ParameterValue', $_)
        }
}

Then just use it! You can do the same not only in PowerShell, but in bash, or zsh as well!

It's super useful for "dotnet add package" because it'll make smart completions like this:

It also works for adding/removing local project preferences as it is project file aware. Go set it up NOW, it'll take you 3 minutes.

RANDOM BUT ALSO USEFUL: "dotnet serve" - A simple command-line HTTP server.

Here's a useful little global tool - dotnet serve. It launches a server in the current working directory and serves all files in it. It's not kestrel, the .NET Application/Web Server. It's just a static webserver for development.

The latest release of dotnet-serve requires the 2.1.300-preview1 .NET Core SDK or newer. Once installed, run this command:

dotnet install tool --global dotnet-serve 

Then whenever I'm in a folder where I want to server something static (CSS, JS, PNGs, whatever) I can just

dotnet serve

It can also optionally open a web browser navigated to that localhost URL.

NOTE: Here's a growing list of .NET Global Tools.


Sponsor: Get the latest JetBrains Rider for debugging third-party .NET code, Smart Step Into, more debugger improvements, C# Interactive, new project wizard, and formatting code in columns.do

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb
Tuesday, 27 March 2018 19:03:10 UTC
This is possibly one of the only things I've been missing from the dotnet CLI! I find myself hitting tab quite often when using the dotnet CLI just out of habit!

Couple of things:

1. I didn't have a PowerShell profile so I had to run "New-Item –Type file –Force $PROFILE" to create one before I could run "notepad $PROFILE" in PowerShell.

2. It also relies on the PowerShell Execution policy allowing running the scripts (which might not be allowed in corporate environments).
Mo
Tuesday, 27 March 2018 20:42:27 UTC
I published a module called posh-dotnet a few months to the PSGallery that is an improved version of this and also works for the old version 1 CLI. It is open source here:
https://github.com/bergmeister/posh-dotnet
Wednesday, 28 March 2018 00:25:15 UTC
What app do you use to show key presses?
Derek Price
Wednesday, 28 March 2018 13:02:10 UTC

Lots of people are using open source .NET Core and the "dotnet" command line...


I'd like to see some data backing that up. I've been a .NET dev for 10 years and I don't know anyone who uses the "dotnet" command line.

I've been doing a lot of front end work lately with Angular and Webpack (all command line, because VS has zero support) and I can say unequivocally that the experience is atrocious compared to a proper GUI. Devs are constantly confused about how to do things, the web is full of conflicting information on which commands to use, and the "inner loop" of code-test-debug is way slower.

Like we keep telling you Scott, there's a reason Visual Studio became so popular.
Sam
Wednesday, 28 March 2018 14:49:01 UTC
Note that this also enables Ctrl+Space listing of all available options. Apologies if this is already implied or common knowledge — I'm new to PowerShell. I typically prefer Ctrl+Space so I can see what my options are.

And Sam, I don't have any hard data backing up Scott's claim about the popularity of the dotnet command line, but simply by virtue of how widely used Visual Studio Code is, which has no .NET GUI and relies entirely on the command line, I think it's obvious that many are indeed using the command line.

GUI tools are convenient and fast, command line tools are flexible and powerful. They are both useful in their own ways, and embracing the utility of both makes one a more well-rounded developer.
Jacob Stamm
Wednesday, 28 March 2018 16:25:36 UTC
Why is this not built into the SDK installer?
Wednesday, 28 March 2018 18:04:27 UTC
Sam - The telemetry for the dotnet command line is public. Tens of millions of executions. I agree that the VISUAL in Visual Studio has value and is important, but there's room for more than one way. It's undeniable that a non-trivial number of people dig the CLI. https://blogs.msdn.microsoft.com/dotnet/2017/07/21/what-weve-learned-from-net-core-sdk-telemetry/

Derek and David - That's CarnacKeys.
Wednesday, 28 March 2018 19:03:35 UTC
@Scott

Right but does that telemetry distinguish between tools (IDEs) calling the CLI and people actually sitting down and using the CLI? Seems that would be difficult to distinguish. And even if it could- there's also a chicken-and-egg problem. The CLI is the first class environment for MS these days and everyone knows it, so they're often forced to use it. That doesn't tell you anything about whether they *want* to be using it or not.

I think .NET Core is great and growing in popularity. Does that mean there is a growing wave of developers who suddenly want to be using command lines instead of IDEs? I don't believe that for a second. Who wants to keep a list of commands in their head when a tool could do it for them?


I agree that the VISUAL in Visual Studio has value and is important, but there's room for more than one way.

I think this makes for a good soundbite, Scott, but it doesn't reflect reality. The teams working on these tools have finite resources. Every man-hour spent trying to make a better CLI experience to be trendy and try to impress the NodeJS folks (many of whom will never try .NET no matter what you do) is an hour not spent making the Visual Studio experience better.

Have you tried to use Visual Studio to do web development using a modern web stack any time recently? It's absolutely atrocious. There is no IDE NPM support outside of NodeJS projects, no real Webpack support, no Angular2+ support. Broken, half baked support for already-dead technologies like Bower. Zero support for getting TypeScript definition files in IDE. And to top all that off, Mads Kristensen has moved onto other things and Web Essentials is pretty much dead.

It's frankly embarrassing the state of Visual Studio these days. And please don't pretend it's a coincidence that all this has corresponded with all the effort spent at Microsoft on the CLI.
Sam
Wednesday, 28 March 2018 19:22:18 UTC
Didn't work for me.

C:\Users\somedude>dotnet --version
2.1.300-preview1-008174

C:\Users\somedude>dotnet install tool --global dotnet-serve

The installation succeeded. If there are no further instructions, you can type the following command in shell directly to invoke: dotnet-serve

C:\Users\somedude>dotnet serve
No executable found matching command "dotnet-serve"
Some Dude
Saturday, 31 March 2018 11:05:18 UTC
For fish sell you just need to call

complete --command dotnet --arguments '(dotnet complete (commandline -cp))'
Rémy
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.