mirror of https://github.com/abpframework/abp.git
Browse Source
Document the upgrade path from ABP 10.5 to 10.6, including background job infrastructure changes, upload/proxy generation updates, Angular 22 adoption, antiforgery and authentication behavior fixes, and dependency version bumps. Also add the new guide to the migration guide index.pull/25771/head
2 changed files with 273 additions and 0 deletions
@ -0,0 +1,272 @@ |
|||
```json |
|||
//[doc-seo] |
|||
{ |
|||
"Description": "Upgrade your ABP solutions from v10.5 to v10.6 with this migration guide covering important behavior and integration changes." |
|||
} |
|||
``` |
|||
|
|||
# ABP Version 10.6 Migration Guide |
|||
|
|||
This document is a guide for upgrading ABP v10.5 solutions to ABP v10.6. One item in this release is labeled as a breaking change. The new background job features are opt-in and default runtime behavior is unchanged, but the background jobs infrastructure extends public contracts and database models for optional scenarios. |
|||
|
|||
> **Package Version Changes:** Before upgrading, review the [Package Version Changes](../../package-version-changes.md) document to see version changes on dependent NuGet and NPM packages and align your project with ABP's internal package versions. |
|||
|
|||
## Open-Source (Framework) |
|||
|
|||
This version contains the following changes on the open-source side: |
|||
|
|||
### Background Jobs Infrastructure Extensions |
|||
|
|||
**Who is affected** |
|||
|
|||
- Applications using the default background job worker and wanting dedicated workers, parallel execution, or successful job retention. |
|||
- Applications with a custom `IBackgroundJobStore` implementation. |
|||
- Applications using the Background Jobs module with EF Core and enabling successful job retention. |
|||
|
|||
**What changed** |
|||
|
|||
- ABP adds opt-in support for: |
|||
- storing successfully completed jobs (`StoreSuccessfulJobs`) |
|||
- dedicated workers per job argument type (`AddDedicatedWorker(...)`) |
|||
- parallel job execution (`MaxParallelJobExecutionCount`) |
|||
- `IBackgroundJobStore`, `IBackgroundJobWorker`, and related infrastructure gained new members. |
|||
- EF Core stores add a `CompletionTime` column to background job records for retention scenarios. |
|||
- All new runtime features are disabled by default. |
|||
|
|||
**What to do** |
|||
|
|||
No action is required if you do not enable the new options and do not maintain a custom background job store. |
|||
|
|||
If you maintain a custom `IBackgroundJobStore`, implement the new interface members so your solution compiles. |
|||
|
|||
If you enable `StoreSuccessfulJobs`, add/review the EF Core migration for the `CompletionTime` column and configure retention options explicitly: |
|||
|
|||
```csharp |
|||
Configure<AbpBackgroundJobWorkerOptions>(options => |
|||
{ |
|||
options.StoreSuccessfulJobs = true; |
|||
options.SuccessfulJobRetentionTime = TimeSpan.FromDays(7); |
|||
}); |
|||
``` |
|||
|
|||
If you enable dedicated workers or parallel execution, configure the options consistently across all application instances and use a real distributed lock provider in clustered deployments. |
|||
|
|||
> See the [Background Jobs](../../framework/infrastructure/background-jobs/index.md) document and [#25742](https://github.com/abpframework/abp/pull/25742) for details. |
|||
|
|||
### API Definition and Proxy Generation for Uploads and Content Types |
|||
|
|||
**Who is affected** |
|||
|
|||
- Applications using generated Angular, jQuery, or C# proxies for upload endpoints. |
|||
- Applications returning non-JSON response types from application services. |
|||
- Applications that customized generated upload proxy signatures. |
|||
|
|||
**What changed** |
|||
|
|||
- API definition now exposes response `ContentTypes` and `IsRemoteStream`. |
|||
- Generated Angular and jQuery proxies forward upload DTOs containing `IRemoteStreamContent` as multipart `FormData`. |
|||
- Generated Angular upload method signatures may collapse the upload argument to `FormData`. |
|||
- `RestService` now unwraps ABP error envelopes more consistently for text and blob response modes. |
|||
|
|||
**What to do** |
|||
|
|||
- Keep upload DTO types in `FormBodyBindingIgnoredTypes` as before. |
|||
- Regenerate client proxies after upgrading. |
|||
- Update custom client code that assumed upload proxies accepted the original DTO type instead of `FormData`. |
|||
- Re-test file upload flows in Angular, MVC/jQuery, and C# client integrations. |
|||
|
|||
> See [#25639](https://github.com/abpframework/abp/pull/25639) for details. |
|||
|
|||
### Angular 22 Upgrade |
|||
|
|||
**Who is affected** |
|||
|
|||
- Applications using the ABP Angular UI. |
|||
- Applications with custom Angular code, third-party Angular libraries, or CI pipelines pinned to Angular 21. |
|||
|
|||
**What changed** |
|||
|
|||
- ABP Angular packages and templates now target **Angular 22.0.x**. |
|||
- Locale loading was improved with a fallback mechanism for missing or partial locale resources. |
|||
|
|||
**What to do** |
|||
|
|||
- Upgrade your Angular application dependencies together with ABP NPM packages. |
|||
- Follow the official Angular update guidance for your current Angular version. |
|||
- Re-run UI tests and rebuild custom Angular libraries after the upgrade. |
|||
- Regenerate Angular proxies after upgrading backend packages. |
|||
|
|||
> See [#25690](https://github.com/abpframework/abp/pull/25690) and [#25734](https://github.com/abpframework/abp/pull/25734) for details. |
|||
|
|||
### Antiforgery User Id Claim Issuer Normalization |
|||
|
|||
**Who is affected** |
|||
|
|||
- Applications that serve a token-authenticated SPA and cookie-authenticated MVC/Razor Pages on the same origin. |
|||
- Applications using Razor Pages modules such as Setting Management with antiforgery-protected POST handlers. |
|||
|
|||
**What changed** |
|||
|
|||
- ABP normalizes the user id claim issuer while generating and validating antiforgery tokens. |
|||
- Razor Pages now use ABP's antiforgery validation path instead of only the built-in ASP.NET Core filter. |
|||
- The behavior is enabled by default through `AbpAntiForgeryOptions.NormalizeUserIdClaimIssuer`. |
|||
|
|||
**What to do** |
|||
|
|||
- Re-test SPA + MVC mixed authentication flows, especially pages that POST immediately on load. |
|||
- If you implemented custom antiforgery logic that depends on the raw claim issuer, review it after upgrading. |
|||
- Disable the behavior only if you intentionally rely on the previous issuer-specific antiforgery identity: |
|||
|
|||
```csharp |
|||
Configure<AbpAntiForgeryOptions>(options => |
|||
{ |
|||
options.NormalizeUserIdClaimIssuer = false; |
|||
}); |
|||
``` |
|||
|
|||
> See [#25655](https://github.com/abpframework/abp/pull/25655) and [#25669](https://github.com/abpframework/abp/pull/25669) for details. |
|||
|
|||
### OpenIddict Interactive Cookie `client_id` Fix |
|||
|
|||
**Who is affected** |
|||
|
|||
- Applications using OpenIddict authorization-code flows together with interactive cookie authentication. |
|||
- Applications relying on audit logs or current-client resolution from cookie-authenticated requests. |
|||
|
|||
**What changed** |
|||
|
|||
- ABP removes `client_id` from the interactive authentication cookie when the cookie principal is refreshed. |
|||
- Access tokens are unaffected. |
|||
- Cookies that were already corrupted self-heal on the next refresh. |
|||
|
|||
**What to do** |
|||
|
|||
No action is required. Re-test authorization, account, and audit-log scenarios if you previously observed intermittent incorrect `ClientId` values in cookie-authenticated requests. |
|||
|
|||
> See [#25711](https://github.com/abpframework/abp/pull/25711) for details. |
|||
|
|||
### Access Token Forwarding for Authenticated Client Requests |
|||
|
|||
**Who is affected** |
|||
|
|||
- Applications using `HttpContextAbpAccessTokenProvider`. |
|||
- Machine-to-machine integrations that authenticate with `client_credentials` and then call other protected APIs from the same request pipeline. |
|||
|
|||
**What changed** |
|||
|
|||
- The provider now forwards the incoming access token whenever the request is authenticated, not only when there is an interactive user. |
|||
- `client_credentials` requests no longer fall back to configured identity clients in that scenario. |
|||
|
|||
**What to do** |
|||
|
|||
- Re-test service-to-service calls that rely on the current HTTP context access token. |
|||
- Verify downstream API authorization when the caller authenticates as a client rather than a user. |
|||
|
|||
> See [#25740](https://github.com/abpframework/abp/pull/25740) for details. |
|||
|
|||
### Thread Current Principal Accessor Behavior |
|||
|
|||
**Who is affected** |
|||
|
|||
- Background jobs, hosted services, and other non-web code that reads `ICurrentPrincipalAccessor.Principal`. |
|||
- Code that explicitly checks for `null` principals in non-web contexts. |
|||
|
|||
**What changed** |
|||
|
|||
- `ThreadCurrentPrincipalAccessor` now returns an anonymous `ClaimsPrincipal` instead of `null` when `Thread.CurrentPrincipal` is not set. |
|||
|
|||
**What to do** |
|||
|
|||
- Re-test background jobs and hosted services that branch on `Principal == null`. |
|||
- Prefer checking authentication/identity state through claims or ABP's current user/client abstractions instead of relying on a `null` principal. |
|||
|
|||
> See [#25752](https://github.com/abpframework/abp/pull/25752) for details. |
|||
|
|||
### Dependency Updates |
|||
|
|||
**Who is affected** |
|||
|
|||
- Applications that pin ABP transitive dependencies directly. |
|||
- Applications using `Microsoft.Data.SqlClient`, Swashbuckle, or Angular with fixed versions. |
|||
|
|||
**What changed** |
|||
|
|||
- `Microsoft.*` and `System.*` packages were upgraded to **10.0.9**. |
|||
- `Microsoft.Data.SqlClient` was upgraded to **7.0.2**. |
|||
- `Swashbuckle.AspNetCore` was upgraded to **10.2.3**. |
|||
- ABP Angular packages were upgraded to **Angular 22.0.x**. |
|||
|
|||
**What to do** |
|||
|
|||
- Review your direct package references and align them with ABP's package versions where needed. |
|||
- Rebuild and run database/integration tests if you directly use `Microsoft.Data.SqlClient`. |
|||
- Re-test Swagger/OpenAPI integration if you customized Swashbuckle configuration. |
|||
|
|||
## Pro |
|||
|
|||
There are no explicitly marked breaking changes on the PRO side in this release scope. However, check the following if they apply to your application. |
|||
|
|||
### OpenIddict Generate Access Token UI |
|||
|
|||
**Who is affected** |
|||
|
|||
- Applications using OpenIddict application management UIs in ABP Commercial. |
|||
|
|||
**What changed** |
|||
|
|||
- Administrators can generate access tokens for OpenIddict applications from MVC, Blazor, MudBlazor, and Angular UIs. |
|||
- The backend forwards `client_credentials` requests to `/connect/token`. |
|||
|
|||
**What to do** |
|||
|
|||
- Re-test OpenIddict application administration pages after upgrading. |
|||
- Review who can access the new token-generation action in your authorization setup. |
|||
|
|||
### Low-Code Runtime History |
|||
|
|||
**Who is affected** |
|||
|
|||
- Applications using the LowCode module and Admin Console designer. |
|||
- Teams relying on writable low-code layers and designer undo/redo workflows. |
|||
|
|||
**What changed** |
|||
|
|||
- The designer adds runtime model history with undo/redo, save points, compare, revert, and selective apply flows. |
|||
- History starts after deployment; older saves are not reconstructed. |
|||
- MongoDB history persistence is not implemented yet in this release scope. |
|||
|
|||
**What to do** |
|||
|
|||
- Re-test low-code designer save, undo/redo, compare, and revert flows after upgrading. |
|||
- Plan operational expectations for history retention and deployment timing. |
|||
|
|||
### Low-Code Layer Contracts and Designer Policy Enforcement |
|||
|
|||
**Who is affected** |
|||
|
|||
- Applications using inherited low-code layers, page groups, and multi-layer customization. |
|||
|
|||
**What changed** |
|||
|
|||
- Layer override/edit policies are enforced in backend validation and Admin Console designer controls. |
|||
- Disabled or orphaned overrides can be cleaned up and reported through model health snapshots. |
|||
- Broken parent/group/page reference chains are hidden from runtime APIs while remaining visible in designer diagnostics. |
|||
|
|||
**What to do** |
|||
|
|||
- Re-test inherited entity/page/page-group customization flows. |
|||
- Review model health warnings after upgrading and clean up orphaned or disallowed overrides if needed. |
|||
|
|||
### AI Management Indexing Resilience |
|||
|
|||
**Who is affected** |
|||
|
|||
- Applications using the AI Management module with document indexing enabled. |
|||
|
|||
**What changed** |
|||
|
|||
- Indexing is more resilient under memory pressure. |
|||
|
|||
**What to do** |
|||
|
|||
- Re-test document indexing on large datasets or memory-constrained environments after upgrading. |
|||
Loading…
Reference in new issue