kindness

PLEASE NOTE THAT THIS CONTENT IS COPY-PASTED FROM : http://www.sblackler.net/2015/05/02/Up-And-Running-With-DNX-DNVM-DNU/

There’s been quiet a few announcements throughout Build 2015. One of the many aspects that I am excited about is the new cross platform runtime environment called DNX, or the .NET Execution Environment.

What is DNX?

The .NET Execution Environment (DNX) provides a consistent development and execution environment across multiple platforms (Windows, OS X, Linux), multiple CPU architectures (x86, x64) and different .NET flavors (.NET Framework, .NET Core and Mono).

There has been a lot of talk about how we can run more and more cross-platform during the conference and that’s what DNX is all about. There are several different pieces to DNX, including:

• DNX (distribution): A NuGet package containing the implementation of the new environment. The .NET Core DNX distribution includes CoreCLR and the base parts of CoreFX. The .NET Framework and Mono DNX distribution only contain the DNX components.
• DNX (commandline tool): The command line tool controls various app operations, primarily launching.
• DNVM: This is a tool for acquiring and managing DNX distributions. While it’s not part of DNX itself, it plays an administrator role for DNX, providing version management among other things.
• DNU: The NuGet client for DNX. NuGet.exe is not used.

What all of this means is that we can run console apps/asp.net 5/entity framework on anything that can run DNX. So think Mac’s, Linux, Raspberry Pi’s etc.

How CoreCLR differs from DNX

CoreCLR contains the .NET Core runtime and the base library called mscorlib. It includes the garbage collector, JIT compiler, base .NET data types and many low-level classes.

DNX contains the CoreCLR and the base parts of CoreFx which includes classes for collections, file systems, console, XML, async and many others.

Installing DNVM/DNX

Before you can install any DNX runtimes you need to install DNVM. There are a few ways to install the DNVM. Personally I prefer running the following powershell command:

C:\Dev> powershell -NoProfile -ExecutionPolicy unrestricted -Command "&{iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/aspnet/Home/dev/dnvminstall.ps1'))}"

Once that command has been executed, you will see similar console output to the following:

Using temporary directory: C:\Users\SBLACK~1\AppData\Local\Temp\dnvminstall
Downloading DNVM.ps1 to
Downloading DNVM.cmd to
Installing DNVM
Installing .NET Version Manager to C:\Users\sblackler\.dnx\bin
Creating destination folder 'C:\Users\sblackler\.dnx\bin' ...
Installing 'dnvm.ps1' to 'C:\Users\sblackler\.dnx\bin' ...
Installing 'dnvm.cmd' to 'C:\Users\sblackler\.dnx\bin' ...
Adding C:\Users\sblackler\.dnx\bin to Process PATH
Adding C:\Users\sblackler\.dnx\bin to User PATH
Adding C:\Users\sblackler\.dnx to Process DNX_HOME
Adding C:\Users\sblackler\.dnx to User DNX_HOME

After that has been completed, restart powershell and you should have the DNVM bits installed. You can verify this using the following command:

dnvm

Installing a version of DNX

To install the latest .NET Core-based DNX, use the dnvm install command:

dnvm install -r coreclr latest

This will install the 32-bit version of .NET Core. If you want the 64-bit version, you can specify processor architecture.

dnvm install -r coreclr -arch x64 latest

Then, you can see the currently installed DNX versions with dnvm list:

dnvm list

Which, after running the above commands, results in the following output from the command above:

Active Version           Runtime Architecture Location                         Alias
------ -------           ------- ------------ --------                         -----
       1.0.0-beta5-11682 coreclr x64          C:\Users\sblackler\.dnx\runtimes
  *    1.0.0-beta5-11682 coreclr x86          C:\Users\sblackler\.dnx\runtimes

Interestingly, when you install each of the runtimes, the installer generates native images for the target machine which improves the start up performance.

Switching between DNX runtimes

If you have the need to switch between different versions of DNX, you can use the dnvm use command which has the following format:

dnvm use -r coreclr -arch <arch> <version>

Where <arch> is, replace with the architecture that you would like to have; eg: x86, x64. With <version> replace with the version number that is shown in dnvm list:

dnvm use -r coreclr -arch x86 1.0.0-beta5-11682

