Scott Hanselman

Exploring the new .NET "dotnet" Command Line Interface (CLI)

December 25, 2015 Comment on this post [38] Posted in Open Source
Sponsored By

I've never much liked the whole "dnvm" and "dnu" and "dnx" command line stuff in the new ASP.NET 5 beta bits. There's reasons for each to exist and they were and they have been important steps, both organizationally and as aids to the learning process.

My thinking has always been that when a new person sits down to learn node, python, ruby, golang, whatever, for the most part their experience is something like this. It should be just as easy - or easier - to use .NET.

This is just a psuedocode. Don't sweat it too much.

apt-get install mylang #where mylang is some language/runtime
#write or generate a foo.fb hello world program
mylang foo #compiles and runs foo

I think folks using and learning .NET should have the same experience as with Go or Ruby.

  • Easy To Get - Getting .NET should be super easy on every platform.
    • We are starting to do this with and we'll have the same for .NET Core alone, I'm sure.
  • Easy Hello World - It should be easy to create a basic app and build from there.
    • You can "dotnet new" and get hello world. Perhaps more someday?
  • Easy Compile and Run
    • Just "dotnet run" and it compiles AND executes
  • Real .NET
    • Fast, scalable, native speed when possible, reliable

I've been exploring the (very early but promising) work at that will ship next year sometime.

IMPORTANT NOTE: This toolchain is [today] independent from the DNX-based .NET Core + ASP.NET 5 RC bits. If you are looking for .NET Core + ASP.NET 5 RC bits, you can find instructions on the

Once I installed the "dotnet" cli, I can do this:

>dotnet new
>dotnet restore
>dotnet run

Imagine with me, when you combine this with the free Visual Studio Code editor which runs on Mac, Windows, and Linux, you've got a pretty interesting story. Open Source .NET that runs everywhere, easily.

Here is a longer command line prompt that includes me just typing "dotnet" at the top to get a sense of what's available.

.NET Command Line Interface
Usage: dotnet [common-options] [command] [arguments]

[command] The command to execute
[arguments] Arguments to pass to the command

Common Options (passed before the command):
-v|--verbose Enable verbose output

Common Commands:
new Initialize a basic .NET project
restore Restore dependencies specified in the .NET project
compile Compiles a .NET project
publish Publishes a .NET project for deployment (including the runtime)
run Compiles and immediately executes a .NET project
repl Launch an interactive session (read, eval, print, loop)
pack Creates a NuGet package

C:\Users\Scott\Desktop\fabulous>dotnet new
Created new project in C:\Users\Scott\Desktop\fabulous.

C:\Users\Scott\Desktop\fabulous>dotnet restore
Microsoft .NET Development Utility CoreClr-x64-1.0.0-rc1-16231

Restoring packages for C:\Users\Scott\Desktop\fabulous\project.json
Writing lock file C:\Users\Scott\Desktop\fabulous\project.lock.json
Restore complete, 947ms elapsed

NuGet Config files used:

Feeds used:

C:\Users\Scott\Desktop\fabulous>dotnet run
Hello World!

Note that I ran dotnet restore once before on another projects so that output was not very noisy this time.

Native Compilation of .NET applications

This is cool, but things get REALLY compelling when we consider native compilation. That literally means our EXE becomes a native executable on a platform that doesn't require any external dependencies. No .NET. It just runs and it runs fast.

It's early days, and right now per the repro it's just hello world and a few samples but essentially when you do "dotnet compile" you get this, right, but it requires the .NET Core Runtime and all the supporting libraries. It JITs when it runs like the .NET you know and love.

.NET Core Compiled EXE

But if you "dotnet compile --native" you run it through the .NET Native chain and a larger EXE pops out. But that EXE is singular and native and just runs.

Native compiled .NET Core EXE

Again, early days, but hugely exciting. Here's the high-level engineering plan on GitHub that you can explore.

Related Projects

