When Visual Studio 2017 released today a few other things happened that are relevant to Entity Framework Core.
For more on EF Core, watch my EF Core: Getting Started course on Pluralsight.
EF Core Migrations Tools Release
First – something we were prepared for – the .NET Core SDK was also released. The last stable version was 1.0.0-preview2-1-003137. It’s now simply 1.0.0. Along with this, its dependent tooling, including EF Core Tools for PowerShell and dotnet were also released. As the .NET Core support evolved from project.json to msbuild, the EF Core tools split . We have been using 1.0.0-preview4 (for .NET and project.json) and 1.0.0-msbuild3 for msbuild/csproj support.
Now the tool packages are 1.1.0 (Tools) and 1.0.0 (Tools.DotNet)
For PowerShell support: Microsoft.EntityFrameworkCore.Tools 1.1.0
For dotnet CLI support: Microsoft.EntityFrameworkCore.Tools.DotNet 1.0.0
In Visual Studio 2015 (for full .NET projects) and Visual Studio 2017 (shown here, for full .NET or .NET Core projects), the Package Manager will show the RTM versions:
Notice that I do not have “Include prerelease” checked.
If using PMC to install, it’s just
install-package Microsoft.EntityFrameworkCore.Tools
That’s for the PowerShell tools, otherwise, add .DotNet to the name.
But notice that you no longer need to add the –pre.
When using the CLI version of the tools, the command
dotnet ef –version
results in
Entity Framework Core .NET Command Line Tools 1.0.0-rtm-10308
Changes to Migrations Commands
As the tools evolved through the previews, some details changed for example, the scaffolding command got smarter.
But one change that is notable is with respect to EF Core in class libraries. You still need to point to an executable project (exe or test) to run most of the commands, but now you can at least just use “dotnet ef” to get the help file without having to set the –startup-project parameter. There are a few other commands that will run without knowledge of the startup project. You can read more about this in this GitHub thread. Check some of the later comments by Brice Lambson as he worked on evolving the commands.
EF Core 1.1.1 – Patch
This was a more subtle part of the release. Even though the 1.1.1 milestone on GitHub had 30 bug fixes that are all closed , there hadn’t been any mention that this was going to get pushed out and the milestone had no target date on it. Though I had my suspicions! Here’s a screenshot I happened to take on March 5.
And yes, the newest version of the EF Core packages is now 1.1.1. These are bug fixes …as the increment suggests. Most of them are edge cases, but regardless, you should definitely update your EF Core packages to ensure you have these latest fixes. If you’re creating new projects, 1.1.1 is what you’ll see available from NuGet.
Note: there was a regression introduced in EF Core 1.1.1 that is targeted to get fixed with the next patch. You can read about this issue here: http://stackoverflow.com/questions/42708522/loading-related-data-aspnet-core-1-1
You can learn much more about EF Core in my EF Core: Getting Started course on Pluralsight.
Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!
Too many contractions of “it is” where you obviously intended the personal possessive pronoun “its” – get a copy editor!
Thanks for the helpful comment. There were TWO. I replaced one with the word “the” and fixed the other. Let me know if I missed one. (You’re my new copy editor!)
Since your Pluralsight course that I am taking is marked “closed for comments”, I’m forced to ask this question here.
I’m using Visual Studio 2017 Enterprise edition with the first official patch applied.
In Module 2, I go to add my very first migration in the package manager console, making sure that the Default project: dropdown is set to SamuraiApp.Data, I try to run the following command:
Add-Migratoin Init
The error comes back as:
System.IO.FileNotFoundException: Could not load file or assembly ‘Microsoft.EntityFrameworkCore.Design’ or one of its dependencies. The system cannot find the file specified.
File name: ‘Microsoft.EntityFrameworkCore.Design’
at Microsoft.EntityFrameworkCore.Tools.Program.Main(String[] args)
My first guess is that there is a mismatch between 1.1.1 vs. 1.1.0 editions of some packages.
The relevant package.config settings are:
I have tried using the -Pre switch to get a newer edition (1.1.1?) of the Tools to match up with the Design pieces, but have not found anything as of 2017-03-21.
What am I missing or doing wrong?
Re pluralsight comments…yes…Adobe (who owns LiveFyre) is sunsetting LiveFyre and Pluralsight didn’t get a warning when the comment system was shut down. They are working hard to get a replacement system up and running as quickly as possible.
I have revised the VS2017 demos since the release and am waiting for Pluralsight to publish the changes I made.
But …isn’t that the message that I also get (intentionally) and follow up with saying that you’ll need to add an executable project because migrations can’t run from a class library? And so in the demo, I then add a .net core console project, add the design package and then show you how to run the migration from the data project folder while pointing to the console. IF NOT, say so and we’ll see what’s happened in your case!
I peeked ahead at the final module. I have only gotten as far as the beginning of “Coding with EF Core and Visual Studio Code”, but, so far, no mention of the need to create a dummy EF.Core Console app (which I assume needs to be the start up project too?).
Is the part about creating a dummy EF.Core Console App in VS 2017 somewhere *after* the discussion about Visual Studio Code? The topic headers don’t really give me a clue as to how far into that module I need to go before the “magic fix” gets discussed. 🙂
OK, despite the confusion about where EXACTL in the Pluralsight course the information about using VS 2017 and the lack of Package Manager (vs. dotnet ef) examples, I figured out what to do.
1. Do NOT (unlike what is suggested in the video) skip ahead to the last module to find out how to do Add-Migration with VS 2017 RTM. The information is LATER on in module 2 (sort of).
2. Modify (if not already modified) SamuraiContext.cs to include a parameterless constructor. Since you’re in there anyway, may I suggest the following which includes some comments that explain EXACTL Y WHY you need that type of constructor:
public SamuraiContext()
{
// cannot run Add-Migration or Update-Database without this parameterless constructor
// Add-Migration -Name ‘Init’ -Project ‘SamuraiAppCore.Data’ -StartupProject ‘CoreUI’ -Verbose
// Update-Database -Project ‘SamuraiAppCore.Data’ -StartupProject ‘CoreUI’ -Verbose
}
Notice the example above uses the Package Manager Console. Since the course video only shows the “magic trick” of specifying the startup project using the command line ef tool in order to use EF.Core migrations, I hope my example helps others struggling with the same “have to fight with the tool” battles that I find myself engaged in with Visual Studio 2017 RTM when it comes to using any of the .net core “stuff”.
Thanks. Good catch When I redid the demos after the VS2017 release, I noticed that I didn’t mention the parameterless constructor and in the testing demos when I added the new ctor (which overrides the implicit (inherited) parameterless ctor) I added the parameterless one in and explained why. Sorry I missed that the first time around. Sorry for any confusion. My whole goal for doing these videos is to help you avoid the type of confusion that comes from doing these things on your own.
Also, my point about skipping ahead to the VS2017 demos was more to have you see what the csproj looks like more than anything else. Sorry that you felt misled by that.
I’m at the point of your Pluralsight course where I’m switching from using CoreUI as the startup to SamauraiWebApi as the startup. I wanted to start from scratch with a new database, so I deleted the Migrations folder and tried the following from Package Manager Console:
PM> Add-Migration Init -StartupProject SamuraiWebApi -Verbose
However, I’m getting a strange (totally useless) error.
Using project ‘SamuraiAppCore.Data’.
Using startup project ‘SamuraiWebApi’.
Build started…
Build succeeded.
C:\Program Files\dotnet\dotnet.exe exec –depsfile C:\projects\SamuraiAppCore\SamuraiWebApi\bin\Debug\netcoreapp1.1\SamuraiWebApi.deps.json –additionalprobingpath C:\Users\fpmor\.nuget\packages –runtimeconfig C:\projects\SamuraiAppCore\SamuraiWebApi\bin\Debug\netcoreapp1.1\SamuraiWebApi.runtimeconfig.json C:\Users\fpmor\.nuget\packages\microsoft.entityframeworkcore.tools\1.1.0\tools\netcoreapp1.0\ef.dll migrations add Init –json –verbose –no-color –prefix-output –assembly C:\projects\SamuraiAppCore\SamuraiWebApi\bin\Debug\netcoreapp1.1\SamuraiAppCore.Data.dll –startup-assembly C:\projects\SamuraiAppCore\SamuraiWebApi\bin\Debug\netcoreapp1.1\SamuraiWebApi.dll –project-dir C:\projects\SamuraiAppCore\SamuraiAppCore.Data –content-root C:\projects\SamuraiAppCore\SamuraiWebApi –data-dir C:\projects\SamuraiAppCore\SamuraiWebApi\bin\Debug\netcoreapp1.1\ –root-namespace SamuraiAppCore.Data
Using assembly ‘SamuraiAppCore.Data’.
Using startup assembly ‘SamuraiWebApi’.
Using application base ‘C:\projects\SamuraiAppCore\SamuraiWebApi\bin\Debug\netcoreapp1.1’.
Using content root ‘C:\projects\SamuraiAppCore\SamuraiWebApi’.
Using root namespace ‘SamuraiAppCore.Data’.
Using project directory ‘C:\projects\SamuraiAppCore\SamuraiAppCore.Data’.
Using data directory ‘C:\projects\SamuraiAppCore\SamuraiWebApi\bin\Debug\netcoreapp1.1\’.
Add-Migration : Exception calling “Substring” with “1” argument(s): “StartIndex cannot be less than zero.
Parameter name: startIndex”
At line:1 char:1
+ Add-Migration Init -StartupProject SamuraiWebApi -Verbose
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Add-Migration], MethodInvocationException
+ FullyQualifiedErrorId : ArgumentOutOfRangeException,Add-Migration
PM>
I’ve tripled-checked the connection string in appSettings.json, which for me points to my local SQL Server 2016 Developer edition:
“ConnectionStrings”: {
“SamuraiConnection”: “Server = . ; Database = SamuraiDataCoreWeb; Trusted_Connection = True; ”
}
Is there a better place to find the “real error” for the above?
More “What Mother [Microsoft] Didn’t Tell You About EF Core 1.1”:
public class SamuraiContext : DbContext
{
#if USE_NO_POWERSHELL_CMDLETS
public SamuraiContext()
{
// 1. Absolutely REQUIRED to run ef command line tools, which look for a parameterless constructor before running
// 2. Absolutely FORBIDDEN when running the PowerShell cmdlets – if you leave this in your will get a VERY USELESS error
// messsage accusing you of not providing a database provider
// Therefore, Microsoft is FORCING you to choose EITHER the EF commands OR the EF PowerShell cmdlets, but
// you CANNOT HAVE BOTH !!!
}
#endif
public SamuraiContext(DbContextOptions options)
: base(options)
{
}
Frank, isn’t this the same conversation you brought up and I responded to a few days earlier? Unfortunately I’m STILL waiting for Pluralsight to publish the updates.