Activities of "maliming"

hi

The UserInvitation is a new entity, so add it to your DbContext is correct.

We will check your angular issues.

Thanks.

: )

ok.

Hi,

Yes, you can reuse Blazor WebAssembly pages in a MAUI Blazor Hybrid application with ABP. ABP provides a MAUI Blazor application template specifically designed for this purpose.

How reuse works at different levels:

1. ABP built-in module pages (Identity, Settings, Audit Logging, Language Management, OpenIddict, etc.) — These are already shared. Both MAUI Blazor and Blazor WebAssembly reference the same base Blazor UI packages (e.g., Volo.Abp.Identity.Pro.Blazor). The WebAssembly variant just adds a .WebAssembly suffix package for WASM-specific service registration, but the actual Razor pages/components come from the same base package. So you get all the built-in module pages working in MAUI Blazor without any extra work.

2. Template-generated pages (like Index.razor, HostDashboard.razor) — In our current templates, these pages are duplicated between MAUI Blazor and Blazor WebApp Client projects. The markup is almost identical, but there are small differences. For example, the Login button on Index.razor uses <a href="/Account/Login"> in MAUI Blazor vs <a @onclick="Login"> with NavigationManager in WebApp Client. The HostDashboard.razor is essentially the same in both templates.

3. Your custom pages — If you want to share your own custom pages between both apps, you can create a Razor Class Library (RCL) project and reference it from both the MAUI Blazor and Blazor WebAssembly projects. Keep in mind that you may need to handle some platform-specific differences (like navigation and authentication) through abstractions or conditional logic.

4. HttpApi.Client — Both MAUI Blazor and Blazor WebAssembly reference the same HttpApi.Client project, so all your API client proxy code is fully shared.

What requires separate implementation:

• Authentication: MAUI Blazor uses OIDC via Duende.IdentityModel.OidcClient with a platform-specific MauiAuthenticationBrowser (supporting both authorization code flow and password flow). Blazor WebAssembly uses standard ASP.NET Core authentication (AddBlazorWebAppServices()). ABP provides Volo.Abp.Account.Pro.Public.MauiBlazor package that handles MAUI authentication for you.

• Module configuration: MAUI Blazor module (MyProjectNameMauiBlazorModule) has its own setup for Blazorise, routing, bundling, and authentication that differs from the WebAssembly module.

• Navigation menus: Each template has its own MenuContributor. For example, the MAUI Blazor user menu links to external URLs (Account management pages on the auth server) with target: "_blank", while the WebAssembly version uses OperatingSystem.IsBrowser() to differentiate behavior.

• Platform-specific code: MAUI Blazor includes platform handlers for Android, iOS, MacCatalyst, and Windows (e.g., WebAuthenticator callbacks, SSL certificate handling in debug mode).

Getting started:

You can create a new ABP solution with the MAUI Blazor option using ABP Studio. The generated template comes pre-configured with everything needed. Then, to maximize code reuse with your existing Blazor WebAssembly app, extract shared custom components into a Razor Class Library.

Thanks

hi

Can you try to share full /api/abp/application-configuration HTTP request debug logs?

liming.ma@volosoft.com

https://abp.io/support/questions/8622/How-to-enable-Debug-logs-for-troubleshoot-problems

Have you used Redis? If so. Can you disable it and try again?

Thanks.

hi

Is your problem solved?

Thanks.

Get the LeptonXTheme source code.

dotnet tool list -g
Package Id                       Version         Commands         
------------------------------------------------------------------
volo.abp.studio.cli              2.2.4           abp      

abp get-source  Volo.Abp.LeptonXTheme 
[09:46:59 INF] Downloading source code of Volo.Abp.LeptonXTheme (Latest)
[09:46:59 INF] Output folder: /Downloads/test
[09:47:14 INF] Volo.Abp.LeptonXTheme.SourceCode (v: 5.1.1) package downloaded from https://nuget.abp.io/xxx/v3/index.json and saved to (/Users/maliming/.nuget/packages/)
[09:47:15 INF] 'Volo.Abp.LeptonXTheme' has been successfully downloaded to '/Downloads/test'

hi

The MobileNavbar component was moved from the SideMenu namespace to the Common namespace starting from LeptonX 4.3 (ABP 9.3). Since you are upgrading directly from ABP 8 to ABP 10, you hit this breaking change.