There are many .NET related projects on GitHub.

Sponsor: Big thanks to Redgate for sponsoring the feed this week! Have you got SQL fingers? Try SQL Prompt and you’ll be able to write, refactor, and reformat SQL effortlessly in SSMS and Visual Studio. Find out more with a 28 day free trial!

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
Hosting By
Hosted in an Azure App Service
December 25, 2015 3:24
Scott, this is very good news. I think moving .NET to Linux was one of the wisest things MS has done in the past few years.

We currently operate on Win and Linux servers via mono using NFX (alternative .NET stack altogether). Cant wait to switch to Linux as our primary platform.
December 25, 2015 3:36
I've been waiting on .NET native for regular .Net (not just Windows store apps)! It's exciting to see it hasn't been forgotten about. :)
December 25, 2015 5:53
Awesome, I am wait for this moment SOOO long time. After this step every rubist or developer who works on Unix-like system can easily migrate to .NET. oh my gosh its really a big news
December 25, 2015 14:39
People on linux / mac using python or java already know they have to specify the run environment to actually run the application they made, so I think devs on those platforms are not looking surprised when using .NET on linux requires specifying a tool to get things run.

It might be for windows devs though ;) It's a bit about understanding what you're actually doing:

1) With an interpreted language like python you have to specify the interpreter and give it the file you want to run.
2) With a language that compiles to intermediate language that is interpreted (.NET/C#, Java) you have to compile first and then basically go the route of 1). On windows with a PE trick this isn't visible, but it's still done under the hood.
3) With a language that compiles to native, you simply run the compiler and you get an executable.

It's cool that for .NET on linux/mac there's a way to combine 1 and 2, like we've known for years on Windows. Perhaps it's my C/vi roots but I don't find it a big disadvantage to first compile and then run. I mean, in practice you either use an IDE or build environment anyway later on which builds and runs your stuff.

The .NET native initiative is interesting. From the filesize of a hello world app is it safe to conclude that the native compiled executable contains the IL and a CLR? It's otherwise a pretty complex task to accomplish without running the IL up front: only then the compiler knows which external libs are used and thus which calls it has to statically link into the executable. Which looks like a halting-problem (as the app might never end). Of course, without reflection (of any kind) it's simpler, and with a native compiled BCL (for e.g. linux or mac) it will be easier. Will be interesting to see where they end up though, and I mean: for windows. Windows is still a major desktop environment and it would be great if winforms/wpf apps can be compiled to native (not ngenned) so they run much faster.
December 25, 2015 18:21
This is so special! I am so happy to see the platform that I have learnt to code on aligning itself with other platforms and doing it also by preserving its strengths. This is especially really beneficial for newcomers to the platform who will not feel alienated any-more and this type of stuff will break the entry barriers for those.
December 25, 2015 18:55
This looks great and very useful but for us guys not at the cutting edge how do you get hold of it and how do you avoid messing up your current production VS2015 instances?
December 25, 2015 20:52
I'm finding all these new possibilities with .NET really exciting...but is there anyone else out there who's also confused as hell by the scope and rate of all the changes? The original .NET framework was nice, easy and monolithic. Trying to get started with .NET Core is like having to put together a puzzle.
December 26, 2015 12:56
Looks great. Thanks Scott.

New version of .NET is coming with a lot of changes/enhancements and more closed to Open source world.

Following ASP.NET 5 and see drastic changes in MVC project structure. Though it looks uncomfortable initially however later on I realized, it is for better.
December 26, 2015 14:28
Sounds interesting stuff, I like the native compilation but I wish that Microsoft would Make the 'full fat' version of .net compile to native code; after all that's what most people are actually doing. Store apps are ok but I don't know anyone who produces them for a business environment.
December 26, 2015 19:34
Hi, Scott.

Can you say whether or not the switch from dnx, etc. to dotnet will happen before ASP 5 is released?

