Command line "tab" completion for .NET Core CLI in PowerShell or bash
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.
About Newsletter
https://github.com/bergmeister/posh-dotnet
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.
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.
Derek and David - That's CarnacKeys.
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.
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"
complete --command dotnet --arguments '(dotnet complete (commandline -cp))'
Comments are closed.
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).