abp new-module --modern not generating a frontend project is expected with this approach.Volo.Abp.AdminConsole and hosted under /admin-console/* in layered/single-layer solutions, or as a separate app in microservice solutions)So, for your questions:
forRoot() / forChild() for routes/menu/admin-console/* (or as a separate admin-console app in microservices).Volo.Abp.AdminConsole). The publicly available ABP docs/article above explain that it’s pre-built and upgradeable, but they don’t provide a public “reference React source code for commercial modules” workflow in the provided verified sources.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.passkey is not defined by the open-source abpframework/abp repository (so you won’t find it via GitHub search there). In ABP v10, the Pro Account module’s embedded Pages/Account/Login.js expects a global helper namespace (abp.passkey.serializeCredential) to exist, but in your customized login page bundle that helper script is not being included, so abp.passkey stays undefined and the click handler throws.
With ABP 10.4.x specifically, there is no verified public source (docs or OSS code) that shows where abp.passkey is injected/registered for MVC/Razor Pages when using Volo.Abp.Account.Pro.Public.Web. The only verified related official doc page about passkeys does not mention any required extra JS snippet when overriding the login view, nor does it document abp.passkey:
Practical fix (what you already did) is to ensure the helper exists before Login.js executes. The most robust approach is to add the missing helper to the same script bundle used by the login page (so ordering is guaranteed), e.g. load your shim before /Pages/Account/Login.js:
<abp-script-bundle name="@typeof(Volo.Abp.Account.Public.Web.Pages.Account.LoginModel).FullName">
<abp-script src="/Pages/Account/PasskeyCompatibility.js" />
<abp-script src="/Pages/Account/Login.js" />
</abp-script-bundle>
And in PasskeyCompatibility.js, define abp.passkey.serializeCredential (your shim approach is fine). This avoids relying on any inline script that might exist in the stock Pro page.
abp.passkey to be defined in 10.4.1 Pro.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.
Volo.Abp.LeptonXTheme is not the correct module name to download the LeptonX theme source. For LeptonX, the package you can download the source for is the Pro package:abp get-source Volo.Abp.LeptonXTheme.Pro
(You can also download it via ABP Suite.)
%USERPROFILE%\.abp\templates\abp get-source Volo.Abp.LeptonXTheme.Pro
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.
abp add-module Volo.Payment integration into your solution: the generated/added ProjectDomainSharedModule.cs ends up with using Volo.Payment.Paypal; (lowercase p) while the actual namespace/module is Volo.Payment.PayPal (uppercase P).Volo.Payment.Paypal namespace not foundAbpPaymentPayPalDomainSharedModule not found (because the using fails)Fix
src/Project.Domain.Shared/ProjectDomainSharedModule.csusing Volo.Payment.Paypal;
with:
using Volo.Payment.PayPal;
That should unblock compilation immediately (as you observed).
If you want to avoid editing by hand after re-running module add, check the file right after abp add-module Volo.Payment and correct the casing before building.
(Verified doc page for the module install command is below.)
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.
You’ve already found the correct workaround for ABP 10.1.1 + Angular + LeptonX: ensure the ABP translation provider stays the active one after calling provideThemeLeptonX(withThemeLeptonXOptions(...)), because that call chain ends up registering a translate service/provider that takes precedence and makes LeptonX fall back to its default (English) labels in the settings context menu.
Use this in your app.config.ts (or wherever you define Angular providers), keeping ABP’s translate provider last:
import { provideThemeLeptonX, withThemeLeptonXOptions } from '@volosoft/abp.ng.theme.lepton-x';
// or @abp/ng.theme.lepton-x depending on your package
import { LPX_TRANSLATE_PROVIDER } from '@volosoft/ngx-lepton-x'; // your workaround
export const appConfig = {
providers: [
provideThemeLeptonX(
withThemeLeptonXOptions({
defaultTheme: 'dim',
}),
),
// Ensure LeptonX uses ABP's translation pipeline (fixes settings menu localization)
LPX_TRANSLATE_PROVIDER,
],
};
What to do “on ABP side”: this should be fixed by adjusting provider registration order inside the implementation of withThemeLeptonXOptions() / provideThemeLeptonX() so that it doesn’t override ABP’s translate service (or so it re-exports/aliases ABP’s translation service instead of registering a different default). I can’t verify the exact internal source from the indexed repos available in my tools (no repo code match found for these Angular symbols), so I can’t point to the exact file/line to change.
If you want this officially addressed, please open a support ticket / issue with your minimal reproduction and the provider-order diagnosis; include that the workaround is to re-add LPX_TRANSLATE_PROVIDER after provideThemeLeptonX(...).
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.
uow.CompleteAsync() in ABP does more than “commit”. Even when isTransactional: false, it still runs the Unit Of Work completion pipeline, which includes (among other things) publishing/processing “auto events” (domain/entity change events) inside the same UoW. With ~1,000,000 inserts, any “per-entity” event collection/publication/handler execution can dominate the runtime and look like “hangs for hours”.
The fix is to avoid accumulating 1M changes in a single UoW and avoid/disable auto-event generation/handling for bulk imports.
CompleteAsync(), then start a new UoW.const int batchSize = 10000;
foreach (var batch in data.Chunk(batchSize))
{
using var uow = _unitOfWorkManager.Begin(requiresNew: true, isTransactional: false);
await _installer.InstallBatchAsync(batch);
await uow.CompleteAsync();
}
Disable/avoid auto-event publishing for this import path
CompleteAsync()).The exact way to disable auto-event publishing depends on what you’re using (domain events, entity change events, distributed events, etc.). However, the most robust approach for “1M inserts import” is:
If you keep EF Core inserts: flush periodically
SaveChangesAsync() can reduce memory/event buildup, but it still leaves the final CompleteAsync() pipeline cost. Batching UoWs is usually better.[DisableAuditing] didn’t helpCompleteAsync() can still be slow due to auto-event processing and other UoW completion tasks, even if auditing is disabled and the entities aren’t auditable.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 login fails because ABP CLI tries to open a local browser using gio open / xdg-open, and there is no GUI/browser available.abp login --device
This prints a verification URL and a code in the terminal. Open the URL on your local computer (with a browser), enter the code, complete the sign-in, then return to the terminal session; the CLI will finish login.
If you do want the “open browser automatically” behavior on Linux, install/configure a desktop environment + a browser and ensure xdg-open can find one (your error shows www-browser, links, lynx, etc. are missing). But for servers, --device is the recommended approach.
If you want to verify connectivity from the server, ensure this endpoint is reachable:
curl -I https://account.abp.io/.well-known/openid-configuration
Less obvious 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.
This happens when your embedded JSON localization files are no longer being served by the Virtual File System (VFS) after the upgrade, so the /api/abp/application-localization endpoint can only return the resource metadata (resource name + baseResources), but cannot read your embedded en.json, therefore:
"texts": {} for your resource.In ABP v10, a common cause (especially after upgrades) is that the project that contains your embedded localization JSONs (typically *.Domain.Shared) does not reference Microsoft.Extensions.FileProviders.Embedded anymore (or it wasn’t present). Without it, embedded files may not be discoverable by VFS at runtime in some setups.
Fix: add the embedded file provider package to the project that contains the embedded json files (usually MyApplication.Domain.Shared.csproj):
<ItemGroup>
<PackageReference Include="Microsoft.Extensions.FileProviders.Embedded" Version="*" />
</ItemGroup>
Then rebuild and rerun. After that, /api/abp/application-localization should start returning your "MyApplication": { "texts": { ... } } content again.
You do not need to change your localization configuration (e.g. AddVirtualJson("/Localization/MyApplication")) if it was already correct and unchanged; this is typically a missing runtime dependency needed to read embedded resources.
If you also have module/submodule resources, apply the same fix to each *.Domain.Shared (or whichever assembly embeds the localization jsons).
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 install-libs in Azure DevOps is to avoid the “first run only installs/updates extensions and restarts the CLI” behavior by explicitly running abp check-extensions before abp install-libs, and to ensure the agent has Node.js/npm available on PATH (since install-libs uses the JS package manager under the hood).wwwroot/libs cleanup deterministic (your read-only cleanup approach is fine), or simply wipe the repo folder each build.Use a pipeline structure like this (Windows example), replacing Node version as needed:
steps:
# Ensure Node/npm exist (required by install-libs)
- task: NodeTool@0
displayName: 'Use Node.js'
inputs:
versionSpec: '18.x' # pick a stable LTS for reproducibility
# (Optional but recommended on self-hosted agents) deterministic cleanup
- powershell: |
Get-ChildItem -Path "$(Build.SourcesDirectory)" -Recurse -Directory -Filter 'libs' -ErrorAction SilentlyContinue |
Where-Object { $_.FullName -like '*\wwwroot\libs' } |
ForEach-Object {
Write-Host "Force-cleaning $($_.FullName)"
Get-ChildItem -LiteralPath $_.FullName -Recurse -Force -ErrorAction SilentlyContinue |
ForEach-Object { try { $_.Attributes = 'Normal' } catch {} }
Remove-Item -LiteralPath $_.FullName -Recurse -Force -ErrorAction SilentlyContinue
}
displayName: 'Force-clean wwwroot/libs'
# Make CLI extension state stable BEFORE install-libs
- script: |
abp check-extensions
displayName: 'abp check-extensions'
# Now install libs once (no “run twice” workaround needed)
- script: |
abp install-libs
displayName: 'abp install-libs'
Key points this fixes vs. your current YAML:
abp check-extensions is the supported way to “check/update extensions” up-front, so install-libs can do its real job in the next step.UnauthorizedAccessException when deleting wwwroot/libs.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.
NavItemsService, and their order is determined by each item’s order value. After upgrading, ABP/theme packages may have changed the default order values of built-in items, so the visual order can change even if you didn’t customize anything.You can patch the built-in items and set their order:
// e.g. app.component.ts (constructor) or an app initializer
import { Component, inject } from '@angular/core';
import { NavItemsService } from '@abp/ng.theme.shared';
import { eThemeBasicComponents } from '@abp/ng.theme.basic';
@Component({
selector: 'app-root',
template: '<router-outlet />',
})
export class AppComponent {
private navItems = inject(NavItemsService);
constructor() {
// Desired order:
// abp-languages | abp-current-user | abp-full-screen
this.navItems.patchItem(eThemeBasicComponents.Languages, { order: 1 });
this.navItems.patchItem(eThemeBasicComponents.CurrentUser, { order: 2 });
this.navItems.patchItem(eThemeBasicComponents.FullScreen, { order: 3 });
}
}
That’s the intended way to change ordering without overriding/replacing NavItemsComponent.
Most likely due to changes in the theme package defaults (your upgrade from @abp/ng.theme.shared 8.x to 10.4.x). Those packages can adjust built-in nav item definitions (including order), so it’s not necessarily something you did.
ABP Angular theme packages (and their dependencies like icon sets) are meant to be used in a compatible set with your ABP version. Pinning/downgrading only the theme packages to force older FontAwesome is generally not recommended because it can introduce incompatibilities across ABP Angular packages.
What you can do safely in ABP is:
If you want to fully control markup/icons, the verified approach is component replacement (replace nav-items / toolbar parts), but for just ordering, NavItemsService.patchItem(...order...) is enough.
Links:
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.