Any chance it will happen by RC2, which I believe Damian said will likely be in February?

December 28, 2015 1:54
Compiling apps to a native executable, like we're programming in C/C++ in 1985!

Everything old is new again!
December 28, 2015 13:27
@Bud, that's because the mobile devices of a few years ago have resource constraints similar to computers of 1990's! Now, ok, recently we are seeing cheap smartphones with 4GB of RAM and something like 16 cores, but CPU is still as much a scarce resource as in 1985 due to battery life issues!
December 28, 2015 19:59
Sweet! I'm glad to see more things that separate .NET from being tied down to Visual Studio and Windows. It's amazing how far things have come in the past year.

Thanks for posting, Scott.
December 28, 2015 21:27
Why not just use powershell...geeze...don't we have enough crap to deal with. Powershell is based on the same clr as .net and will execute .net commands....
December 29, 2015 4:13
" Which looks like a halting-problem (as the app might never end). "

Most people who mention the Halting Problem have no understanding of it, and this is an example.

The (not a) Halting Problem is posed thus: Write a program (called HALTS) that, given two inputs, the encoding of a program (P) and a specific input (I)for that program, can always determine whether P halts when given I as input. There's a simple proof by contradiction that no such program HALTS can exist.

That's the Halting Problem, and it has nothing to do with the issues here, or any other practical programming problem.
December 30, 2015 4:28
W-o-w. Old school native Linker capability! Great stuff!
December 30, 2015 18:49
Isn't Project Centennial the compile-to-native solution for desktop applications? Haven't heard a peep about it since it was announced.
January 01, 2016 19:27
I found the answer to my own question on the ASP Roadmap GitHub page:

Looks like the plan is to switch to the dotnet cli in the February RC2 release.
January 02, 2016 14:02
+Moderately interesting post. Command line compile, link to native code and execute is nice - been there / done that on pre-K&R unix.

Bonus points for a commercial software company quality and professionally supported managed language (c#) on non-windows platform. Much better than roll the dice and basing a $1 million+ new development project on the popular open source language of the year which is highly likely to be near dead and largely unsupported in 5 years. 4 to 5 paid maintainers, a few bug fixes each year, and a loose selection of random blog posts every few months is not a basis for making a sound long-term million dollar business decision.
January 04, 2016 20:14
Scott, do you have any idea when we will see a working and viable way to develop for ARM?

Right now I've been fighting with trying to develop using the relatively latest bits and still haven't been able to successfully build against ARM so that I can deploy and app to the RaspPi.
January 04, 2016 20:28
You should not be using command line interfaces on christmas, scott. :-)
January 04, 2016 23:05
@LKeene Yes, I hope .NET doesn't turn into Java. One of the things I've liked about .NET at least to this point, was as you mentioned that it was monolithic. I know that's typically considered a bad thing, but, what I mean is, you install .NET Framework and Visual Studio and you are good to go. In the Java world, you get into Maven hell too often. I don't that has to be the case, but, you have developers adding this whiz bang package or that and it causes total chaos. Personally, I think there are good changes and bad ones. Overally, I like NuGet and a lot of the changes that are happening, but, if it ends up like Java, then, I will be longing for the .NET days of old. I want something that works. I don't want to cobble things together from a bunch of disparate open source projects. Personally, I wonder if Microsoft isn't going too far in trying to parrot other systems like Ruby On Rails. IMHO, ASP.NET has a major failing. Namely, that it doesn't have the concept of UI controls. I think the ASP folks went overboard on parroting Ruby On Rails in that regard. Do we need an update to Web Forms, yes, but, MVC doesn't cut it when it comes to LOB applications that have complex UI requirements. When is Web Forms coming to this new system? Also, I'm getting sick of having this this fad JavaScript package or that crammed in my face. It's a constant churn. Just because it's new, doesn't make it better. My job as I see it to make usable products in an efficient manner, not spend all my time learning the fads the cool kids are doing. Especially, when it's a step backwards like MVC. I want to program at the proper level of abstraction.
January 05, 2016 6:49
The program runs for more than 3 seconds on my SSD drive.
January 06, 2016 2:20
Hey 'mk' nice of you to join the conversation! :) I know what the halting problem is, it's actually a category of problems which are all similarly impossible to solve, like finding dead code, which is also impossible to solve due to ... you guessed it :) The complete graph of called code at runtime is similar. You see, if you can find the complete graph of called code at runtime (to know what to compile to native for your app), you ... could find the dead code in the application. But as finding dead code is due to the halting problem impossible to solve (only through heuristics and in subsets of the situations, not all situations, which we're talking about here!), it implies finding all code to compile to native code also is impossible to solve, _unless_ you compile against already native libraries, so the only code to compile to native is the app code.

