Reverse Engineer: Ability to generate entity classes in a different location

[rowanmiller]

In past versions folks often move the EDMX based T4 templates for entities to a separate project. We should have the ability to specify a different location to write out the entity classes.

[tonysneed]

Proposed implementation of this in #10156. Let me know what you think of the design and if you might accept a PR.

[bricelam]

Another alternative would just be to have something like a --output-dbcontext-dir. To put the generated file in separate project.

[bricelam]

We're happy to work with you on a PR. I think we need to design it from the perspective of the Scaffold-DbContext and dotnet ef dbcontext scaffold commands first before worrying about the implementation.

[tonysneed]

Yes, I'd like to take this one on and submit a PR. So from the scaffold command perspective, there could be an arg -g|--generation-options <OPTIONS> where the options would be context, entities or all. What do you think?

[smitpatel]

Is it about generating files in different locations or different projects ?

@tonysneed - It should be single command invocation with parameters passed to generate files in different locations. An arg specifying context location & another arg for entityTypes location.
Having --generation-options is bad idea since, if you scaffold context using it and then later scaffold entities but if your database changed in between invocations then project will not compile. Also it adds friction to user experience since command needs to be run twice.

[tonysneed]

Oh yes, I was thinking of options for what to generate (context, entities, or both), rather than where to place the generated entities. I actually think it's OK to generate the context and entities independently, because you may want to do it in two steps, knowing that the database has not changed in between.

The reason this is important is that code generation may not be just for C# classes. For example, I'm planning on creating a package that generates TypeScript files from a database schema using the EF Core tooling. So in that case, I would run the generator for the entities independently from the context (obviously there would not be a TypeScript version of the context).

Another reason for independent content and entities generation is that my package allows customization of generated entities / context via Handlebars templates. So a developer could generate the entities, then customize the template, then re-generate the entities, without the need to generate the context, because he or she has not customized the context template.

In addition to the --generation-options arg, you could also have two args for context and entities locations, which if supplied could determine the location of the generated classes. This is especially helpful for generating entities that should be in a .NET Standard project, or even an Angular project (for TypeScript classes).

[tonysneed]

@bricelam It looks like this may actually be a different issue than #10156, because what I'm proposing there is to add an option to generate either a context class without entities, entity classes without a context, or both (the default). That's different than this issue, which is to generate both context and entity classes, but output them to different locations. If #10156 is a no-go, then it should be marked with a closed-not-needed label.

As far as this issue is concerned, how about adding two args: --output-dbcontext-dir and --output-entities-dir. Then the developer can specify alternative output locations. This is especailly useful because you are currently limited to generating entities in a .NET Core app or library, but if you are using a repository / unit of work pattern, you would want to place your entities in a .NET Standard library, and your context class either in an ASP.NET Core app or a separate .NET Standard library.

If these command args make sense, then perhaps we could take a look at the API changes that would be needed?

[bricelam]

We'd have to re-discuss #10156 if you want to go that route. Feel free to re-open it.

We already have --output-dir, so I think just adding --output-dbcontext-dir is sufficient.

[bricelam]

FYI, when #8434 is implemented we'll probably also need an --output-configurations-dir

[tonysneed]

I love it. Happy to Roll up my sleeves. Just wanted to make sure I understand the design. Are you saying there should be one argument for the location of the context, the other argument for the location of the entities? Meaning the context and entities could be generated two different directories?

[bricelam]

Yes.

There is already one argument for the location of everything (--output-dir), so we just need an argument to make the location of the DbContext different. (the proposed --output-dbcontext-dir)

[tonysneed]

OK, what I'm thinking is clearest is to keep just --output-dir and add an option of what to generate (context only, entities only or both), as I proposed in #10156. Then you could easily generate the context to one location, and the entities to another location, by specifying a different --output-dir when you select --generation-options "ContextOnly" versus --generation-options "EntitesOnly" (for example). By default both context and entities would be output to the same location as specified by --output-dir.

[tonysneed]

We'd have to re-discuss #10156 if you want to go that route. Feel free to re-open it.

I don't think I can the rights to re-open this issue (since I didn't close it). :)

[tonysneed]

+1 for @bricelam's suggestion to add a --output-dbcontext-dir option.

What API changes would this require? I'm happy to pitch in and submit a PR for this.

[smitpatel]

From C# code generation part. https://github.com/aspnet/EntityFrameworkCore/blob/dev/src/EFCore.Design/Design/OperationExecutor.cs#L417

This is what tools code into Design package to generate everything so from there, we just need to pass in additional arg to CSharpScaffoldingGenerator which actually writes the files.

In EF command side this is where all command variations calls into design package. So you can back track way from there to update PowerShell & and configure dotnet ef but that could be bit difficult.
https://github.com/aspnet/EntityFrameworkCore/blob/dev/src/ef/Commands/DbContextScaffoldCommand.cs

[tonysneed]

I’ll start digging and can submit a PR for this.

Update: I got busy with other things the past couple of weeks, but I plan to revisit this shortly.

[tonysneed]

I opened PR #10356 to address this issue by adding --output-dbcontext-dir to generate the DbContext class in a different location. I updated both the code generation and EF commands.