Add a REPL for dotnet-ef

[sliekens]

I have my DbContext in a class library, so dotnet ef commands always have to be qualified with either a --project or a --startup-project or both, depending where I run the command.

It would be helpful if dotnet ef came with a REPL that remembers these parameters for the duration of a terminal session.

Something like this:

$ dotnet ef interactive --project MyDataAccess
                     _/\__
               ---==/    \\
         ___  ___   |.    \|\
        | __|| __|  |  )   \\\
        | _| | _|   \_/ |  //|\\
        |___||_|       /   \\\/\\

Entity Framework Core REPL

Commands:
  database    Commands to manage the database.
  dbcontext   Commands to manage DbContext types.
  migrations  Commands to manage migrations.

dotnet ef>  migrations add SomeChanges
Build started...
Build succeeded.
Done. To undo this action, use 'migrations remove'

dotnet ef> migrations list
Build started...
Build succeeded.
20241116123911_Initial
20241116125308_SomeChanges

dotnet ef> migrations remove
Build started...
Build succeeded.
Removing migration '20241116125308_SomeChanges'.
Reverting model snapshot.
Done.

dotnet ef>

Possibly, this could be further optimized to skip the project build for side-effect free commands. For example, migrations remove after migrations list does not really need a rebuild since migrations list does not have any side-effects.

[ajcvickers]

We talked about this in a team meeting. Historically, for this scenario, we have suggested the guidance here: #20862 (comment). I'm copy/pasting the text from @bricelam here, so we can decide whether this is still what we want to:

Just to publicly state my stance on this, I don't think we'll ever be able to provide something that's more discoverable or simple than a script file can provide.

For example, by creating a file named ef.cmd (or an equivalent .sh file on macOS and Linux) in the root of your project with contents like the following:

@dotnet ef --project MyApp.Data --startup-project MyApp %*

And using commands like the following:

ef migration add MyMigration
ef database update

Or if you have multiple contexts or projects, use response files. For example create a file named identity.rsp with the following contents.

--context=IdentityContext
--project=MyApp.Data
--startup-project=MyApp

And use it like this:

dotnet ef database update @identity.rsp

[bricelam]

I do like the idea of a session that knows it doesn't have to rebuild, but the incremental-build-friendly improvements made in 9.0 probably make this less important.

[roji]

Another possible approach here would be to have environment variables which serve as the defaults for the above (e.g. EF_CONTEXT, EF_PROJECT, EF_STARTUP_PROJECT). AFAIK response files are more of a Windows thing, I don't remember having seen them on Unix in general.

But in any case, I definitely don't think EF should have a REPL - it simply doesn't make sense for the things people do with EF; this isn't a database interface (like sqlcmd) or a programming language (like C#) - it's something that users use occasionally for a single operation only. The actual ask here (which I find reasonable) seems to be to not have to specify the same parameters every time you execute the command (regardless of the specific mechanism).

[sliekens]

I like the idea of the environment variables because that would also be useful in scripting. The REPL is probably something I could bolt on myself with a console app that wraps dotnet-ef.

[roji]

Closing in favor of #35231, which is a general write-up of the problem and the possible solutions.

[roji]

Duplicate of #35231