Anyway, have a nice day! :)
January 06, 2016 20:24
Awesome stuff!
So is going to co-exist ?
It's hard to know where to get up to speed with the new shiny .net these days
January 07, 2016 3:24
The mental weight of all this stuff sours the awesome work you guys are doing to be more open.

I have no idea what to use and when. I'm lost and I'm confused.

There's one node (well, yeah I know) and there's one npm. It's not only simple, it's easy. With .NET I've not only got all the ASP.NET 5 stuff to contend with, I've also got this new dotnet CLI. Combine that with different compilers, frameworks and Nuget and you've got yourself a rubix cube. I know they can be solved in seconds but you what? 30 years on this planet and I haven't solved one, ever.

Oh and types hidden in Nuget packages making core CLR use really hard. Kill me!

Please Scott bash whatever heads you need to bash to make this simpler. It also needs to be explained properly. Venturing into open multi platform tooling is fantastic. It rocks and you and the rest of the open MS people deserve great props, but let's do it in a way that doesn't scare the living daylights out of people!

Or it's just me! Haha. Rant complete!
January 07, 2016 5:24
So how the dotnet run command is different from dnx run? Or I should ask how dotnet commands are different from dnx commands? On this link, it is mentioned that .NET core components will replace DNX and DNX will only be used for hosting purpose. Is it?
January 07, 2016 11:07


Good to see good information about .NET.

I've been using .NET to build a Web site I
hope will be successful. So, the site has
a Web server, a session state server, an
instance of SQL Server, and two more
servers with unique functionality. The
code appears to be read for deployment for
a Web site live on the Internet.

I wrote the code in Visual Basic .NET with
the .NET Framework 4.0.

The total code is 18,000 programming
language statements in 80,000 lines of
text. Yup, I typed it all into my
favorite general purpose text editor using
just my fingers.

The parts of the work unique to my Web
site were all fast, fun, and easy. By a
wide margin, the most difficult part of
the work was getting needed, standard,
common, basic information about .NET.
That difficulty nearly sank the project
and still may.

Here I can give some illustrations of such
difficulties from your post:

> I've never much liked the whole "dnvm"
and "dnu" and "dnx" command line stuff

Easy to understand why: I never heard of
"dnvm" "dnu" "dnx" either and, thus, have
no idea what they are about. Does "dn"
abbreviate "domain name", "down", "darn",
something else?

I saw

>dotnet new
>dotnet restore
>dotnet run

And then what? The "new" means
a "new" what?

Okay, below is some text from a command
line program dotnet with

> restore -- Restore dependencies
> specified in the .NET project

What constitutes a ".NET project"?

What are "dependencies"?

Here the definition for "restore" starts
with "restore".

"Restore" in what sense?

Where on my computer is the "project", and
where are the "dependencies".

> publish -- Publishes a .NET project for
> deployment (including the runtime)

Here used "publishes" to define "publish".

"Publish" in what sense, where, for what

> repl -- Launch an interactive session (read,
> eval, print, loop)

What does "repl" abbreviate? It's a
misspelling of "reptile"?

