Efcore: Run EF .NET Core CLI commands from outside of a project

[HamedFathi]

I want to run
dotnet ef dbcontext scaffold [arguments] [options]
from outside of a project.

now I must create just Console Application and run the commands inside it !

I want to use any ef commands from other C# applications with System.Diagnostics.Process.Start().

This is too important for me, Is this possible ? anyway ?

namespace dotNETEF
{
    public static class EFScaffolder
    {
        public static void Do(string path, string cnnString, string provider, string output)
        {
            Process process = new Process();
            process.StartInfo.CreateNoWindow = true;
            process.StartInfo.FileName = "dotnet";
            process.StartInfo.WorkingDirectory = path;
            process.StartInfo.Arguments = $"ef dbcontext scaffold {cnnString} {provider} -o {output}";
            process.Start();
            process.WaitForExit();
        }

    }
}

I have a class library with above code, I want to use EFScaffolder.Do() for scaffolding in any other project. but does not works.

[rowanmiller]

The dotnet ef commands are built around being called on a project. If you want to perform reverse engineering without a project, then you probably want to look at using the internal components that the tool pulls together (primarily Microsoft.EntityFrameworkCore.Scaffolding.Internal.ReverseEngineeringGenerator).

These are internal, so we may break the APIs in future releases.

[HamedFathi]

@rowanmiller , What is the meaning of 'we may break the APIs' ?
We want to create an universal code generator for our .NET Core projects so I need to know Your team delete this features (Internal ReverseEngineering) from EF Core in futures or may improve (change heavily) it ???

If Your team will delete these APIs so we should find another way unfortunately !
However, Do your team support like these APIs in futures or not ? because I want to program based on your scaffolding APIs.

[rowanmiller]

We're not going to delete the reverse engineering functionality. It's more a case that method signatures etc. may change. If it's in application code, then that's not a big deal because you can just change your code when you upgrade. If you are building a third party tool, provider, etc. then it's a bigger deal because if the app developer upgrades to a new version of EF Core then the APIs you expect to be there may not be.

BTW - I was curious about how easy this was to do, so here is a blog post showing the code you want https://romiller.com/2017/02/13/ef-core-1-1-run-reverse-engineer-from-code/

[HamedFathi]

@rowanmiller , Yes This is awesome, I hope EF Core team support this way continuously, Thanks for your help and blog post.