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:


efworking22

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:

efworking06

efworking07

efworking08

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

efworking21

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

efworking09

Fine. Return to the sdk location referenced above:

efworking12

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…

efworking22

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:

efworking13

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:
 1.1.0
 - Alternatively, install the framework version '1.0.0'.

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

efworking24

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:

efworking25

efworking26

efworking27

efworking28

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:

efworking29

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.

efworking31

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 https://chocolatey.org/install.ps1 | 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

 

https://www.microsoft.com/net/core#windowscmd

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

 

 

 

Docker on Windows: DockerFile

Once you are up and running with Docker on Windows… it is great! That’s an aside. Back to the job in hand.

So far, I have instantiated Containers from Images. I now wanted to play with DockerFile, which allows you to create Images. I briefly played with the Docker linux examples… but of course you have to get a bit twisted to make those work on Windows. I then went the Windows route, and followed these examples.

The key command is, imho:

docker build -f DockerFile .

Note that VSCode understands that this is a DockerFile:

 

DockerFile21.PNG

The code and PowerShell execution is from this DockerFile:

DockerFile22.PNG

Docker on older Windows: don’t bother

I have a working Windows Server 2016 with Containers Azure VM running Docker for Windows very successfully. As I could not resist, I started a Windows Server 2016 without Containers Azure VM, to see if I could get the Docker instructions for older Windows machines to work. (I had previously tried to get it running on my Windows 10 Anniversary box, and failed).

These are the links:

These are the screenshots, ultimately ending in failure. I started out with a 2 core/SSD box. I saw that unlike with the Azure box with Containers, predictably, there was no Docker entry in services. Things seemed to be going OK.. until the failures at the end.Conclusion: it is not worth the pain of installing Docker on a box that does not already have it available as a service… unless you enjoy going through the pain to get the reward. Part of the problem for me is that apart from my rubbish home laptop, I only have virtualised environments, and the Docker installation process is not expecting that.

 

SQL Server Management Studio (SSMS)

This is now a) free, b) no longer part of the SQL Server media. Get it here.

ssms01.PNG

(Right now WordPress image upload seems to have  a glitch where it uploads in reverse order of capture, so read these pictures bottom to top)

Docker on Windows: First Steps

Last night I wasted a few hours getting nowhere: various problems with the spec or config of machines I was trying Docker out against not matching up to assumptions in the msdn pages, blogs I was reading. However, remember this is firmly Windows. Sure, I dare say it is a breeze on Linux – I would not know.

Tonight in fact was a much better contrast. I have any number of SQLServer instances running on a single Windows Server 2016 Azure VM.

Let’s take it real slow… The first important step is to grab the right image in Azure for these purposes. One that works is this:

Always select the Resource Manager deployment model:

This is the size I usually pick: shut it down between use and it won’t be too expensive. I would not use 2 cores – I tried one a couple of days back, and it was REALLY slow. This speed is fine, for me:

That takes no more than 10 minutes to create.

Once it has been created, rdp onto it, and you will see that the Docker service is already running:

Then start a PowerShell admin session, and start playing. You will find there are already some images there:

docker images

Try these commands as well:

docker --help

docker --version

Across the Cloud of course the file transfers are blindingly fast – pulling down 10GB images is done in a matter of minutes, so this lot took me a max of minutes I think:


To get a new image, for example the latest SQL Server for Windows (as opposed these days to Linux, for example):

docker pull microsoft/mssql-server-windows

With that downloaded we can start the SQLServer instance:

docker run -d -p 1433:1433 -e sa_password=$dbpw -e ACCEPT_EULA=Y microsoft/mssql-server-windows

How to connect to the SQLServer instance

Run docker ps, and that gives you the Container Ids of all the running Docker… Containers:

docker ps


Stick that container id in a variable for later use, and run the inspect switch to get the ip address of the container..

docker inspect -format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $containerId

I could not see how to get the ip address directly into a variable, so again you have to do that by hand, e.g.

$dbServer="123.45.675.890"

Now test your connectivity with sqlcmd before trying through ssms:

Now see my recent post on SSMS installation, and you see that what you created through the command line now appears in SSMS:

And finally for now shut down the container. In this shot, I try to stop a nonsense container, just to see how failure looks, and then stop the actual container. However I’d like better feedback than that (see the 2 docker stop lines). The second one has presumably silently failed. Trying to run sqlcmd against that ip address now fails… as you would want and expect. And although not shown, [docker ps] returns an empty set.

 

dockertake2_15

I don’t yet know how to run many containers against a single image, but this suggests to me it is possible.


https://blogs.technet.microsoft.com/dataplatforminsider/2016/10/13/sql-server-2016-express-edition-in-windows-containers/

https://store.docker.com/images/1bc596e5-6961-4d12-8465-c0e7c3cad4bb?tab=description

https://hub.docker.com/r/microsoft/mssql-server-windows/

https://hub.docker.com/r/microsoft/mssql-server-windows-express/

https://www.docker.com/products/docker#/azure

https://beta.docker.com/

https://beta.docker.com/docs/azure/