Dotnet Core 1.1 Gotchas

Just a quick post on a few gotchas and other things I stumbled into when updating a project to .NET Core 1.1.

What’s in a version number?

.NET Core 1.1 is not replacing 1.0. With the release of 1.1 the 1.0 version is now the long term support (LTS) release. 1.0 LTS being a more stable bedrock (but will still receive updates in parallel to 1.1) and for those brave adventurers that like to be on the cutting edge we can play with 1.1

Runtime and tooling versions

Just to add to the version number confusion, the .NET Core runtime and the tooling/SDK exist at different version levels. This is apparent when downloading the SDK for .NET Core 1.1 you’ll get a file called (something like) “dotnet-dev-win-x64.1.0.0-preview2-blahblah.exe” I genuinely thought at first this was a mistake “I want the 1.1 version damnit!” and some sort of error on the download site. But it is correct, in .NET Core world the SDK and more importantly the command line tools have a lifecycle of their own and maybe not in step version number wise with the runtime. Weird, but that’s how it is.

How to upgrade your project to 1.1

This one was covered in the blog post announcing the 1.1 release but it’s worth re-capping I think. If you have a 1.0 project you want to update to .NET Core 1.1 you need to edit project.json and focus on two sections. In the dependencies change Microsoft.NETCore.App to 1.1.0 and in the frameworks section the netcoreapp1.0 reference will need to change to netcoreapp1.1 (note your imports here might be different). E.g


Entity Framework Core 1.1

If you’re using Entity Framework Core in your project you’ll probably want to update that to version EF Core 1.1 (yes EF Core has a release lifecycle and version numbing separate from both base .NET Core and the SDK!) If you’re using the “dotnet ef” command line tooling, you’ll likely run into some problems when upgrading your packages to 1.1.0. I’ve seen the dreaded “Entry point not found in assembly” and dotnet.exe crashing hard a few times due to incompatibilities.
GOTCHA NOTE. The name of the tools package has changed from Microsoft.EntityFrameworkCore.Tools to Microsoft.EntityFrameworkCore.Tools.Dotnet (as detailed but buried in this blog post)

Here’s the combo in my project.json that worked for me (at the time of writing, of course!)

dependencies section:

tools section:


Precious Secrets

If you are using the User Secrets feature of .NET Core (and you should it’s super helpful) you’ll stumble across another gotcha. In the update to 1.1 they changed how User Secrets works and removed the dependency on having an userSecretsId value in your project.json.

The change is detailed & documented in this issue on Github, so you’d be forgiven for totally missing it! Apparently there were good reasons for doing this, I can’t say I care strongly enough about this to find out the reasons. However it’s worth nothing that the fallback option described in the documentation to this change does not work and I had to make code changes. It’s also not well described what you need to add to your code to get this to work, so let me share what worked for me.

In Startup.cs add an assembly attribute, I’d never used these before so I discovered they live at the top level, so I stuck this between my using statements and my namespace (I used the same id string and GUID I had in my userSecretsId in my project.json, this is not my real ID, I’m not silly!)

Then also in Startup.cs I modified the call to AddUserSecrets as follows, adding the <Startup> overload

And with this User Secrets sprung into life again

I bit of a brain dump but hopefully some helpful nuggets in there that you might be tripping over with .NET Core 1.1

Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *