Ef6: issues moving from migrate.exe to ef6.exe

[joelmdev]

Bumped up to EF 6.4.0 today having previously been on 6.2.0. Until today we used migrate.exe in our CI pipeline to make sure DBs are up to date. Eventually realized migrate.exe was replaced by ef6.exe and pieced together some documentation from around the web on how to use the latter (seems there's no official documentation at the time of this writing). Here's what we were executing previously:

packages\EntityFramework.6.2.0\tools\migrate.exe MyDataAccessProject /StartupDirectory:Web\bin /connectionProviderName:"System.Data.SqlClient" /connectionString:"myConnectionString"

and now we have this:

packages\EntityFramework.6.4.0\tools\net45\any\ef6.exe database update --assembly MyDataAccessProject.dll --project-dir Web\bin --connection-provider "System.Data.SqlClient" --connection-string "myConnectionString"

Web is the project that we build and deploy that references MyDataAccessProject, and MyDataAccessProject is where all of our EF6 stuff lives. I believe what we've done is a direct port from migrate.exe to ef6.exe but it's returning a rather curious error message:

Your target project 'MyDataAccessProject' 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.

Well yes it does, as long as we're talking about ef6, which we are- that's the name of the tool. Why is this ef6 tool talking about efcore? More importantly, what's wrong with the command I've ported?

Further technical details

EF version: 6.4.0
Operating system: Windows 10
Build Server: TeamCity Professional 2019.1.3 (build 66439)

[joelmdev]

If you need additional information on this issue, please let me know. As it stands, we cannot deploy schema changes without rolling back to pre-6.3.0 (bad), or connecting to prod database through VS and running update-database manually (worse).

[ErikEJ]

Maybe you need to specify the startup project: https://github.com/dotnet/EntityFramework.Docs/issues/1740

[joelmdev]

@ErikEJ --project-dir is ef6.exe's replacement for migrate.exe's /startUpDirectory. I've included the former in the original post for this issue.

[joelmdev]

Ok think I found it. Adding relative path to --assembly argument seems to have allowed migrations to run. Apparently --assembly is not relative to --project-dir as the equivalents were when using migrate.exe, and the resulting error messaging when omitting the path is very poor.

I could sub "MyDataAccessProject.dll" with "ImARandomEffingStringThatDoesntPointToADLL.dll" and I'd get the following error message:

Your target project 'ImARandomEffingStringThatDoesntPointToADLL' 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.

Technically I suppose that a null project indeed does not reference EntityFramework, but this should be clearer. Based on that I have the following recommendations for the EF6 team regarding the ef6.exe tool:

1. Error message should indicate when referenced assembly does not exist.
2. Remove mention of "Entity Framework Core Tools" from messages generated by this tool.

[yokovaski]

Ran into the same problem in our pipeline. Our assembly is in the same location as an EntityFramework.dll but I got the same message:

Your target project 'Example.dll' 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.

The solution in our case was to specify the absolute directory of the assembly. I.E.

packages\EntityFramework.6.4.4\tools\net45\any\ef6.exe database update --assembly "C:\path-to-assembly\Example.dll" --connection-provider System.Data.SqlClient --connection-string "myConnectionString" --verbose