4
votes

We're in the final stages of porting a huge solution over to .Net Core (from 4.7.2), but we're not yet ready to migration to Entity Framework Core, as we make use of table-per-type hierarchies, etc. We use EF code-first. So, the project containing our DbContext and EF migrations is now running .netstandard2.1 and references EF 6.4 (which, as of v6.3 apparently supports .net core). I understand that the EF tooling changed from v6.2 -> v6.4, so our traditional way of creating an EF migration now results in the following error in the Package Manager Console:

add-migration TEST -project Data

Project 'Data' targets framework '.NETStandard'. The Entity Framework Package Manager Console Tools don't support this framework.

After some investigation, I came across this, which suggests that you need to use a .Net Core assembly as a dummy start-up project. After creating a .netcore 3.1 console app project (called Data_Startup, which references the Data project) and modifying my command slightly, I now get the following error:

dotnet ef migrations add TEST --project Data --startup-project Data_Startup -c CustomContext

No DbContext named 'CustomContext' was found.

This seems like it's at least attempting the migration, but I'm now stuck. I've tried fully qualifying the DbContext with the namespace and adding the DBContext class as a "linked file" to the new dummy project, but I'm faced with the same error.

I've also attempted to use the EF 6.4 tool: dotnet C:\Users\xxxx.nuget\packages\entityframework\6.4.0\tools\netcoreapp3.0\any\ef6.dll" migrations add TEST --assembly Data

Your target project 'Data' doesn't reference EntityFramework. This package is required for the Entity Framework Core Tools to work. Ensure your target project is correct, install the package, and try again.

...despite it definitely being installed in the Data project!

What am I doing wrong? Which tool do I actually need to use? Is this project configuration even possible?

3
You should include your context in your new console application after that it will find your context with the command you provided.BenceL
I've tried this and it results in the same behaviour - regardless of whether the DB Context is added as a linked or concrete file.Nick H
@NickH your link is for EF Core cli, not for EF 6.4smg
@smg Sorry - You are correct, although I'd already attempted to use the old version of the tool but was unsuccessful (for a different reason!). I've updated the question to reflect this.Nick H

3 Answers

4
votes

I know this is an older post, but I stumbled upon it when having the same problem so hopefully my solution is gonna help someone. If you have a .NET 5 or a .NET Core project and you use EF6 in it, here is how to run the migrations from PowerShell :

Adding a migration:

cd "your_solution_directory"
$assemblyDirectory = "Test.Project\bin\Debug\net5.0-windows"

& dotnet exec --depsfile "$assemblyDirectory\Test.Project.deps.json" --runtimeconfig "$assemblyDirectory\Test.Project.runtimeconfig.json" packages\EntityFramework.6.4.4\tools\netcoreapp3.0\any\ef6.dll migrations add TestMigrationName --json --verbose --no-color --prefix-output --assembly "$assemblyDirectory\Test.Project.dll" --project-dir Test.Project\ --root-namespace Test.Project --connection-string "Data Source=(LocalDB)\MSSQLLocalDB;Initial Catalog=DBNAME;Integrated Security=True" --connection-provider "System.Data.SqlClient"

Running migrations:

cd "your_solution_directory"
$assemblyDirectory = "Test.Project\bin\Debug\net5.0-windows"

& dotnet exec --depsfile "$assemblyDirectory\Test.Project.deps.json" --runtimeconfig "$assemblyDirectory\Test.Project.runtimeconfig.json" packages\EntityFramework.6.4.4\tools\netcoreapp3.0\any\ef6.dll database update --target TARGET_MIGRATION_NAME_HERE --verbose --no-color --prefix-output --assembly "$assemblyDirectory\Test.Project.dll" --project-dir Test.Project\ --language C# --root-namespace Test.Project --connection-string "Data Source=(LocalDB)\MSSQLLocalDB;Initial Catalog=DBNAME;Integrated Security=True" --connection-provider "System.Data.SqlClient"

Since using ef6.exe directly like you would in .NET Framework doesn't work these long commands seem to be the only way. If you are still having problems and my solution didn't help you, try running Update-Database or Add-Migration commands from the Package Manager Console and add the --verbose flag. This will show you the exact PowerShell command being run by Visual Studio which you will be able to reuse in your script.

Additionally, you can make it read your App.Config file, but for some reason the --configuration parameter is ignored. It always uses ef6.dll.config file which needs to be present in the assembly directory. You can setup your build configuration to always copy your App.config file to ef6.dll.config

2
votes

Finally cracked it!

Firstly, it seems that despite everything I've read from Microsoft, this project configuration is not possible. I upgraded the Data project to netcoreapp3.1 (meaning an upgrade to every other project in the solution!), which resolved the targeting and DB Context location errors. I ended up using the following command from the Package Manager Console:

add-migration TEST -connectionString "SERVER=(local);DATABASE=xxxx;Integrated Security=true" -connectionProvider "System.Data.SqlClient"

Interestingly, running the above with the verbose flag suggests that it is in fact running one of my originally attempted commands: dotnet C:\Users\xxxx.nuget\packages\entityframework\6.4.0\tools\netcoreapp3.0\any\ef6.dll migrations add Test command, BUT explicitly running this exact command fails with the familiar error

Your target project 'Data' doesn't reference EntityFramework. This package is required for the Entity Framework Core Tools to work.

...so I've no idea why the add-migration alias seems to work!

Additionally, many of the parameters that are supposed to work with the ef 6.4 tool (listed here) actually didn't work either (e.g. "--connection-string" is actually "-connectionString"), but thankfully the above command works perfectly. In short, the documentation for EF 6.4 tooling is an absolute mess. Hopefully these findings are of use to anyone else in the same, painfully frustrating situation.

0
votes

Instead of creating a dummy project, you could also temporarily change the target framework to either net48 or netcoreapp3.1 while running the commands.