Skip to content
This repository has been archived by the owner on Jan 16, 2024. It is now read-only.

Import Code results to no entities on the designer surface #225

Closed
alprinias opened this issue Oct 28, 2020 · 6 comments
Closed

Import Code results to no entities on the designer surface #225

alprinias opened this issue Oct 28, 2020 · 6 comments
Labels
enhancement New feature request released Issue is resolved in a current release
Milestone

Comments

@alprinias
Copy link

I am having the folloing situation:
An existing database.
Using "Scaffold-DbContext" -UseDatabaseNames -force -DataAnnotations created entity classes and dbcontext from the database in a new "scaffold" project in a solution.
Added a new project "EFDesigner" and a designer item in this project.
Dragged a single class from the scaffold project to the designer surface
Nothing shows up in the designer surface. The .efmodel xml is updated, however the efmodel.diagramx is not updated
When code is generated, the class is generated and it is added in the dbcontext in the code.
Closing and opening the designer file does not change something.

Did all this after having imported all the code files from windows explorer, also the compiled assembly, with the same result. It seems that the diagramx file wouldn't update.

What am I doing wrong? All this with the 2.0.5.3 version.

Best,
Alex

@msawczyn
Copy link
Owner

Actually, nothing. When multiple diagrams were added, there was a change to not add consumed classes directly to the diagram. The thought being that multiple diagrams will typically be used to show different areas of concern in the application, and it's a bit of a pain having to remove all those classes when you didn't want them to be on that particular diagram. It's always possible to drag them from the entity model explorer onto the diagram precisely where you want it placed.

Clearly, though, that's not intuitive -- it should at least ask if you wanted them added. I've added an enhancement request for that feature; it isn't too difficult.

Thanks for bringing it up!

@msawczyn msawczyn added the enhancement New feature request label Oct 28, 2020
@alprinias
Copy link
Author

Thanks, Michael.

Something else I noticed, which must be related. As I said, I dragged one class from my scaffolded project. After your comment, I went to the Entity Model Explorer to drag it to the design surface from there, so that it shows up, and indeed it dod. However, I saw that all related entities (which I had not dragged) were also present on the Entity Model Explorer, which I suppose is correct, since they are properties of that single one I imported. When I dragged one of those, the entity was created on the design surface but without any properties, just the name. Still correct, since I hadn't imported it. I continued by going to the original project and imported that second class by dragging it onto the designer surface. It dodn't show up, but now I knew the trick, I saved and dragged it again, now from the Entity Model Explorer. No properties were added. Then I closed the designer and opened it again and the properties showed up. All correct.
Then I started adding the rest of the related classes in the same way. By mistake, I dragged again the second entity which I had already imported. And then, I saw compiler errors. It turns out, that the properties of the created entity corresponding to the doubly-imported class, are not overwritten the second time, but new (same) properties are added. Both to the entity and to the DBContext modelbuilder.
That's FYI from my experience.
All the best,
Alex

@alprinias
Copy link
Author

One more point from my experience from importing from an existing database.

The database tables had their foreign keys defined and their names were not always simple, e.g. Table_Id. These were imported to the model and designer, but the model then created new properties for the associations. Fair enough, I would not expect the designer to know which column refers to which association. I then had to expose the foreign keys (at model level) and go through each association and set the foreign key column name to the already existing in the table, which resulted in the little blue key icon to appear next to the column names. But in this way I am "obliged" to expose the foreign keys in the models. If I go and select "false" for exposing the foreign keys at model level, the foreign key names I set are lost.

So, I think an enhancement would be to be able to set the foreign key name even if the foreign keys are not exposed in the model.

Best,
Alex

@npagare
Copy link

npagare commented Nov 3, 2020

Hi @msawczyn ,

I am using the latest stable version 2.0.5.6
I see following message but no entities / enums are shown on the design surface including related ones. I would like to see those entities.

image

Is there a way to indication draw only the entity for the dragged class file ?
I am building a new ER model where enums are created using enums from toolbox for .efmodel file.
My existing class enum classes have custom values of type (character). Those related enums getting added in .efmodel as entities (which I don't want) in Classes under Entity Model Explorer panel.

Your help will be appreciated,

Thank you

@npagare
Copy link

npagare commented Nov 6, 2020

Hi @msawczyn , any thoughts?

Thank you.

@msawczyn
Copy link
Owner

msawczyn commented Nov 7, 2020

Regarding the enum problem, could you please pinch that off as a separate issue and describe fully what's happening? While I think what you're describing does involve the import, it seems to indicate that the importer is improperly classifying enumerations as entities, which is quite puzzling as that should never happen, being as it's Roslyn that's doing the classifying.

I'd like to investigate that as a possible bug so as not to conflate it with the enhancement of automatically drawing the classes when they're imported to the model.

Thanks.

@msawczyn msawczyn added this to the 3.1 milestone Nov 17, 2020
@msawczyn msawczyn added the pending release Issue is resolved in the current codebase, will be published with the next release label Nov 19, 2020
@msawczyn msawczyn modified the milestones: 3.1, 3.0 Nov 19, 2020
@msawczyn msawczyn added released Issue is resolved in a current release and removed pending release Issue is resolved in the current codebase, will be published with the next release labels Nov 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature request released Issue is resolved in a current release
Projects
None yet
Development

No branches or pull requests

3 participants