Hi team,
I'm working on a commercial ABP project and I've encountered a limitation that makes ABP Suite difficult to use in long-running projects.
According to the documentation, ABP Suite stores entity metadata inside the .suite/entities folder and uses those JSON files as the source for code generation.
However, this creates a problem when entities are created or maintained outside ABP Suite.
Scenario
Suppose I have an existing solution.
Some entities were generated with ABP Suite.
Other entities were created manually (or evolved manually over time).
Example:
Region Province City
These entities compile correctly, EF Core works correctly, CRUD pages exist, migrations exist.
From a developer's point of view they are perfectly valid ABP entities.
Problem
When I try to create a Child entity or add Navigation properties in ABP Suite, the UI allows me to select those entities.
However, when generating the code, Suite fails because it expects the corresponding metadata file:
.suite/entities/Region.json
If the entity was not originally created by Suite, this file does not exist, therefore generation fails.
Example error:
Cannot find the entity 'Region' ... .suite/entities/Region.json Expected behavior
One of these approaches would make the experience much better.
Option 1 (preferred)
Provide a way to synchronize an existing solution with the .suite metadata.
Something like:
Import Existing Entities
or
Rebuild .suite metadata
that scans the solution and generates the missing JSON metadata for existing entities.
This would allow Suite to continue working even after years of manual development.
Option 2
If automatic synchronization is not possible, the UI should clearly prevent selecting entities that are not managed by Suite.
Currently the UI lets the user configure relationships that are guaranteed to fail during generation.
Why this matters
In real projects:
entities evolve over time; developers sometimes create entities manually; entities may come from external modules; code may be refactored independently from Suite.
After that point, those entities become impossible to use as:
Master entities Child relationships Navigation properties
even though they are perfectly valid ABP entities.
This creates a "point of no return": once an entity exists outside Suite metadata, it cannot fully participate in Suite code generation.
Question
Is there currently any supported way to regenerate or synchronize the .suite/entities metadata from an existing codebase?
If not, would you consider adding such a feature?
I think it would significantly improve the long-term usability of ABP Suite.
2 Answer(s)
-
0
There is currently no supported/official way to “rebuild” or “synchronize”
.suite/entities/*.jsonfrom an existing codebase (C# entity classes). ABP Suite’s code generation expects the corresponding.jsonmetadata file to exist; without it, generation (including relationships/navigation configs) can fail with errors like “Cannot find the entity … Region.json”. This matches the current product behavior described in ABP’s support answers: Suite needs the relevant.jsonfile and it is not automatically possible to generate it from entity classes.Supported workaround (today): bring the missing entities into Suite by generating the JSON metadata files, then place them under
.suite/entities/.- The officially supported path is database/table-based import (Suite can generate entities from an existing database table), which results in Suite-managed metadata.
- If your entities already exist only in code (not via Suite), there isn’t an official “import from code” feature; you’d need to manually/externally produce the JSON files (some community members have built small generators for this and then copy the JSON into
.suite/entities).
About your “Option 2” expectation (UI preventing selection): As of the current behavior, Suite may let you select entities that are present in the solution, but generation still relies on the
.suitemetadata; there isn’t a documented guard that filters out non-Suite-managed entities.
If you’d like this added as a feature request (“Import existing entities / rebuild .suite metadata”), please contact the team so it can be tracked and prioritized.
(Less obvious) references
- https://abp.io/docs/latest/suite/generating-entities-from-an-existing-database-table
- https://abp.io/community/articles/8fomzrdk
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
Markdown supported.Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post) -
0
Hi,
There's no supported way today to rebuild the
.suite/entitiesmetadata from your existing C# classes. But you can still use your hand-written entities in Suite relationships — the trick is that Suite's relationship generators expect a DTO (and, for master-detail, metadata) for the entity on the other end, and the default guesses a name that doesn't exist for a hand-written entity.For the common case — a Suite entity that references an existing one (e.g.
City->Region) — use a navigation property, not master-detail, and point it at your DTO:- Add the navigation property on the new entity and pick
Regionas the target entity. - Open the Advanced tab of the navigation dialog. Under Dependent DTO, set
Dto name/Dto namespaceto a real DTO forRegion(browse the.csfile, or type the name/namespace). If you don't already expose one, add a smallRegionDtowith the properties you want to show. - Generate.
That's it —
Regionstays exactly as you wrote it (the class and the DTO are untouched), the new entity gets the foreign key and lookup, and everything compiles. The defaultDto nameis<Entity>Dto, so if that type doesn't exist you get theRegionDto could not be foundcompile error; setting it to your actual DTO is what fixes it. The genericIRepository<Region>and the entity-to-DTO mapping are resolved automatically, so as long as the DTO's properties line up with the entity you don't need to wire anything else.Master-detail (child) relationships are different: they read the master from
.suite/entities/<Master>.jsonand, when you generate the child, Suite regenerates the master's own code. So that path expects the master to be a Suite-managed entity — pointing it at a hand-written master will overwrite that entity's code. If you specifically need master-detail on an existing entity, plan to let Suite own it (you can use Load Entity From Database to pull the table, then move any custom logic into the*.Extendedpartial classes before generating, since the first generation rewrites the Suite-managed files).On your suggestions: the UI could warn (or filter out) entities that aren't managed by Suite instead of letting you set up a relationship that then fails at generation — that's a fair point. And there's no import/rebuild of
.suitemetadata from existing code today either. Both make sense for long-running projects and I'll pass them to the team.Thanks
Markdown supported.Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post) - Add the navigation property on the new entity and pick
