DNX: a console app on a Windows client with no pre-existing dev tools

Summary: Previously, I got a trivial console app working using DNX. However, As Visual Studio 2015 was on that box, I could not be sure how much help that was giving me under the covers (especially as I started it using a VS template). This post just confirms that you can run a console app on a bare Windows 10 box, with no development environment or tools present, once you have made the necessary trip to GitHub.

Proving out dnx and its mates is getting to be a bit of a drug. I just know that even though I have absolutely zero justification for trying out it out on a Linux distribution… it will happen. 🙂

But back to the job in hand…

Using my Azure subscription, I spun up a Windows 10 Enterprise VM – out of the box, this has no developer environment or tools. I installed Google on that box (I have no idea why it assumes I’m in the Netherlands), and searched for [dnvm github] (or just go straight here):


I picked a link, and downloaded the zip (note you do not have to log in just to get the zip):


As I’m just playing, I saved that to the (temp) d: drive on the VM, and expanded it:

DnvmGithub02 DnvmGithub03

I decided that the I would just have a go with the dnvm.cmd:

DnvmGithub04 DnvmGithub05

PowerShell (called from the .cmd) knows that the .ps1 came from the Internet, so let that through:

DnvmGithub06 DnvmGithub07

Let it install the DNX runtime for me:


This has also updated the path for me, to find dnx



But DNVM isn’t on the path. OK, I could put that there by hand, but for now, I’ll just navigate to its location. Note that it was evidently a mistake to earlier save it to a temporary location – I will need it another time:


As said, this is a new Windows box, so update the execution policy:

DnvmGithub12 DnvmGithub13 DnvmGithub14

In fact, running dvnm upgrade is evidently redundant, well, this time anyway, as it is doubtless repeating stuff done in the dnx wizard earlier:


So now I have copied across the 3 files from yesterday, ie the .cs, the .xproj, and the project.json. This confirms that neither a .sln nor a .csproj are needed. However, I am not yet clear on the implications for msbuild. I don’t care about that right now:


With those minimum files in place, I can now run [dnu restore] to read the project.json file and download the dependencies. There are some errors… but I’m not going to examine those right now:

DnvmGithub17 DnvmGithub18

With all dependencies hopefully resolved, we can execute the Program.cs, using

[dnx -p .\project.json run]

… and that gives me the hoped-for result:


Note that although I used the console app from yesterday, the dnx download actually contains its own console app, so I could have used that. For this exercise, I would not have needed the .sln file, but for something more enterprisy, maybe I would need a .sln file:


Next day…

I just spent not more than 5 minutes on my Linx Windows tablet going through all the above steps. As a plus, I was also able to load Visual Studio code, edit the .cs in there, get Intellisense working, AutoSave, and then re-run dnx against it. This time round I did use the sample console app rather than my own. The only interesting thing in that was that in VSC the OmniSharp/Roslyn parser saw that System.Diagnostics was not required, and offered to remove it. Great.

I think right now the one gap in my mind is seeing how the new (?) MsBuild fits in to this, when you have more complex dependencies. But that will do for now.