DotNet Core: project.json dead? And I hadn’t noticed?

Somehow, the fact that the move has been made to the promised/threatened .csproj for DotNet Core had passed me by. Here we do the usual sequence of dotnet nes, restore, build, run…


Looking down from its root, we have a .csproj, and no .json. Shame, I was getting pretty comfortable with the latter, and I will miss it:





DotNet Core and EF: Database First

In a LocalDB (SQLServer), I created 2 tables, City and Customer, with FKs from Customer to City. I populated them, and you can get the backup of those here.

From there, I wanted to scaffold out the POCOs, something like this:

That was achieved by this set of PowerShell commands, and some massaging of the content of the project.json (mostly to add SQLServer Tools to the default Web option, which by default right now references SqlLite):

cd C:\sandbox\dotnet
dotnet new -t Web
dotnet restore
dotnet ef
where.exe dotnet
dotnet --info
dotnet ef dbcontext scaffold "Server=(localdb)\MSSQLLocalDB;Database=MyDB;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer -o \temp



DotNetCore and EF: “The specified framework… was not found.”

In late December 2016 I find that the default DotNetCore and default DotNetCore SDK are not playing nicely when it comes to the command line

dotnet ef

I believe I have now found a fail-safe way of getting the command to work, without playing around with project.json. That solution simply means selecting the LTS (Long Term Support) version of the DotNetCore runtime rather than the Current version. But it took me a long time to get to that realization.

First, the screenshots showing the 2 errors which blocked any progress on this for some time, and which seem to crop up pretty frequently on a Google:


I then went back to a clean-ish machine, defined, as:

  1. no DotNetCore references in Programs and Features – that is both for the runtime and SDK
  2. recursive deletion of c:\Program Files\Dotnet
  3. prove that [dotnet] executing under PowerShell returns [no such command] of somesuch.

These are the key locations for getting the correct combination of files, right now:

So for the runtime, I grabbed the Current / Windows / .NET Core 1.1 runtime – Installer, noting and installing that version of the installer. The fact it is the Current version will be significant later in the post:




Now create a new working folder, e.g. c:\sandbox\t1 and navigate there (admin mode). Prove that [dotnet] now works:


All good. Now what happens if we try to run dotnet commands?


Fine. Return to the sdk location referenced above:


Note that confusingly it is the .Net Core element that is 1.1.0, with the SDK element 1.0.0. Regardless. Now try the [dotnet ef] command again…


No executable found matching command "dotnet-ef"

Hm. It requires you to invoke in fact the template Web to get this to work. So do e.g..

dotnet new -t Web

Now try [dotnet ef], and you get a different error:


The specified framework 'Microsoft.NETCore.App', version '1.0.0' was not found.
 - Check application dependencies and target a framework version installed at:
 C:\Program Files\dotnet\shared\Microsoft.NETCore.App
 - The following versions are installed:
 - Alternatively, install the framework version '1.0.0'.

Let’s look at what P&F says we have:


1.1.0 both for the Runtime and for the SDK. Yet the message says I have “specified” 1.0.0. No I haven’t. I spent some time trying to marry up the project.json and the project.lock.json content to reconcile what was generated. I couldn’t, suggesting to me that the 1.0.0 requirement is somehow baked into DotNetCore EF in the current version. So then I went back to the downloads area above, and rather than specifying the Current version, I asked for the LTS or Longterm Support Version of the Runtime:





So although it says above it wants 1.0.0, maybe 1.0.3 is good enough. We run [dotnet ef] again, and this time we have lift-off:


And the installation has created a 1.0.3 runtime location in addition to the 1.1.0 runtime that was already there from the earlier default installation from the download area.


That’s all for this article. Another day we will look at scaffolding the EF project.

I will leave in some other screenshots:

AspNetCore and Yeoman: First Steps

This is a good starting point. I started out with a bare Windows Server 2016. That is, no Dotnet Core or Dotnet SDK binaries were installed to start with.

Challenges I found, to single some out:

The combination of a say tool which controls its own colors and PowerShell can be REALLY annoying. There are points when it is almost impossible to distinguish the text from the background when using Yeoman… so I switched reluctantly back to CMD.

I want to be doing ALL my installation using CLI, that is effectively choco and npm. However, there ain’t no such thing for the dotnetcore sdk, although there is for dotnetcore itself.


For now, some PowerShell history snippets, and all the screenshots.

iwr | iex

choco install nodejs.install -g

npm install -g yo generator-aspnet-spa
npm install -g webpack
npm install -g yo generator-aspnetcore-spa
yo aspnetcore-spa
npm install dotnetcore
dotnet new
choco install dotnetcore-runtime -y
yo aspnetcore-spa

DotNet SDK – dotnet-dev-win-x64.1.0.0-preview2-1-003177.exe




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.

DotNetCore: late November 2016

As noted back in June 2016, dnx etc. are no more, the confusingly named core is now JUST about  and not a more generalised catch all. Good. However… I am sure this morning I heard say on a podcast that the move towards non-Sln based solutions/projects was basically dead. That is, no more project.json, unless you are doing e.g. Visual Studio Code, which I will be here.

For the DotNetCore piece, this is your opening URL:


Installation of the .NET Core SDK:

Get Visual Studio Code (google it).

Let’s see where it has installed DotNet using where.exe:

And for my own interest, the existing versions of dotnet I’ve been collecting:

Now you have dotnet, you can carry on following the rest of the page. This does not need VS Code:

Then opening VS Code shows you that there is no .sln file… but there is a project.json, and a pretty big project.lock.json file, latter at 7000 lines, give or take:

Picking up in VS Code can be for another day.