ABP Version 8.0 Migration Guide

This document is a guide for upgrading ABP v7.x solutions to ABP v8.0. There are some changes in this version that may affect your applications, please read it carefully and apply the necessary changes to your application.

ABP upgraded to .NET 8.0, so you need to move your solutions to .NET 8.0 if you want to use the ABP 8.0. You can check the Migrate from ASP.NET Core 7.0 to 8.0 documentation.

Open-Source (Framework)

Upgraded to OpenIddict to 5.0.0

The 5.0 release of OpenIddict is a major release that introduces breaking changes.

See OpenIddict 4.x to 5.x Migration Guide for more information.

Injected the IDistributedEventBus Dependency into the IdentityUserManager

In this version, IDistributedEventBus service has been injected to the IdentityUserManager service, to publish a distributed event when the email or username is changed for a user, this was needed because sometimes there may be scenarios where the old email/username is needed for the synchronization purposes.

Therefore, you might need to update the IdentityUserManager's constructor if you have overridden the class and are using it.

See the issue for more information: https://github.com/abpframework/abp/pull/17990

Updated Method Signatures in the Bundling System

In this version, ABP introduced the CDN support for bundling. During the development, we have made some improvements on the bundling system and changed some method signatures.

See https://github.com/abpframework/abp/issues/17864 for more information.

Replaced IdentityUserLookupAppService with the IIdentityUserIntegrationService

Integration Services are built for module-to-module (or microservice-to-microservice) communication rather than consumed from a UI or a client application as Application Services are intended to do.

In that regard, we are discarding the IIdentityUserLookupAppService in the Identity Module and moving its functionality to the IIdentityUserIntegrationService. Therefore, if you have used that application service directly, use the integration service (IIdentityUserIntegrationService) instead. IIdentityUserLookupAppService will be removed in thes next versions, so you may need to create a similar service in your application.

Notice that integration services have no authorization and are not exposed as HTTP API by default. Also, if you have overridden the IdentityUserLookupAppService and IdentityUserIntegrationService classes in your application, you should update these classes' constructors as follows:

IdentityUserLookupAppService.cs

    public IdentityUserLookupAppService(IIdentityUserIntegrationService identityUserIntegrationService)
    {
        IdentityUserIntegrationService = identityUserIntegrationService;
    }

IdentityUserIntegrationService.cs

    public IdentityUserIntegrationService(
        IUserRoleFinder userRoleFinder,
+       IdentityUserRepositoryExternalUserLookupServiceProvider userLookupServiceProvider)
    {
        UserRoleFinder = userRoleFinder;
+       UserLookupServiceProvider = userLookupServiceProvider;
    }

MongoDB Event Bus Enhancements

In this version, we have made some enhancements in the transactional inbox/outbox pattern implementation and defined two new methods: ConfigureEventInbox and ConfigureEventOutbox for MongoDB Event Box collections.

If you call one of these methods in your DbContext class, then this introduces a breaking-change because if you do it, MongoDB collection names will be changed. Therefore, it should be carefully done since existing (non-processed) event records are not automatically moved to new collection and they will be lost. Existing applications with event records should rename the collection manually while deploying their solutions.

See https://github.com/abpframework/abp/pull/17723 for more information. Also, check the documentation for the related configurations: Distributed Event Bus

Moved the CMS Kit Pages Feature's Routing to a DynamicRouteValueTransformer

In this version, we have made some improvements in the CMS Kit's Pages Feature, such as moving the routing logic to a DynamicRouteValueTransformer and etc...

These enhancements led to some breaking changes as listed below that should be taken care of:

• Page routing has been moved to DynamicRouteValueTransformer. If you use {**slug} pattern in your routing, it might conflict with new CMS Kit routing.

• PageConsts.UrlPrefix has been removed, instead, the default prefix is pages for now. Still /pages/{slug} route works for backward compatibility alongside with /{slug} route.

