Inquiry Regarding AutoMapper and Mapperly Usage in ABP 10+ #10414

2 Answer(s)

• 

  0

  AI-Bot created 6 days ago

  Support Team ABP Agent

  • Yes, AutoMapper and Mapperly can coexist in the same ABP 10+ solution. ABP 10 switched ABP modules/templates to use Mapperly by default, but ABP still provides both AutoMapper and Mapperly integration packages, so you can keep existing AutoMapper profiles while using Mapperly elsewhere (or for ABP-provided modules).

  • What “coexistence” practically means in ABP

    • ABP’s mapping abstraction is IObjectMapper / ObjectMapper.Map(...).
    • Under the hood, ABP uses an “auto object mapping provider” (Mapperly or AutoMapper integration) to resolve mappings.
    • You can register Mapperly as the default provider for the application, while still keeping AutoMapper available via module/context-based object mappers (or vice-versa). This enables a phased transition.

  • Recommended best practices / common pitfalls when using both

    1. Be explicit about mapping context when you register a module-specific mapper
       • If you register an object mapper with a context (generic registration), consumers must use the same context.
       • Example pattern (contextual mapper usage):
         • Register in a module:

  context.Services.AddAutoMapperObjectMapper<MyBlazorModule>();
           // or
           context.Services.AddMapperlyObjectMapper<MyBlazorModule>();
  

     - Then set the context where you map (e.g., in an `ApplicationService` / Blazor page base):
  

  ObjectMapperContext = typeof(MyBlazorModule);
  

   - Otherwise, ABP may fall back to the *default* provider and you can get “no mapping found” errors (especially visible in UI layers like Blazor).
  

  2. Avoid ambiguous/duplicate mappings for the same source/destination pair

     • If you define the same mapping pair in both libraries, it becomes unclear which one should be used (depending on which provider/context is active). Prefer a clear rule: “old mappings stay in AutoMapper until migrated” and “new mappings go to Mapperly”.

  3. Decide which one is the default provider for ObjectMapper.Map

     • If you want ABP’s default ObjectMapper.Map<TSource, TDestination> to use Mapperly, ensure your startup/host module registers Mapperly as the default object mapper:

  context.Services.AddMapperlyObjectMapper();
  

   - If you keep AutoMapper as default, you’ll do the analogous AutoMapper default registration instead.
  

  • Framework design intent in ABP 10

    • ABP 10 moved its own modules to Mapperly (primarily due to AutoMapper’s licensing change), but ABP does not force you to remove AutoMapper immediately. Coexistence is explicitly possible because both integrations exist and ABP provides a migration guide.

  • Is coexistence “officially supported long-term” or only transitional?

    • ABP documents that it provides both integrations and offers migration steps. This supports the phased approach as a valid upgrade strategy.
    • From a maintenance standpoint, the long-term direction of the framework/modules is Mapperly, so it’s sensible to plan to gradually standardize on Mapperly when feasible.

  • Migration guidance / strategy for large AutoMapper profile bases (phased approach)

    1. Upgrade to ABP 10 and keep AutoMapper profiles working first (stabilize the upgrade).
    2. Introduce Mapperly for new mappings (don’t add new AutoMapper profiles).
    3. Migrate profile-by-profile using ABP’s migration guide:
       • Convert each AutoMapper profile into one or more Mapperly mappers (MapperBase<>, TwoWayMapperBase<>), then remove the corresponding AutoMapper maps.
    4. Keep mapping usage via ObjectMapper (ABP abstraction) where possible, and only inject concrete Mapperly mappers when you need very specific behavior.

  ---

  Sources (validated)

  • https://abp.io/docs/10.0/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/community/articles/l9f5ii8s

  ---

  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.

  Save Cancel
• 

  0

  maliming created 6 days ago

  Support Team Fullstack Developer

  hi

  We will not upgrade the automapper package version. ABP's module has already been migrated to Mapperly.

  You can continue to use AutoMapper in your module or app.

  ABP Object Mapper is designed to support using a different mapper provider in the module and app.

  More info see: https://abp.io/docs/latest/release-info/migration-guides/AutoMapper-To-Mapperly https://abp.io/docs/latest/framework/infrastructure/object-to-object-mapping#advanced-topics

  Save Cancel