-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reverse Engineer: Ability to generate entity classes in a different location #1836
Comments
Proposed implementation of this in #10156. Let me know what you think of the design and if you might accept a PR. |
Another alternative would just be to have something like a |
We're happy to work with you on a PR. I think we need to design it from the perspective of the |
Yes, I'd like to take this one on and submit a PR. So from the scaffold command perspective, there could be an arg |
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. |
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 |
@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: If these command args make sense, then perhaps we could take a look at the API changes that would be needed? |
We'd have to re-discuss #10156 if you want to go that route. Feel free to re-open it. We already have |
FYI, when #8434 is implemented we'll probably also need an |
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?
|
Yes. There is already one argument for the location of everything ( |
OK, what I'm thinking is clearest is to keep just |
I don't think I can the rights to re-open this issue (since I didn't close it). :) |
+1 for @bricelam's suggestion to add a What API changes would this require? I'm happy to pitch in and submit a PR for this. |
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 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. |
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. |
I opened PR #10356 to address this issue by adding |
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.
The text was updated successfully, but these errors were encountered: