Hacking DNX. Part one – build & debug

This is part one of my first series Hacking DNX.

Agenda [may change a bit]:

  1. Build & debug (this)
  2. Debugging DNU Utility
  3. Overview of DNX projects and architecture
  4. DNX internals

So you like diving deep into code? Or maybe trying to solve problem with new ASP.NET 5 on your own?. After all code is the source of truth. Read on to see how to compile and run your very own version of DNX.

First of download source code of dnx using git client

One thing to remember is to include --recursive flag to include sub projects as well. If already have the code and do not want to download it again, init submodules by typing:

After a few minutes repository should be on machine and you are ready to start building code. Although solution contains Visual Studio *.sln file the preferred way to build DNX is through build.cmd or, in case of Linux, build.sh file. Build script uses Sake which is basically a C#-enabled make script interpreter. Running script will download Sake and build project according to makefile.shade.

Be sure to use command line that has msbuild path set in PATH environment variable. If in doubt use Command Prompt installed with Visual Studio 2015 (eg. VS2015 x86 Native Tools Command Prompt).
Build produces artifacts in artifacts\build\ directory. Most notably there should be folders with fully functional runtimes:

  • dnx-clr-win-x64
  • dnx-clr-win-x86
  • dnx-coreclr-win-arm
  • dnx-coreclr-win-x64
  • dnx-coreclr-win-x86

Next action you should take is to install them to your dnvm. This can be achieved by running Sake command:

This produces series of junctions named VERSION-dev in your local .dnx folder. All point to your build.

Running dnvm list reveals all installed runtimes along with architecture and shows which one is active.

At this point active runtime is one of previously installed. Changing runtime is as easy as using one dnvm command. Type

and then use dnvm list to check if everything goes as planned.
Congrats. From this point you will be able to debug DNX.
The easiest way to to it is to run dnx.exe with flag –debug on any test project. Runtime stops and waits until you attach debugger.

Running dnx will then display Process Id which you can use to attach visual sudio debugger to process by navigating to Debug->Attach to process or by pressing Ctrl + Alt + P. I strongly recommend remembering keyboard shortcut as you are going to use it often.

Attaching to process with Visual Studio

Attaching to process with Visual Studio

At this point this process is still native (not Managed) and this should be the only one DNX listed in this state. The –debug flag is processed in runtime c++ project called dnx.win32 in pal.win32.cpp file where you can place your first breakpoint to start stepping through the code. To be able to step through the Managed code the correct option in Attach to window must be checked.

Wait for debug session

Wait for debug session

I recommend playing with the code on your own. In the next step I will show you how to debug tooling directly from Visual Studio.

1 Comment

Leave a Reply