Over a million developers have joined DZone.

Love Thy Command Line

DZone 's Guide to

Love Thy Command Line

Are you a .NET dev who is unfamiliar with the command line? Perhaps it's just been far too long since you've used it... This cheat sheet will help you get a quick grasp on everything you need to know to get started. It's much easier than you may think!

· Web Dev Zone ·
Free Resource

For the last decade, Windows or .NET developers using Visual Studio have been shielded from the command line. Why do we need command line tools when just about everything needed for app development is right there in Visual Studio? Simply use the extensive IDE menu options or the right-click to access additional operations through the context menus. As a result, command line tooling has often been thought of as counter-productive and meant for the über geeks.

But are rich IDEs making developers lazy? Why do we depend on having a UI to perform even the simplest of tasks? Do you keep hearing people boast of the power and flexibility of the command line? Or of features that you just cannot invoke from your IDE? Relax – the command line isn’t difficult to use. With a little practice, you can master the art and have a lot of power at your disposal.

The new .NET is lean, modular and cross-platform with a much lower barrier to entry. And since developers can now choose any IDE and OS of their choice, the commonality between Windows, OSX and Linux becomes the command line. Command line tooling for .NET works the same way on any platform.

This article distils down the most common and useful command line tooling for the new .NET. We’ll dispense with any cat pictures and funny memes and focus on just creating a straight up developer cheat sheet for .NET command line tooling.

For a deeper look at CLI tools and the .NET CLI, check out our whitepaper, The Command Line: Reinvented for Modern Developers, which celebrates the resurgence of CLI tools and provides insight into how modern development platforms cater to application development through CLI—for web, desktop, and mobile channels.


Since .NET is now portable, you need a comprehensive version manager to manage how apps are using and bundling the .NET framework. That’s the job of DNVM – the .NET Version Manager.

DNVM works cross-platform and, once installed, comes with a set of command line tools. Here’s a list of the most commonly used commands, along with flags and parameters, that offer flexibility for developers:

  1. dnvm Purpose: Check if DNVM is installed and print version
  2. dnvm list Purpose: List out DNX version information Parameters:-detailed : Displays detailed info about each runtime
  3. dnvm help Purpose: Look up Help information on commands/parameters
  4. dnvm install Purpose: Installs the requested DNX version Parameters:<version> : Specified DNX version
    latest : Grabs latest DNX from feed
    -OS : Operating System for target runtime (darwin for OSX)
    -a : Runtime target architecture (default x64)
    -p : Sets installed version as default (persistent)
    -f : Force install DNX versions on top of existing ones
    -u : Grab DNX versions from unstable feed
    -r : Runtime indicator (mono or coreclr)
    -g : Install DNX to configured global DNX file location
    -alias : Sets the alias of requested DNX version on install
    -y : Assume yes to all prompts
  5. dnvm upgrade Purpose: Installs latest DNX from feed and sets as default in one step Parameters:-f : Force upgrade by overwriting existing DNX versions if any
    -u : Grab DNX versions from unstable feed
    -r : Runtime indicator (mono or coreclr)
    -g : Install DNX to configured global DNX file location
    -y : Assume yes to all prompts
  6. dnvm uninstall Purpose: Uninstalls the requested DNX version Parameters:<version> : Specified DNX version
    -OS : Operating System for target runtime (darwin for OSX)
    -a : Runtime target architecture (default x64)
    -r : Runtime indicator (mono or coreclr)
    -y : Assume yes to all prompts
  7. dnvm use Purpose: Sets up a requested DNX version to host apps Parameters:<version> : Add DNX bin to PATH of current command line session
    none : Remove DNX bin from PATH of current command line session
    -p : Set specified version of DNX as default (persistent)
    -r : Runtime indicator (mono or coreclr)
    -a : Runtime target architecture (default x64)
  8. dnvm run Purpose: Bootstraps DNX to run the requested version, without affecting current PATH Parameters:<version> : Specified DNX version to run
    <args> : Arguments passed to DNX
  9. dnvm alias Purpose: Lists aliases or sets an alias for requested DNX version Parameters:<none> : Lists all DNX aliases that have been defined
    <alias> : The name of the alias to set
    <version> : The DNX version to set the alias to
    -d : Remove the specified alias
  10. dnvm update-self Purpose: Updates DNVM itself


Once you have DNVM set up .NET runtimes and start building your app, you will invariably have some dependencies. These could be parts of the .NET framework that you want to pull in through NuGet or third party open source packages that you want to consume. You’ll need some command line tools that help you manage your dependencies.

Enter DNU. DNU stands for ‘DotNet Utilities‘ and it provides command line tooling used to manage, restore, pack and publish your apps, along with all package dependencies. Here are the most common commands you may be using from inside your app project directory:

  1. dnu restore Purpose: Restores NuGet packages in project as per references in Project.JSON
  2. dnu build Purpose: Produce assemblies for the project in given directory
  3. dnu publish Purpose: Packages up app with requested DNX runtime for deployment Parameters:"<ProjectPath>" : Root directory of app to publish
    --out "<OutputPath>" : Output directory of published app
    --configuration <Release/Debug> : Package mode to publish app
    --runtime <version> : Specified DNX to include in app package
  4. dnu pack Purpose: Build NuGet packages for the project in given directory
  5. dnu list Purpose: List the dependencies of a given app/project


Once you’ve built your app on top of the right .NET runtime and managed packages through DNU, it’s time to run your app. This is where DNX comes in.

DNX is the .NET Executable runtime and it will host your app and bootstrap the entry points into .NET applications. You can also use DNX to fire up commands, either built-in or custom ones for your app, as shown with some commands below:

  1. dnx web/kestrel Purpose: Starts up ASP.NET DNX host on Windows/OSX/Linux
  2. dnx <command> Purpose: Invoke named execution of a custom .NET entry point, defined in Project.JSON
  3. dnx run Purpose: Runs a console app on top of DNX

DotNet CLI

Are you getting comfortable with DNVM and DNU tooling? Stop. And forget all the commands that this article listed. Well, not in reality, but just the syntactical part of it. Let’s discuss the .NET CLI.

As a part of trying to make the .NET command line more accessible and consistent, a new set of tools is in the works. Aptly called ‘DotNet CLI ‘, this set of commands is slated to replace much of the DNU tooling you saw above. It uses the same general ideas, just invoked via the standard DotNet moniker. The .NET CLI is supposed to go live alongside ASP.NET 5 RC2, which is slated for sometime in Q1 of 2016.

Some of the new commands in the .NET CLI are listed below – they do exactly the same things as their DNU tooling counterparts and allow you to start having a 1:1 mapping as you transition.

  1. dotnet new – Creates a new project
  2. dotnet run
  3. dotnet compile – Compiles to IL (--native compiles to native)
  4. dotnet pack
  5. dotnet restore
  6. dotnet publish


Hopefully, the command cheat sheet in this article helps you get a better grasp of the various commands along with flags/parameters that are at your disposal. Fear not, and bravely step into the world of command line tools for .NET. You’ll find the power addictive and the flexibility indispensible.

command line ,.net ,web dev

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}