To fix the compile error, update the @using directive in your customized Default.cshtml:

Old (ABP 8 / LeptonX 3.x):

@using Volo.Abp.AspNetCore.Mvc.UI.Theme.LeptonX.Themes.LeptonX.Components.SideMenu.MobileNavbar

New (ABP 10 / LeptonX 5.x):

@using Volo.Abp.AspNetCore.Mvc.UI.Theme.LeptonX.Themes.LeptonX.Components.Common.MobileNavbar

The @model MobileNavbarViewModel declaration itself is still valid — only the namespace changed.

Note that the Default.cshtml template also has significant HTML structure changes between LeptonX 3.x and 5.x (the layout of the mobile nav tabs was redesigned), and the MainMenuViewComponent reference was replaced with MobileMainMenuViewComponent. If you are getting layout issues after fixing the compile error, you may need to compare your customized file against the latest LeptonX source and update the HTML structure accordingly.

Thanks

hi

Thanks for the detailed report. Let me address each issue separately.

AutoMapper 13.0.1 (GHSA-rvv3-g6hj-g44x)

The ABP team has applied a code-level mitigation for this vulnerability in PR #25138 by setting MaxDepth = 64 for all AutoMapper maps that don't have an explicit MaxDepth configured. However, this fix is going into the upcoming ABP release and will not be backported to 8.2.3.

Since you're staying on ABP 8.2.3 / .NET 8, you can apply the same mitigation manually in your own project. Additionally, since the AutoMapper maintainer has confirmed no patch will be released for the affected version, your NuGet security audit will continue showing NU1902/NU1903 warnings regardless. To suppress the warning, add the following to your Directory.Build.props (or individual .csproj files):

<ItemGroup>
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-rvv3-g6hj-g44x" />
</ItemGroup>

If you hold a commercial AutoMapper license (LuckyPenny Software), you can override the AutoMapper package to version 15.1.1 in your projects. The ABP team has also released a Volo.Abp.LuckyPenny.AutoMapper integration package (see #25153) as a drop-in replacement for Volo.Abp.AutoMapper for users with such a license — though note this targets newer ABP versions, so you would need to adapt it manually for 8.2.3.

As a long-term solution, we recommend migrating from AutoMapper to Mapperly, which ABP Framework has built-in support for. See the migration guide for details.

Select2 4.0.13

Select2 4.0.13 is actually the latest stable release in the 4.0.x series (released January 28, 2025). The only known vulnerability in Select2 (GHSA-rf66-hmqf-q3fc) was fixed in version 4.0.6 — 4.0.13 is well past that threshold and is not affected. The scanner result is a false positive, and I'd recommend raising it with your security scanning tool vendor.

Additionally, since your UI type is React, Select2 is only present in the MVC-based Auth Server pages, not your main React frontend, so the actual exposure is further limited.

Thanks

Hi,

Thanks for the detailed report. Before suggesting a fix, could you share the output of:

npm list @abp/ng.core

The reason is: the error "No provider found for RestService" is unusual — in newer ABP versions RestService is providedIn: 'root' and should always be resolvable. If you're on an older ABP version (built for Angular 17), the compiled package may not be compatible with Angular 20's DI runtime, which would explain why the provider registration silently fails.

In the meantime, there's one thing in your AppModule that should be fixed regardless:

@NgModule({
  imports: [
    AbpModule,
    BrowserModule,
    BrowserAnimationsModule,
    AppRoutingModule,
    // HttpClientModule,  ← remove this
  ],
})
export class AppModule {}

HttpClientModule (old API) should be removed. ABP's CoreModule.forRoot() already sets up HttpClient internally via provideHttpClient(). Having both at the same time can cause provider conflicts in Angular 20.

However, if the error persists after removing HttpClientModule, the most likely root cause is that your @abp/ng.* packages were compiled for Angular 17 and are not compatible with Angular 20. In that case, upgrading all @abp/ng.* packages to a version that officially supports Angular 20 would be the required fix.

To answer your questions directly:

• No, you don't need to migrate to standalone APIs — NgModule-based architecture is still fully supported.
• No, the AbpModule wrapper pattern is not the problem.

Please share your ABP package version and we can give you more targeted guidance.

Thanks