• Endpoints changed:

  • api/cms-kit-public/pages/{slug} endpoint is changed to api/cms-kit-public/pages/by-slug?slug={slug}. Now multiple level of page URLs can be used and / characters will be transferred as URL Encoded in querysting to the HTTP API.
  • api/cms-kit-public/pages changed to api/cms-kit-public/pages/home

CmsKit Client Proxies are updated. If you don't send a custom request to this endpoint, you don't need to take an action

Added Integration Postfix for Auto Controllers

With this version on, the Integration suffix from controller names while generating auto controllers are not going to be removed, to differ the integration services from application services in the OpenAPI specification:

This should not affect most of the applications since you normally do not depend on the controller names in the client side.

See https://github.com/abpframework/abp/issues/17625 for more information (how to preserve the existing behaviour, etc...).

Revised the reCaptcha Generator for CMS Kit's Comment Feature

In this version, we have made improvements on the CMS Kit's Comment Feature and revised the reCaptcha generation process, and made a performance improvement.

This introduced some breaking changes that you should aware of:

• Lifetime of the SimpleMathsCaptchaGenerator changed from singleton to transient,
• Changed method signatures for SimpleMathsCaptchaGenerator class. (all of its methods are now async)

If you haven't override the comment view component, then you don't need to make any changes, however if you have overriden the component and used the SimpleMathsCaptchaGenerator class, then you should make the required changes as described.

Disabled Logging for HEAD HTTP Methods

HTTP GET requests should not make any change in the database normally and audit log system of ABP doesn't save audit log objects for GET requests by default. You can configure the AbpAuditingOptions and set the IsEnabledForGetRequests to true if you want to record GET requests as described in the documentation.

Prior to this version, only the GET requests were not saved as audit logs. From this version on, also the HEAD requests will not be saved as audit logs, if the IsEnabledForGetRequests explicitly set as true.

You don't need to make any changes related to that, however it's important to know this change.

Obsolete the AbpAspNetCoreIntegratedTestBase Class

In this version, AbpAspNetCoreAsyncIntegratedTestBase class has been set as Obsolete and it's recommended to use AbpWebApplicationFactoryIntegratedTest instead.

Use NoTracking for Readonly Repositories for EF Core

In this version, ABP provides read-only repository interfaces (IReadOnlyRepository<...> or IReadOnlyBasicRepository<...>) to explicitly indicate that your purpose is to query data, but not change it. If so, you can inject these interfaces into your services.

Entity Framework Core read-only repository implementation uses EF Core's No-Tracking feature. That means the entities returned from the repository will not be tracked by the EF Core change tracker, because it is expected that you won't update entities queried from a read-only repository.

This behavior works only if the repository object is injected with one of the read-only repository interfaces (IReadOnlyRepository<...> or IReadOnlyBasicRepository<...>). It won't work if you have injected a standard repository (e.g. IRepository<...>) then casted it to a read-only repository interface.

See the issue for more information: https://github.com/abpframework/abp/pull/17421

Use IAbpDaprClientFactory to Obtain DaprClient

From this version on, instead of injecting the DaprClient directly, using the IAbpDaprClientFactory.CreateAsync method to create DaprClient or HttpClient objects to perform operations on Dapr is recommended.

The documentation is already updated according to this suggestion and can be found at https://docs.abp.io/en/abp/8.0/Dapr/Index. So, if you want to learn more you can check the documentation or see the PR: https://github.com/abpframework/abp/pull/18117.

Use Newer Versions of the SQL Server (SQL Server 14+)

Starting with EF Core 8.0, EF now generates SQL that is more efficient, but is unsupported on SQL Server 2014 and below. Therefore, if your database provider is SQL Server, then ensure that it's newer than SQL Server 2014. Otherwise, you may get errors due to database creation or while seeding initial data.

The error is similar to: Microsoft.Data.SqlClient.SqlException (0x80131904).

Check the Entity Framework Core's Breaking Changes documentation for more info.

Angular UI

Guards

From Angular Documentation;

Class-based Route guards are deprecated in favor of functional guards.

• Angular has been using functional guards since version 14. According to this situation we have moved our guards to functional guards.

We have modified our modules to adaptate functional guards.

- import {AuthGuard, PermissionGuard} from '@abp/ng.core';
+ import {authGuard, permissionGuard} from '@abp/ng.core';

- canActivate: mapToCanActivate([AuthGuard, PermissionGuard])
+ canActivate: [authGuard, permissionGuard]

You can still use class based guards but we recommend it to use functional guards like us :)

Upgraded NuGet Dependencies

You can see the following list of NuGet libraries that have been upgraded with .NET 8.0 upgrade, if you are using one of these packages explicitly, you may consider upgrading them in your solution:

PRO

Please check the Open-Source (Framework) section before reading this section. The listed topics might affect your application and you might need to take care of them.

If you are a paid-license owner and using the ABP's paid version, then please follow the following sections to get informed about the breaking changes and apply the necessary ones:

CMS Kit Pro: Moved Public Components Under the Common Projects

We have revised the project structure of the CMS Kit Pro module and decided to create common projects to share common components between the public and backoffice applications. Therefore, we have moved some components under these common projects and this development led to modification in the namespaces of the CMS Kit Pro components and their associated DTOs.

As a result, the following namespaces and sub-namespaces were changed as in the following and if you have used these components, you should make the related namespace changes in your application:

Volo.CmsKit.Pro.Public.Web.Pages.Public.Shared.Components -> Volo.CmsKit.Pro.Web.Pages.Public.Shared.Components

The client-proxy.js file was also updated as follows:

client-proxies/cms-kit-pro-proxy.js -> client-proxies/cms-kit-pro-common-proxy.js

CMS Kit Pro: Changed Route Convention for Poll Feature

We have made some improvements on the CMS Kit Pro's Poll Feature such as preventing adding more than one poll with the same date range to a widget, or not rendering a widget without any active poll. During the development, we revised the Poll Feature and noticed that the route convention was not following the REST API Route URI Convention and this led us to update the routes.

You can see the following changes and if you are making a request to the following routes, you can change them as stated below:

/api/cms-kit-public/poll/findbywidget -> /api/cms-kit-public/poll/by-available-widget-name

/api/cms-kit-public/poll/findbycode -> /api/cms-kit-public/poll/by-code

/api/cms-kit-public/poll/showresult -> /api/cms-kit-public/poll/result/{id}

Switch Ocelot to YARP for the API Gateway (Microservice Solution Template)

Until this version, ABP was using the Ocelot for the API Gateway, in the Microservice Startup Template. Since the Ocelot library is not actively maintained, we have searched for an alternative and decided to switch from Ocelot to YARP for the API Gateway.

You don't need to make any changes in your solution regarding this migration. However, if you want to migrate your existing microservice application's API Gateway from Ocelot to YARP, then you can read the Migrating to YARP documentation.

Added the AccountAdminApplicationModule & AccountAdminHttpApiModule to Auth Server Project

In this version, the Volo.Abp.Account.Pro.Admin.HttpApi and Volo.Abp.Account.Pro.Admin.HttpApi packages have been added to the AuthServer project in the microservice startup template.

/apps/auth-server/src/MyCompanyName.MyProjectName.AuthServer/MyCompanyName.MyProjectName.AuthServer.csproj:

<ItemGroup>
+    <PackageReference Include="Volo.Abp.Account.Pro.Admin.HttpApi" Version="8.0.*"/>
+    <PackageReference Include="Volo.Abp.Account.Pro.Admin.Application" Version="8.0.*"/>
</ItemGroup>

/apps/auth-server/src/MyCompanyName.MyProjectName.AuthServer/MyProjectNameAuthServerModule.cs:

[DependsOn(
    //other module definitions...
+   typeof(AbpAccountAdminApplicationModule),
+   typeof(AbpAccountAdminHttpApiModule),
)]
public class MyProjectNameAuthServerModule : AbpModule
{
}