The above is used to switch the current runtime to the x86 version of the 1.0.0-beta5-11682 build of DNX. To switch to the x64 version, simply switch out x86 for x64:

dnvm use -r coreclr -arch x64 1.0.0-beta5-11682

This only makes the DNX runtime apply to the current terminal session. We do have options of adding it to the user profile or the system profile (the system profile is not recommend). Usually, when we run dnvm use we get something along the lines of:

Adding C:\Users\sblackler\.dnx\runtimes\dnx-coreclr-win-x64.1.0.0-beta5-11682\bin to process PATH

Which gives us the following output in dnvm list:

Active Version           Runtime Architecture Location                         Alias
------ -------           ------- ------------ --------                         -----
  *    1.0.0-beta5-11682 coreclr x64          C:\Users\sblackler\.dnx\runtimes
       1.0.0-beta5-11682 coreclr x86          C:\Users\sblackler\.dnx\runtimes

Note the astrix above? That signifies the current running DNX environment. If we wish to persist that environment within our profile we add -p to our dnvm use command:

C:\Dev> dnvm use -r coreclr -arch x64 1.0.0-beta5-11682 -p
Adding C:\Users\sblackler\.dnx\runtimes\dnx-coreclr-win-x64.1.0.0-beta5-11682\bin to process PATH
Adding C:\Users\sblackler\.dnx\runtimes\dnx-coreclr-win-x64.1.0.0-beta5-11682\bin to user PATH

This time you see DNVM has added the run time to the user path, so the next time you start a terminal session, that will be the selected runtime.

Aliasing DNX runtimes

Aliasing is useful so you don’t have to remember those lovely version strings. To see the current aliases setup in your environment use, dnvm alias. This acts the exact same as the dnvm list command. Here is a sample output:

Alias Name
----- ----
Beta5 dnx-coreclr-win-x86.1.0.0-beta5-11682

You can create aliases in a few ways. The first is to specify the name and the version:

dnvm alias Beta5 -Version 1.0.0-beta5-11682 -Runtime coreclr

Using the above command, DNVM will create an alias for version 1.0.0-beta5-11682 with the x86 architecture on coreclr. Given that I have both x86 and x64 runtimes installed, I would suggest that the order of preference for the runtimes is x86, x64, arm, mono, everything else. However, we can specify a specific architecture with the command:

C:\Dev> dnvm alias Beta5 -Version 1.0.0-beta5-11682 -Architecture x64 -Runtime coreclr
Updating alias 'Beta5' to 'dnx-coreclr-win-x64.1.0.0-beta5-11682'

By specifying the architecture and using the same alias name, the DNVM has updated the alias to use the correct runtime. -Version, -Runtime and -Architecture can be shortened to -v, -r and -a respectively. If no runtime is specified, DNVM will default to the clr runtime.

When you have aliasing setup, you can use the alias within the dnvm use command. Note that you have to specify the runtime if you are not selecting the clr option:

C:\Dev> dnvm use Beta5x86 -r coreclr
Adding C:\Users\sblackler\.dnx\runtimes\dnx-coreclr-win-x86.1.0.0-beta5-11682\bin to process PATH
C:\Dev> dnvm list

Active Version           Runtime Architecture Location                         Alias
------ -------           ------- ------------ --------                         -----
        1.0.0-beta5-11682 coreclr x64          C:\Users\sblackler\.dnx\runtimes Beta5
   *    1.0.0-beta5-11682 coreclr x86          C:\Users\sblackler\.dnx\runtimes Beta5x86

Starting a DNX application

Before you can run your program, you need to ensure that your packages are restored. So enter dnu:

dnu restore

As mentioned earlier, dnu is all the other tools. It does builds, package restore and alot more. It can be thought of as a NuGet client plus more. Once the packages are restored, you can run your application:

dnx <path> run

All you need to do is specify a path, or use . as the path. The dot signifies the current working directory. If I build a quick console application and run the commands above, I get the following output:

C:\dev\test\ConsoleApp1> dnu restore
Restoring packages for C:\dev\test\ConsoleApp1\src\ConsoleApp1\project.json
Writing lock file C:\dev\test\ConsoleApp1\src\ConsoleApp1\project.lock.json
Restore complete, 146ms elapsed
C:\dev\test\ConsoleApp1> dnx . run
Hello DNX

And that’s it. That’s the basics of DNX/DNVM/DNU.