Purpose of this was:
- Point at the right CLR (CoreClr not er Full in this case)
- Play a bit with updating the project.json files and then run [dnu restore]
This gallery contains 6 photos.
I like XUnit. A nice short namespace so you don’t struggle to remember it for each new file [XUnit – compare that to MsTest]. A way of handling exceptions in tests that seems to need less ceremony than MsTest. Here is a useful page comparing MsTest, NUnit and XUnit.
A debate on Setup/Teardown started by the person who used to lead the NUnit team.
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:
I decided that the I would just have a go with the dnvm.cmd:
PowerShell (called from the .cmd) knows that the .ps1 came from the Internet, so let that through:
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:
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:
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:
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.
This is archive material: the syntax below no longer works. By Microsoft’s own admission I believe, while fun, this was barely alpha. See .Net Core 2 blog here.
Summary: I have at least proven that I can run a Console App from the command line, using dnu, dnx, dnvm, yada.This is the output from an hour’s effort, that it is, a console app called using dnx.exe:
The snippets below record my steps a) to see if by building a console app in VS2015 using a template I could infer exactly how it is done manually, b) failing to understand why it could not resolve the System.* dependencies, c) ignoring guidance in MSDN blogs about Nuget package manager in VS sorting it out, and instead letting dnvm restore do its job, d) F5 and ctrl-F5 to get a clue about how it is executed (i.e. the path to the required dnx.exe), e) executing dnx.exe from the command line, passing in the location of the project.json file, which holds all the necessary info about how and what to execute, f) an implicit confirmation that console applications are no longer about building and running an .exe. (And I get that aspVNext/Roslyn etc is not per se about console apps – I was just looking for a way to do the simplest thing, with the smallest number of dependencies. This at least does now open up the door to knowing (I think!) how I can execute this on a low power Windows machine (or Linux – I have no access to OSX) without Visual Studio present. I could of course just have grabbed an old style csc.exe… but this is about doing Roslyn and related, not revisiting old ground. So the noisy snippets: