Activities of "pajokit"

Hi,

This seems like a lot of work for something that used to work and came as a total surprise to us as it was a big breaking change that was not documented anywhere.

What is the path forward here to actually use ABP and ABP Suite as intended and we want to avoid tedious handcrafting with every change?

Thanks.

Hi,

Thanks. And where is this change documented as we were not able to find it? We tried to upgrade to latest ABP Suite btw but were told as it loaded the Solution that we needed to downgrade. This seem like a breaking change with no way out of besided stop using ABP Suite and change code by hand with zero documentation besides the answer above?

Team please

ABP Suite 10.4.0 regeneration silently renames many-to-many join entities, producing a data-destroying migration Environment • ABP Commercial 10.4.0 (.NET 10, EF Core, Angular UI, non-tiered) • ABP Suite 10.4.0 via ABP Studio CLI 3.1.0 (Suite version matched to framework version as instructed by ABP Studio) • Solution created January 2026 with the then-current Suite; entities generated at that time and untouched by Suite since

What we did Using ABP Suite 10.4.0, we regenerated two existing entities (Worker, CompanyRepresentative), each to add a single new nullable string property. The entity definitions in .suite/entities/*.json were otherwise unchanged — in particular, the NavigationConnections sections (each entity has a many-to-many connection named "Companies" to the Company entity) are byte-identical to the original.

What Suite generated With identical navigation-connection input, Suite 10.4.0 named the generated artifacts differently than the original generation did: • Join entity class: was WorkerCompany, now WorkerCompanies • Collection methods: were AddCompany / RemoveCompany, now AddToCompanies / RemoveFromCompanies • Join table in the DbContext: was AppWorkerCompany, now AppWorkerCompanies The same applies to the other entity: CompanyRepresentativeCompany became CompanyRepresentativeCompanies, with the corresponding method and table renames.

Consequences

1. Compile errors in all hand-written code calling the generated API (data seeders, import services) — mechanically fixable, but nothing warned us.
2. A data-destroying migration. The scaffolded EF migration expresses the table rename as DropTable + CreateTable, not RenameTable. Applied to any environment with data, it silently deletes all rows of the association tables. In development this passed unnoticed because the database was fresh; against a production database it would have destroyed the worker/company and representative/company relationships.
3. Orphaned files. The old join entity classes (WorkerCompany.cs, CompanyRepresentativeCompany.cs) are left in the project, referenced by nothing.
4. Regenerated test seed contributors get new random GUIDs, which breaks cross-entity FK references in test files for entities that were not regenerated — the test suite then fails at module initialization with SQLite FK violations.

Questions

1. Is the join-entity/method/table naming change between Suite versions intentional? Which version introduced it?
2. Where is it documented? We could not find it in the 10.0 migration guide, the commercial release notes, or the Suite documentation. If regeneration output can change naming conventions between versions, that would seem to warrant a documented breaking change, given that the resulting migration destroys data.
3. What is the recommended path for existing solutions regenerating pre-existing entities under 10.4.0 — is there a way to keep the original naming convention, or is the intended fix to hand-edit the scaffolded migration to use RenameTable?
4. Is Suite expected to remove the obsolete join-entity files it previously generated?