Upgrade .NET 9.0 to .NET 10.0 and upgrade my ABP packages from version 9.3.2 to 10.4.0. #10687

2 Answer(s)

• 

  0

  AI-Bot created 4 months ago

  Support Team ABP Agent

  • Recommended migration path (ABP 9.3.2 → 10.4.0)

    1. Upgrade ABP to v10 first (keep your current .NET SDK only if your environment supports building ABP 10; ABP 10 is on .NET 10). Follow the ABP 10.0 migration guide and apply its breaking changes.
    2. After you are green on ABP 10.0.x, move forward incrementally to 10.1 → 10.2 → 10.3 → 10.4, applying each version’s migration guide (especially important for Blazor UI / Blazorise changes in 10.2).
    3. Only after each step builds and runs, regenerate code (Suite CRUD) and fix UI-level breakages.

  • AutoMapper → Mapperly strategy (officially supported)
    ABP v10 switches the default mapper used by ABP modules to Mapperly, while AutoMapper integration still exists for backward compatibility. The safest approach is:

    • Phase A (stabilize quickly): Keep your existing AutoMapper profiles temporarily by ensuring every layer that uses ObjectMapper has AutoMapper correctly registered (especially your Blazor module).
    • Phase B (migrate cleanly): Move mappings to Mapperly using ABP’s documented pattern (AbpMapperlyModule, AddMapperlyObjectMapper, and Mapperly mapper classes derived from MapperBase<,> / TwoWayMapperBase<,>).

    Practical “gotcha” that causes “No object mapping was found…”: if you register a contextual object mapper (e.g. AddAutoMapperObjectMapper<MyBlazorModule>() or AddMapperlyObjectMapper<MyBlazorModule>()), you must also set the ObjectMapperContext where you call ObjectMapper.Map(...) (Blazor pages/components commonly hit this). This is a known real-world fix pattern in ABP support.

  • Navigation properties / WithNavigationProperties DTOs There isn’t a single “one breaking change” bullet in the public sources you provided that explains all navigation/collection-related DTO generator problems. In practice, what you’re describing is commonly a mapping registration + generated DTO shape mismatch problem after switching mapping provider and/or regenerating code. The most deterministic fix path is:

    • Decide one mapping provider per layer (prefer Mapperly in v10+), and ensure it’s registered as the default provider (context.Services.AddMapperlyObjectMapper();) in a root module that is always loaded.
    • For WithNavigationProperties DTOs, add/verify explicit mappings for:
      • EntityWithNavigationProperties ↔ EntityWithNavigationPropertiesDto
      • nested lookup DTOs used by CRUD pages (these are frequently the missing ones after regeneration)

  • ABP Suite / CRUD Page Generator compatibility ABP Suite can generate for v10, but if you migrate an existing v9 solution and then regenerate, you should expect manual adjustments where your project has custom conventions (navigation display properties, custom DTOs, Identity Pro integration patterns, etc.). Treat generator output as a starting point; stabilize compilation after each regeneration step.

  • Recommended upgrade order (minimizes churn)

    1. ABP 10.0 migration guide items first (core framework + mapping provider changes).
    2. Mapping decision:
       • either keep AutoMapper temporarily across all layers, or
       • migrate to Mapperly and ensure AddMapperlyObjectMapper() is called so ObjectMapper.Map uses Mapperly.
    3. UI upgrades next:
       • if you go through ABP 10.2, you must handle Blazorise 2.0 migration changes there (that’s where many component API breaks like parameters/events happen).
    4. Only then re-apply/regenerate CRUD pages and fix remaining compilation issues.

  ---

  Sources (validated):

  • https://abp.io/docs/10.4/release-info/migration-guides/abp-10-0
  • https://abp.io/docs/10.0/release-info/migration-guides/AutoMapper-To-Mapperly
  • https://abp.io/docs/latest/framework/infrastructure/object-to-object-mapping
  • https://abp.io/docs/10.2/release-info/migration-guides/abp-10-2
  • https://abp.io/docs/10.2/release-info/migration-guides/blazorise-2-0-migration
  • https://abp.io/docs/latest/cli

  ---

  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.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created 3 months ago

  Support Team Fullstack Developer

  Hi,

  The recommended way is to upgrade ABP incrementally, one minor version at a time (10.0 → 10.1 → 10.2 → 10.3 → 10.4) and apply each migration guide. Jumping directly from 9.3.2 to 10.4.0 mixes 5 versions of breaking changes and makes root-causing very hard. The migration guides are here:

  • https://abp.io/docs/10.4/release-info/migration-guides/abp-10-0
  • https://abp.io/docs/10.4/release-info/migration-guides/abp-10-1
  • https://abp.io/docs/10.4/release-info/migration-guides/abp-10-2
  • https://abp.io/docs/10.4/release-info/migration-guides/abp-10-3
  • https://abp.io/docs/10.4/release-info/migration-guides/abp-10-4

  Below are answers to each issue you listed.

  1. "No object mapping was found for the specified source and destination types"

  This happens because in v10 your solution loads both AbpAutoMapperModule (your existing code) and AbpMapperlyModule (loaded indirectly by ABP modules that already migrated to Mapperly). Both register IAutoObjectMappingProvider and the last-loaded module wins, so ObjectMapper.Map<TSource, TDestination>(...) ends up looking for a mapper in the wrong provider.

  Fix: pick one provider and register it explicitly in your root module's ConfigureServices:

  // If you keep AutoMapper:
  public override void ConfigureServices(ServiceConfigurationContext context)
  {
      context.Services.AddAutoMapperObjectMapper();
  }
  

  // If you switch to Mapperly:
  public override void ConfigureServices(ServiceConfigurationContext context)
  {
      context.Services.AddMapperlyObjectMapper();
  }
  

  Doc: https://abp.io/docs/10.4/release-info/migration-guides/AutoMapper-To-Mapperly#set-default-mapping-provider

  2. AutoMapper situation in v10 and which path to take

  Volo.Abp.AutoMapper is still shipped and works in v10. The reason this topic comes up so much is that:

  • AutoMapper 14.x (which Volo.Abp.AutoMapper is built on) has a known DoS vulnerability (GHSA-rvv3-g6hj-g44x) and the 14.x line will not get a patch.
  • AutoMapper 15.x is commercial-only.

  ABP gives you three valid options. Pick one and don't mix them across the solution:

  Option A — Keep Volo.Abp.AutoMapper (no commercial license) ABP Framework has applied a code-level mitigation (MaxDepth = 64) to the integration to address the GHSA-rvv3-g6hj-g44x DoS vector. This is the lowest-effort option if your project does not need the patched AutoMapper.

  Option B — Move to Volo.Abp.LuckyPenny.AutoMapper (commercial AutoMapper 15.x) This is a true drop-in replacement and only requires two changes, no namespace updates:

  1. In every *.csproj:

     <PackageReference Include="Volo.Abp.LuckyPenny.AutoMapper" />
     

     (replacing Volo.Abp.AutoMapper)

  2. In every module that previously depended on AbpAutoMapperModule:

     [DependsOn(typeof(AbpLuckyPennyAutoMapperModule))]
     public class MyModule : AbpModule { /* unchanged */ }
     

  All types remain in the Volo.Abp.AutoMapper namespace, so using directives stay the same. Volo.Abp.LuckyPenny.AutoMapper and Volo.Abp.AutoMapper must not be referenced together — choose one or the other.

  LuckyPenny has a free Community License for organizations with annual gross revenue under $5,000,000 USD and that never received more than $10,000,000 USD in outside capital (sign-up page). Otherwise see paid plans.

  License key configuration (do this only on server-side projects, not Blazor WebAssembly / MAUI):

  [DependsOn(typeof(AbpLuckyPennyAutoMapperModule))]
  public class MyModule : AbpModule
  {
      public override void ConfigureServices(ServiceConfigurationContext context)
      {
          var licenseKey = context.Configuration["AutoMapper:LicenseKey"];
  
          Configure<AbpAutoMapperOptions>(options =>
          {
              options.Configurators.Add(ctx =>
              {
                  ctx.MapperConfiguration.LicenseKey = licenseKey;
              });
          });
      }
  }
  

  Doc: https://abp.io/docs/10.4/framework/infrastructure/luckypenny-automapper

  Option C — Migrate to Volo.Abp.Mapperly Mapperly is free and is what ABP modules use internally in v10. Five global search-and-replace steps, then convert each Profile class into a MapperBase<TSource, TDestination> partial class:

  [Mapper(RequiredMappingStrategy = RequiredMappingStrategy.Target)]
  public partial class MyEntityToMyEntityDtoMapper : MapperBase<MyEntity, MyEntityDto>
  {
      public override partial MyEntityDto Map(MyEntity source);
      public override partial void Map(MyEntity source, MyEntityDto destination);
  }
  

  Use TwoWayMapperBase<TSource, TDestination> for ReverseMap(), [MapperIgnoreTarget] for Ignore(...), [MapProperty] for ForMember(...), and override AfterMap for custom logic. Doc: https://abp.io/docs/10.4/release-info/migration-guides/AutoMapper-To-Mapperly

  Whichever option you pick, do this after the version upgrade is stable, not during.

  3. WithNavigationProperties DTOs / LookupDto / "invalid navigation display properties"

  Two things to clarify first:

  • Suite v10 supports both AutoMapper and Mapperly templates. It detects which one to use by scanning the target project for existing files: if *AutoMapperProfile.cs exists it stays on AutoMapper; if *Mappers.cs exists it switches to Mapperly; if both exist, AutoMapper wins. The AutoMapper templates themselves were not significantly changed between v9 and v10, so if you stay on AutoMapper, regenerated code looks essentially the same as in v9.
  • The Mapperly templates emit a different shape per entity (e.g. {Entity}WithNavigationPropertiesTo{Entity}WithNavigationPropertiesDtoMapper, a {NavEntity}ToLookupDto{Type}Mapper per navigation, child-collection helpers, a CombinedAfterMap). These are the files that may collide with hand-edited mappings after a Mapperly switch.

  How to fix the "invalid navigation display properties" compile errors:

  • In Suite, open each entity → for every Navigation Property and Navigation Collection, verify the Display Property field points to a property that still exists on the navigated entity. Suite emits destination.DisplayName = source.{DisplayProperty}; inside AfterMap, so a stale or wrong property name compiles into invalid code. This is the single most common cause of these specific errors after regeneration.
  • Don't keep both *AutoMapperProfile.cs and *Mappers.cs in the same project during the transition. Pick one provider per project and remove the other family of files, otherwise Suite picks AutoMapper but you may also have orphan Mapperly classes pulled in by namespace.
  • For manual / hand-written mappers, use file names that don't match Suite's search patterns (*AutoMapperProfile.cs, *ApplicationMapperlyMappers.cs, *ApplicationMappers.cs, *BlazorMappers.cs, *WebMappers.cs, *Mappers.cs). For example, MyEntityManualMappings.cs is safe — MyEntityMappers.cs is not.

  4. ABP Suite compatibility with migrated v9 → v10 solutions

  Suite v10 works against v10 solutions, but it is not a "v9 → v10 auto-migration" tool. For an upgraded solution:

  • Do not bulk-regenerate existing entities. The output will overwrite your manual edits and may mix v9-era code with v10 templates (especially around Blazor pages and DataGrid usage, which changed because of Blazorise 2.0 — see #6 below).
  • Regenerate only entities that genuinely need updates, one at a time, and diff the result before saving.
  • For new entities, Suite v10 works as expected.

  5. Identity Pro DbContext

  Two cumulative changes since 10.0 that you need to apply, in addition to other small EF migrations triggered by various ABP modules.

  • 10.1: IdentityUserPasswordHistory and IdentityUserPasskey are added under the Identity Pro module. Run Add-Migration and Update-Database after upgrading to 10.1.

  • 10.2: IIdentityProDbContext adds the UserInvitations DbSet. If your DbContext implements IIdentityProDbContext (the standard startup-template setup), add this property to your DbContext class so it satisfies the new interface member and is included in the model:

    public DbSet<UserInvitation> UserInvitations { get; set; }
    

    Then Add-Migration + Update-Database again.

  Docs:

  • https://abp.io/docs/10.4/release-info/migration-guides/abp-10-1
  • https://abp.io/docs/10.4/release-info/migration-guides/abp-10-2

  6. Blazorise breaking changes (these all land in ABP 10.2)

  Width, CurrentPage, bind-* are all part of the Blazorise 2.0 upgrade that ABP 10.2 brings. The complete list (apply all of them) is here: https://abp.io/docs/10.4/release-info/migration-guides/blazorise-2-0-migration

  Highlights:

  • Input renames: TextEdit → TextInput, DateEdit → DateInput, NumericEdit → NumericInput, etc.
  • Binding API unified to Value / ValueChanged:
    • @bind-Text, @bind-Checked, @bind-Date, @bind-SelectedValue → @bind-Value
  • DataGrid:

    • CurrentPage → Page on the native Blazorise DataGrid. Important: ABP's AbpExtensibleDataGrid still exposes CurrentPage — do not rename it there.

    • Column Width changed from string to fluent sizing:

      Width="Width.Px(30)"   // was Width="30px"
      Width="Width.Is50"     // was Width="50%"
      Width="Width.Is100"    // was Width="100%"
      
      // Dynamic string values (e.g. when Width comes from configuration or an entity):
      Width="@BlazoriseFluentSizingParse.Parse(column.Width)"
      

      For non-standard percentages (e.g. 33%) use BlazoriseFluentSizingParse.Parse("33%") — Blazorise's Width static helper does not have a generic Percent(...) method.

    • Inside DisplayTemplate, context.Property → context.Item.Property. The same rule applies to Clicked / Visible / ConfirmationMessage in DataGridEntityActionsColumn and DataGridCommandColumn.

  • Modal: Size and Centered move from <ModalContent> to <Modal>.
  • Dropdown: RightAligned="true" → EndAligned="true".
  • Autocomplete: MinLength → MinSearchLength.
  • Empty placeholder needs an explicit TValue: <SelectItem></SelectItem> → <SelectItem TValue="string"></SelectItem>.

  7. Recommended upgrade order

  1. .NET 9 → .NET 10 first (update <TargetFramework>, global.json, install SDK 10).
  2. ABP 9.3.2 → 10.0, keep your existing mapping setup for now. Apply the 10.0 migration guide and create a new EF Core migration (OpenIddict 7 + InboxProcessor field changes + module entity changes). Get the solution compiling and running before touching anything else.
  3. 10.0 → 10.1: apply 10.1 migration guide, new EF migration for IdentityUserPasswordHistory / IdentityUserPasskey. Also update custom Swagger filters if any (Swashbuckle 10 + Microsoft.OpenApi 2 are not source-compatible).
  4. 10.1 → 10.2: this is the big UI step — apply the Blazorise 2.0 migration to your Blazor pages, add DbSet<UserInvitation> to your DbContext, create a new EF migration.
  5. 10.2 → 10.3: small changes, update PermissionIntegrationController clients if any (now HttpPost).
  6. 10.3 → 10.4: small changes; if you use email/SMS 2FA, re-test (codes are single-use now).
  7. Decide AutoMapper vs LuckyPenny AutoMapper vs Mapperly only after the version upgrade is fully stable.
  8. Regenerate Suite-managed code last, and only for entities that genuinely need it.

  If you use MySQL, please check the 10.0 guide carefully — the EF Core MySQL providers have limited .NET 10 support at the moment.

  Thanks

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel