Activities of "maliming"

I'll also upgrade the samples to version 10.5.0 soon.

Thanks.

hi

The LeptonXLite theme source code packages have been published.

https://www.nuget.org/packages/Volo.Abp.LeptonXLiteTheme.SourceCode

Thanks.

Hi,

Got your project, fixed it, and it builds and runs now (all the CRM pages work). I've emailed the fixed solution back to you.

The sample itself isn't outdated - it targets ABP 10.0.1 and builds fine on that version. The errors came from upgrading it to 10.5.0, which needs a few changes beyond bumping the package versions:

1. Blazor UI migration to Blazorise 2.0. ABP 10.5 uses Blazorise 2.x, which renamed the input components and changed some APIs (TextEdit -> TextInput, @bind-Text -> @bind-Value, DataGrid context -> context.Item, Centered moves from ModalContent to Modal, etc.). The generated CRUD pages were written for Blazorise 1.x, so they need updating. Full guide here: https://abp.io/docs/latest/release-info/migration-guides/blazorise-2-0-migration

2. Some extra packages (Serilog.AspNetCore, Scriban, SQLitePCLRaw.lib.e_sqlite3, Microsoft.OpenApi, AutoMapper) had been added to every project, including the Blazor WebAssembly client. Serilog.AspNetCore pulls in the ASP.NET Core framework reference, which isn't valid for a WASM client and breaks its build. I removed them from the projects that don't need them (they're already transitive dependencies where they're actually used).

3. Add an EF Core migration for the 10.5 schema changes (new columns like LastSignInTime on AbpUsers), otherwise the database seeding fails on first run.

One more thing I changed so the list pages load: the filter DTOs (GetProductsInput, GetOrdersInput, etc.) had non-nullable string properties. With nullable reference types enabled, those are treated as implicitly required, so the list requests failed validation. I made the filter fields nullable (string?), since a filter is optional by nature.

The zip has the build output stripped (no bin/obj/node_modules), so just restore, build and run it - it creates and seeds the database on first run. Default login is admin / 123456.

If you just want to evaluate the sample, running it on 10.0.1 as downloaded is the simplest path. If you want to stay on 10.5, use the fixed project I emailed you.

Thanks

hi

Can you share the project with liming.ma@volosoft.com?

I will check and fix it.

Thanks.

hi

We will fix the Lite theme as well.

Thanks.

hi

Can you try to remove packageSourceMapping from the NuGet.Config file and run dotnet build again?

Thanks.,

Hi,

This is almost certainly a NuGet source issue, not an outdated sample. The Pro packages (Volo.Saas.*, Volo.Abp.*.Pro.*, Volo.Abp.LeptonXTheme.*) come only from your private ABP feed (nuget.abp.io), not from nuget.org. When you download Easy CRM, that feed is added automatically into the solution's NuGet.Config with your API key.

Could you check two things so we can pinpoint it:

1. Open aspnet-core/NuGet.Config (it sits next to Volo.EasyCrm.sln) and confirm there's a line like:

<add key="ABP Commercial NuGet Source" value="https://nuget.abp.io/<a-guid>/v3/index.json" />

If that line is there, your private feed is already configured for this solution.

2. Build from the command line, from the aspnet-core folder:

cd aspnet-core
dotnet build

If the CLI build works but Visual Studio still shows the errors, then it's Visual Studio not picking up the solution's NuGet.Config (a VS-side issue), not a problem with the sample. Let us know how these two go and we'll take it from there.

Thanks

Hi,

Yes — that change lives in code Suite regenerates. When you run generation again for this entity (e.g. to add another property), Suite rewrites the entity's relationship configuration in the DbContext, so your NoAction gets reverted to SetNull. Suite's "customizable code" only preserves specific custom-code regions in the generated classes (like the entity/service constructors); it doesn't cover the DbContext relationship mapping.

Your database foreign key won't disappear when Suite regenerates the code, because regeneration doesn't change the database schema. But if you add a migration after the mapping has been reverted to SetNull, that migration will try to change the foreign key back to SetNull, and applying it on SQL Server will fail with error 1785.

So the practical approach: after re-generating this entity, re-apply the NoAction line before you add the migration. If the project is under source control, the revert shows up clearly in the diff, so it's a quick thing to restore each time.

We'll also review this behavior in Suite so self-referencing relationships can use a SQL Server-compatible delete behavior by default.

Thanks

Hi,

ABP Suite can scaffold a self-referencing relationship, but on SQL Server this flow needs a small workaround. Two things are happening in your case.

First, the property name. Attribute A+ isn't a valid C# identifier (a space and + aren't allowed), so the generated code doesn't compile and generation fails before anything reaches the database. Give the navigation property a valid, unique name instead — Suite won't allow two properties with the same name, so use something like ParentId.

So: add a navigation property, select A itself as the target entity, set the property name to ParentId, pick a display property, and leave it optional if a root row can have no parent.

Second, the delete behavior (SQL Server only). Suite generates the self-reference with DeleteBehavior.SetNull, and SQL Server rejects SET NULL (and CASCADE) on a self-referencing foreign key — Update Database fails with error 1785 ("may cause cycles or multiple cascade paths"). So on SQL Server:

1. Generate the backend with the valid name (leave "Update Database" unchecked for now).
2. Find that relationship in the generated DbContext and change SetNull to NoAction:

builder.Entity<A>(b =>
{
    b.HasOne<A>().WithMany().HasForeignKey(x => x.ParentId)
     .OnDelete(DeleteBehavior.NoAction);
});

3. Add the migration and update the database with the EF CLI. If Suite already left a migration that failed, remove it first:

dotnet ef migrations remove
dotnet ef migrations add Added_A
dotnet ef database update

Don't re-run Suite generation after this edit, or it will overwrite the DbContext back to SetNull.

One thing to keep in mind with NoAction: the database won't auto-null or auto-delete child rows, so before deleting a parent you'll need to reassign or remove its children first, otherwise the delete is rejected.

To confirm this matches your setup, could you share:

• Your database provider, and both the ABP and ABP Suite/CLI versions.
• The full generation/build log (not just the popup message).
• The generated builder.Entity<A>(...) block, and — if a migration was created — its AddForeignKey / onDelete line.

Thanks

Hi,

This isn't related to your license or a broken install. ABP Studio pins the ABP version inside its solution templates, and the 3.0.6 build ships with 10.4.1 baked in. So any solution created with Studio 3.0.6 comes out as 10.4.1 no matter how many times you reinstall, and clearing caches won't change it either.

Since your ABP Suite is already on 10.5.0, the easiest way for now is to create the solution from Suite (it generates the solution with its own version, so you'll get 10.5.0) and then open that solution in ABP Studio.

We've already updated the templates to 10.5.0, and it will ship with the next ABP Studio release, so creating directly in Studio will default to 10.5.0 once you update.

Thanks