What does "launch" mean? We're playing
with paper airplanes here? Rockets?

"Eval" abbreviates what with what meaning?

> pack -- Creates a NuGet package

What is a "NuGet package" -- some candy in
a box?

To me, no exaggeration, by far the biggest
problem of the Microsoft company is
providing information needed, as in a
famous statement by Steve Ballmer, by


and the biggest problem there is the
quality of the technical writing, and the
biggest problem there is poorly defined,
undefined, and poorly explained
terminology and concepts.

No joke.

> Note that I ran dotnet restore once
before on another projects so that output
was not very noisy this time.

"Noisy"? You lost me. Typically a
computer has a way to lower the volume of
the sound coming out of the speakers.

> This is cool, but things get REALLY
compelling when we consider native

What the heck do you mean by "native"? In
those 18,000 programming language
statements I wrote, I never encountered

> It's early days, and right now per the repro

What's a "repro"?

> .NET Core Runtime

I have 5000+ Web pages of documentation on
.NET, nearly all from the Microsoft Web
site MSDN, and on my computer have the
pages stored, indexed, and abstracted.
I've read all the pages.

Nowhere did I encounter anything called
the ".NET core".

What do you mean by "core"?

> the .NET Native chain

What the heck is that? Never heard of it
before. I can't even guess at the meaning
of either "native" or "chain".

> But that EXE is singular and native and
just runs.

In this context, what does "singular"
mean? I've never heard of this word in
computing before.

I hope that this post help Microsoft solve
one of the biggest problems for itself and
developers, e.g., me.

January 07, 2016 12:05
You need to stop with the GitHub repositories as 'a great starting point' and only have repositories for actual code.
January 07, 2016 13:47
A quick question: On Linux, if I do
dotnet compile --native
and then examine the resulting executable with
readelf -d ..filename..
I get a long list of libraries needed, even with the sample Hello World code.
Is there an option to get a fully statically linked application?
January 07, 2016 16:29
This is awesome, so excited about it. I really think this will make .NET a go to platform for all businesses, hopefully mostly replacing Java.
January 07, 2016 18:35
This is great stuff, reminds me of golang in the way you can compile to a native exe without any dependencies ... one of golang's killer features in my opinion. Golang also has a run command line option which compiles and runs at the same time.

The 'run' option it fact means C# can be used as a scripting language to perform tasks which you might have used python or ruby for in the past.
January 07, 2016 22:23
Does this mean every compiled .NET exe is considered a portable application?
January 17, 2016 17:57
When I dotnet build, I get the following error:

could not load file or assembly Microsoft.Extensions.FileSystemGlobbing or one of its dependencies.

I installed dotnet via the msi, and used dotnet new to create a project.

dotnet restore appeared to work correctly.

What might be causing this issue on a 64-bit Windows 10 computer, fully patched through and including Microsoft "January 2016 Patch Tuesday" ?
January 20, 2016 4:54
Thanks Scott. I'm very happy and excited with this new name. It's very clear now. Separations of the wording ".NET Framework" and ".NET Core" are now clear for ASP.NET Core 1.0.
February 13, 2016 5:06
This is so cool! Does anyone knows How to deploy a 'native app' made with ASPnet Core 1.0 MVC in Linux using Apache without Docker? Thanks!
February 21, 2016 9:39
Thanks Scott. I have 2 queries:
1. Can I build ASP.NET Core web application using Microsoft Dotnet CLI or only console?
2. Is Dotnet CLI replacement of DNVM, DNU & DNX or just an alternative ?
March 16, 2016 20:31
So, it appears that MVC 5 support isn't even bundled with Visual Studio 2015 now. All I see are project templates for MVC 6/ASP.NET 5, an as of yet released beta product. Way to go Microsoft. You are taking everything that sucks about Java and putting it into .NET now. I guess running beta software in production is what all the cool kids are doing these days.

Comments are closed.

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