Volo.Abp.AdminConsole NuGet package and hosted under /admin-console/*. Because it’s not part of your React app’s source code, you can’t style it the same way you style your own frontend (e.g., by editing Tailwind config or app-level CSS).Sources (validated):
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.
Yes, a very large number of EF Core migration files can contribute to slower builds and high CPU, because they are compiled as regular C# source files. More files = more work for the C# compiler, analyzers, IDE indexing, and incremental build checks. In ABP solutions this is most visible in the *.EntityFrameworkCore project that contains the Migrations/ folder.
However, it’s not ABP-specific; it’s primarily a “many C# files in one project” + “Roslyn/analyzers/IDE” build-time cost issue. ABP just commonly centralizes migrations in a single project, so the effect is easy to notice as that folder grows.
If you have existing environments already updated by those migrations, deleting or rewriting them will break upgrade paths unless you also manage a “re-baseline” process (below).
This keeps your current schema the same, but replaces “hundreds/thousands of historical migrations” with:
High-level approach (EF Core standard approach, works fine with ABP):
__EFMigrationsHistory contains the baseline migration id, or keep the old history but stop compiling old migrations).This approach is common EF Core practice; ABP does not require “all historical migrations” to remain forever, as long as your deployment process can still upgrade existing databases.
You can move old migrations into a separate project (e.g., MyApp.Migrations.Archive) so day-to-day builds don’t compile them.
EntityFrameworkCore project.This doesn’t affect build CPU, but it’s a best practice for ABP deployments (and avoids other performance problems):
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.
Volo.Abp.Commercial.SuiteTemplates package and you typically customize them one by one from the Template Editing UI.No verified source is available for a “generate/export all templates in one go” capability in ABP Suite.
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.
Could not find a part of the path
C:\SourceCode\XX\test\XX.Domain.Tests\Locations\LocationsDataSeedContributor.cs
Fix (fastest)
*.Domain.Tests data seed contributors, so it won’t try to access that missing folder/file.Fix (keep tests enabled)
test\XX.Domain.Tests\Locations\Why it happens “only when adding LocationId”
LocationsDataSeedContributor.cs). If the test\...Domain.Tests\Locations\ folder (or the XX.Domain.Tests project) isn’t present, you get this “Could not find a part of the path” internal error.Links (verified):
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.
ABP-LIC-0016 means ABP’s license system blocked loading a commercial (Pro) module at runtime.
In your case, after upgrading to 10.5.0, your app now references/loads these Pro modules:
Volo.Abp.Account.Pro.Admin.HttpApiVolo.Abp.TextTemplateManagement.HttpApiFix it by choosing one of these options:
Use a license that includes these modules
Ensure the environment where you run the app has a valid ABP license setup (and that your license tier actually includes Account Pro Admin and Text Template Management). If your company license should include them, proceed with option (3) too.
Remove/stop referencing the modules (if you don’t intend to use them / your license doesn’t include them)
Volo.Abp.* NuGet packages from the solution (both host and any layer that references them).[DependsOn(...)]) so they are not loaded.Re-login with ABP CLI (most common cause after upgrades/new machines/CI): expired or missing CLI token Run this on the machine that builds/runs the solution:
abp login <username> -p <password>
Then clean + rebuild and run again.
This error is a known symptom of an expired ABP CLI token:
If you believe you should have access based on your license but it still fails after abp login, contact ABP support with your license/order details:
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.
Your analysis is correct: the module’s documented cache key format is application-scoped (WorkspaceConfiguration:{ApplicationName}:{WorkspaceName}), so invalidating with a different ApplicationName will not evict what other processes have cached. In a typical tiered/multi-app solution (DbMigrator, HttpApi.Host, Blazor/Mvc UI, etc.), this can easily produce stale workspace configuration until TTL expires.
Immediate workaround (no module source change): make ApplicationName consistent across all processes that must share the same workspace configuration cache entries.
ApplicationName if you control the data), so reads and invalidations converge on the same key space.If you maintain a fork / can patch the module: the safest fix is to ensure read and invalidation paths derive the cache key from the same source (either always the current app name, or always the workspace’s application name, or remove application name from the key if workspace name is globally unique in your design). Without official upstream code available here to reference precisely, I can’t provide a verified patch diff, but the mismatch you pointed out is the root cause.
About AIManagementChatClient<T> lifetime pinning: even with correct distributed cache invalidation, any service that creates and holds an inner client instance for a long time will keep using the old config until it recreates the client. The practical mitigation is to register/consume such clients with a lifetime that matches your desired refresh behavior (e.g., avoid singleton/long-lived reuse if you expect admin edits to apply immediately), or implement a change-token/version check to rebuild the inner client when configuration changes.
(Reference used below is only for the key format; it doesn’t cover the bug itself.)
Sources:
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.
Proceed, but proceed with one rule: treat ABP Suite output as regeneratable scaffolding, and keep your manual EF Core mapping in “custom-owned” files/sections so Suite won’t overwrite it.
What that means in practice:
ParentId).DeleteBehavior.NoAction/Restrict) in a customization location you own (a separate mapping extension method / separate file that you keep under source control).(Links below are verified accessible.)
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.
Yes, you can lose (have overwritten) your manual EF Core mapping changes if ABP Suite re-generates the same area again. Suite’s “Save and generate” can rewrite generated files (including the DbContext / entity mapping blocks it generated), so a manual change like switching OnDelete(DeleteBehavior.SetNull) to NoAction/Restrict may be reverted on the next generation.
However, your database foreign key will not disappear by itself just because Suite generates more code. The DB schema only changes when you add/apply a new migration (or drop/recreate/update DB). The main risk is: future generation overwrites your mapping, and then your next migration may try to alter the FK behavior again (or you may start getting migration/update failures again).
OnModelCreating (or the project’s ConfigureYourProjectName() style extension method), not in a file that Suite repeatedly regenerates for the entity.DeleteBehavior fix after generation (and before creating the next migration).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.
Volo.Saas.*, Volo.Abp.*.Pro.*, Volo.Abp.LeptonXTheme.*). Those packages are not on nuget.org, so if your machine can only restore from nuget.org (or you have an incorrect/blocked ABP commercial feed), you’ll see exactly the errors in your screenshot: NU1101 Unable to find package Volo.Saas.Domain.Shared / Volo.Saas.EntityFrameworkCore / ....Fix (step-by-step)
abp login
Login with the same account that has the commercial license.
Verify NuGet has the ABP commercial source enabled (and reachable)
Ensure the solution’s NuGet.Config is present and used
NuGet.Config (or you should have the ABP commercial source in your global/user NuGet config).dotnet restore
dotnet nuget locals all --clear
dotnet restore
Do not use “offline packages” / custom sources that shadow nuget.org
nuget.org enabled and ensure the ABP commercial feed is enabled/authenticated.If you don’t have an ABP Commercial license, you won’t be able to restore/build Easy CRM (because it depends on commercial modules). In that case, use the free templates/samples instead, or obtain a license.
Links (validated)
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.
+ suffix) are consistent with Suite not handling that scenario well.Assume entity A should optionally reference a parent A:
1) Domain entity (A.cs)
public class A : AggregateRoot<Guid>
{
public Guid? ParentAId { get; set; } // FK column
public A? ParentA { get; set; } // reference nav
public ICollection<A> ChildAs { get; set; } = new List<A>(); // collection nav
}
2) EF Core mapping (in your OnModelCreating / DbContextModelCreatingExtensions)
builder.Entity<A>(b =>
{
b.HasOne(x => x.ParentA)
.WithMany(x => x.ChildAs)
.HasForeignKey(x => x.ParentAId)
.OnDelete(DeleteBehavior.Restrict); // common choice to avoid cascade cycles
});
3) Add migration + update DB Run the standard EF Core migration commands (or use your DbMigrator project) so the column and FK constraint are created.
+ in property names (Attribute A+). That is not a valid C# identifier and will cause persistence/generation issues in tooling. Use a valid identifier such as ParentA, ParentAId, AttributeAPlus, etc.ParentAId and AlternateParentAId), name them explicitly with valid identifiers and map both relationships in EF Core; Suite typically struggles even more with “multiple relationships to the same entity” scenarios.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.
