DotNet Core: Libraries, XUnit, VS Code. Part 2

I finished it (see Part 1 for context). Most of the delay was in getting the hang of structuring the parent project, and the relationship between the 2 project.json files.

So given a project ShippingContainerApp, a structure like this fits the bill, where SCS is ShippingContainerSource, and SCT is ShippingContainerTest. Also see the repo here:

Anyhoo, you can find the full working project here:


Back to the beginning again…


DotNet Core: Libraries, XUnit, VS Code. Part 1

On this page, there is a tutorial, involving full-fat VS, and at the bottom there are a number of comments around difficulties building the solution.



I saw a challenge in trying to prove it is actually easier to build using the DotNet CLI and VS Code, rather than FF VS. One reason might be that you are closer to the bare metal of DotNet Core: if you are running in FFVS, it might be hard to deduce if the build error is due to DotNet Core problems, or problems with Visual Studio’s integration with DotNet Core.

My previous articles on DotNet Core have only been around simple command line stuff, namely, using the default [dotnet new] command.

To start off, let’s get our CLI environment right. The next few lines (being PowerShell) set the date time as the prompt, recursively remove any existing files from the current root down, and custom-set colours (but then dotnet CLI comes along and ignores that, as we see in a moment):

function prompt(){"$(Get-Date)> "}
Remove-Item -Recurse *
$color = (Get-Host).PrivateData
$color.ErrorForegroundColor = "White"

Whereas before, I used [dotnet new], this time we’ll use a nonsense line to show some options:

The contrast in the red error message is poor. It says (note the typo):

Unrecognized type: nonsense
Avaiable types for C# :
- Console
- Web
- Lib
- xunittest

That tells us what is available. The msdn tutorial is for a library and a test, so let’s start with the lib option [dotnet new -t Lib], and then see the files that creates:

So nothing built yet. Now we’ll try [dotnet run]:

Perhaps now we can do a run? No, it’s a library, you don’t Run a library:

So we can distribute a library. OK…

At this point, we have a library file that contains and does precisely nothing:


That’s enough for a first post on this, as I have stuff to do. I’ll probably complete it over a number of days. More anon.

Azure: controlling it from a Windows Tablet

Nothing special about this, but it was amusing to stop a VM from my Linx 10″ tablet, just to prove there is nothing to stop that – there shouldn’t be after all, it’s just a Windows 8.1 tablet.


In this first shot, having downloaded Azure for PowerShell, you’ll see the error “The server or proxy was not loaded”.


In the time it took me to Google it, I ran it again, and all was fine this time:


And then to stop the service…


These are the rough notes I took while running it for the first time on the Linx:


Try Azure command-line interface [Windows install]

takes about 30 minutes say

Add-AzureAccount - this fails first time with proxy error when it asks for authentication, but then succeeds a second time

“Looking for an account” - takes you to the sign on page

Brings up the id type subscription and tenants fine

Prompts you to use get-azuresubsciption

Great - so that works as well (all this so far without arguments)

Now try get-azurevm

Brings back all the VMs with ServiceName, Name, and Status (StoppedDeallocated, ReadyRole)

Now try to stop the ReadyRole one

stop-azurevm -name TheName -ServiceName TheServiceName

prompted for last deployment, resulting in new ip address

Beyond that, I deleted my VMs to staGetAzureVM01