Thanks — the first three points are clear and useful, and the recommendation matches what our measurements pointed to, so the product decision is settled on our side.
Two questions remain open, and I would appreciate a review from the team: the reply came from AI-Bot and, on exactly these two points, states that no guidance is "documented" or "verified" rather than answering them.
Does anything inside ABP depend on the ExtraProperties column being a string-typed column? I am not asking whether overriding it is a supported customisation — you have answered that. I am asking what would actually break, so we can judge the risk ourselves. Specifically: ObjectExtensionManager, the audit log's property change tracking, distributed event serialisation, and the MongoDB provider.
Is provider-native JSON storage for ExtraProperties (SQL Server json, PostgreSQL jsonb) on your roadmap, or has it been considered and rejected? "Not planned" is a perfectly useful answer for us — we need to know whether to design around its absence permanently or treat it as a temporary gap.
Context, if useful: we are not looking for a workaround to push queryable data into ExtraProperties. We have accepted your recommendation and will keep query-critical dynamic attributes in an application-owned json column. Question 1 only matters for the smaller set of extended entities where the values already live in ExtraProperties today.
Versions: ABP 10.6.0 · EF Core 10.0.9 · .NET 10 · SQL Server 2025 (major 17) · EF Core SQL Server provider
Context We are building an application where end users define entity attributes at runtime, per tenant. Attribute values are stored in two places, and we are trying to decide whether to converge on yours:
on ABP-extended entities, the values live in ExtraProperties; on a fully-dynamic entity of our own, they live in a JSON column we control. Both columns are nvarchar(max) in our schema. We have ~445,000 rows on the second one and ~52,000 on the largest extended entity, so query behaviour matters to us in practice, not in theory.
What we observe today On ExtraProperties we cannot filter server-side at all. Because the bag goes through the ExtraProperties value converter, no predicate over its contents is translatable, so our repository materialises the candidate rows and matches the key in memory:
// ExtraProperties cannot be filtered in SQL through its value-converter, // so match the key client-side. var matched = (await query.ToListAsync()) .Where(e => MatchesNavigationValue(e, navigationKey, wanted)); Free-text search on the same entities does reach SQL, but only because it targets a native column (a LIKE on the label field), not the extra properties.
We are aware of ObjectExtensionManager.MapEfCoreProperty and of the documented limitation at https://abp.io/docs/en/abp/latest/Customizing-Application-Modules-Extending-Entities. Our difficulty is that MapEfCoreProperty is a design-time, per-property mechanism: we cannot enumerate the properties in a migration, because the users create them after deployment.
What we measured, on our own column To understand what the ceiling looks like, we converted our own JSON column from nvarchar(max) to the SQL Server 2025 native json type and added one CREATE JSON INDEX. Measured through EF Core over 445,008 rows, ten iterations after a warm-up:
Filter LIKE on nvarchar(max) JSON_VALUE on native json + JSON index selective attribute 567.60 ms 1.00 ms (8 logical reads vs 47,453) attribute present on most rows 565.20 ms 92 ms (index correctly not used; plain scan) attribute created after the index was built 550.30 ms 1.50 ms, no index maintenance A single JSON index serves any path, including keys that did not exist when it was created — which is exactly what a runtime-defined attribute model needs. EF Core 10 maps the native type via HasColumnType("json") and translates JSON_VALUE through HasDbFunction(...).HasName("JSON_VALUE").IsBuiltIn().
None of this is reachable for ExtraProperties, because the value converter maps the bag to nvarchar(max).
Questions Is there any supported way to filter on ExtraProperties contents server-side today, other than promoting a property with MapEfCoreProperty? We searched and found none; we would like your confirmation before we design around the assumption.
Can the ExtraProperties column be mapped to a provider-native JSON type — json on SQL Server 2025, jsonb on PostgreSQL — instead of nvarchar(max)? Is there a supported extension point to change the store type per entity or per DbContext, and is native JSON mapping on your roadmap?
If we override the mapping ourselves (our own converter plus b.Property(x => x.ExtraProperties).HasColumnType("json")), would that be supported? Specifically: does anything in ABP rely on the column being nvarchar — ObjectExtensionManager, auditing, distributed events, the MongoDB provider — and would such an override be likely to survive framework upgrades?
Is there any intended path for extra properties whose names are known only at runtime? MapEfCoreProperty covers the design-time case well. If the runtime case is explicitly out of scope for ExtraProperties, saying so plainly would help us: it is a legitimate answer and we would design accordingly.
What do you recommend for entities that need both ABP's extensibility and real filtering over the dynamic values — ExtraProperties, or an application-owned JSON column? We would rather align with the framework than diverge from it, and right now the measurements point the other way.
Hi ABP Team,
I noticed that ABP Suite currently does not allow creating a property of type Guid.
When defining a new property for an entity, the available primitive types include:
string bool int long decimal double DateTime DateOnly TimeOnly etc.
However, Guid is missing from the list.
This makes it impossible to create a simple Guid property that is not a navigation property.
Steps to reproduce Open ABP Suite. Create or edit an entity. Go to Properties. Click Add Property. Open the Property Type dropdown. Expected behavior
Guid (and optionally Guid? through Nullable) should be available as one of the primitive property types.
Example:
public Guid ExternalId { get; set; }
public Guid? LinkedEntityId { get; set; }
without creating a navigation property or foreign key.
Actual behavior
Guid is not available in the property type list, so the only way to reference another identifier is by creating a Navigation Property, which also generates EF Core relationships and foreign keys.
There are valid scenarios where a Guid is simply an application identifier and not an EF relationship.
Is this an intentional limitation, or could Guid be added as a supported primitive property type in ABP Suite?
In our project we use Guid values to reference external resources or logical associations that are not database foreign keys. Having Guid available as a primitive type would avoid creating unnecessary navigation properties and EF Core relationships.
Hello ABP Team,
I'm using ABP Suite 10.4.1 with an ABP Framework 10.4.1 Blazor Server application.
My project contains multiple localization files for the same resource:
src/Project.Domain.Shared/Localization/Project/ de-DE.json en-GB.json it.json
The resource is configured as follows:
Configure<AbpLocalizationOptions>(options => { options.Resources .Add<ProjectResource>("it") .AddBaseTypes(typeof(AbpValidationResource)) .AddVirtualJson("/Localization/Project");
options.DefaultResourceType = typeof(ProjectResource);
options.Languages.Add(new LanguageInfo("it", "it", "Italian"));
options.Languages.Add(new LanguageInfo("en-GB", "en-GB", "English (UK)"));
options.Languages.Add(new LanguageInfo("de-DE", "de-DE", "German (Germany)"));
}); Steps to reproduce Create a new entity using ABP Suite. Generate the CRUD. Inspect the localization files. Actual behavior
ABP Suite generates the new localization keys only inside de-DE.json.
For example:
"HybridRegions": "Hybrid Regions", "NewHybridRegion": "New Hybrid Region", "Permission:HybridRegions": "Hybrid Regions", ...
No corresponding keys are generated in:
it.json en-GB.json
As a result, developers must manually copy and translate every new localization entry.
Expected behavior
One of the following behaviors would be expected:
Generate the new keys in all localization JSON files belonging to the resource. Or provide an option to select which language file(s) should be updated. Or document that Suite intentionally updates only one localization file.
Currently, only a single language file is modified, which seems inconsistent for projects using multiple supported cultures.
Additional information ABP Framework: 10.4.1 ABP Suite: 10.4.1 UI: Blazor Server Resource contains: it.json en-GB.json de-DE.json
Is this the intended behavior, or could this be a bug in ABP Suite?
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.
Thank you.
I have already performed these steps.
Environment:
ABP Studio Team Edition 10.4.1 Volo.Abp.Studio.Cli 3.0.4 Claude Code 2.1.169 MCP Inspector 0.22.0 Windows 11
I have already:
Updated Volo.Abp.Studio.Cli to 3.0.4.
Restarted ABP Studio.
Loaded the solution.
Verified that the AI Agent works correctly.
Tested both:
abp mcp-studio
and
abp mcp-studio --endpoint http://localhost:38271/mcp/
Reproduced the same problem with MCP Inspector, not only with Claude Code.
The bridge process stays alive, but the MCP handshake never completes.
MCP Inspector reports:
ZodError Invalid input: expected string/number, received null Unrecognized key: "error"
Therefore this does not appear to be a client-side issue.
Could you please escalate this to the ABP Studio team?
I can provide the complete MCP Inspector logs if necessary.
ABP Framework: 10.4.1 ABP Studio Team Edition: 10.4.1 Volo.Abp.Studio.Cli: 3.0.4 Claude Code: 2.1.169 MCP Inspector: 0.22.0 Windows 11
ABP AI Agent inside ABP Studio works correctly.
However, the MCP bridge exposed by:
abp mcp-studio
cannot be consumed by either Claude Code or MCP Inspector.
The process stays alive but the MCP handshake does not complete.
Claude Code reports:
MCP server "abp-studio" connection timed out after 30000ms
MCP Inspector reports:
ZodError Invalid input: expected string/number, received null Unrecognized key: "error"
ABP Studio is running and the solution is loaded.
The endpoint:
http://localhost:38271/mcp/
is reachable and responds (HTTP/2 only endpoint).
The AI Agent inside ABP Studio is fully functional and can access the project context.
Reproduction.
abp mcp-studio
or
abp mcp-studio --endpoint http://localhost:38271/mcp/
Expected: MCP clients should connect and list available tools.
Actual: Claude Code times out and MCP Inspector throws ZodError exceptions.
-- Additional information. The bridge process remains alive.
Running:
C:\Users<user>.dotnet\tools\abp.exe mcp-studio
blocks as expected.
The same issue occurs with and without the --endpoint parameter.
Both Claude Code and MCP Inspector fail, therefore the issue appears to be in the MCP bridge implementation rather than the client.
