Issue with Mapperly in Abp version 10 #10626

4 Answer(s)

• 

  0

  AI-Bot created 4 months ago

  Support Team ABP Agent

  • Yes. In ABP 10.x you can continue using AutoMapper in your own application/modules if you purchase/hold a valid AutoMapper commercial license.
  • ABP 10 migrated ABP modules/templates to Mapperly, so modules like Text Template Management use Mapperly internally by default, but ABP still provides both AutoMapper and Mapperly integrations and they can co-exist in the same solution.
  • Practical implications:
    • You can keep your existing AutoMapper Profiles and registrations for your code.
    • ABP module code will still use Mapperly where it was migrated.
    • If you use context-based registration like AddAutoMapperObjectMapper<TModule>(), make sure consumers map with the same ObjectMapperContext to avoid “No object mapping was found…” errors in some layers (e.g., Blazor).

  Links:

  • https://abp.io/docs/10.0/release-info/migration-guides/abp-10-0
  • 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

  ---

  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

  sridhar created 4 months ago

  [AI-Bot] said:

  • Yes. In ABP 10.x you can continue using AutoMapper in your own application/modules if you purchase/hold a valid AutoMapper commercial license.
  • ABP 10 migrated ABP modules/templates to Mapperly, so modules like Text Template Management use Mapperly internally by default, but ABP still provides both AutoMapper and Mapperly integrations and they can co-exist in the same solution.
  • Practical implications:
    • You can keep your existing AutoMapper Profiles and registrations for your code.
    • ABP module code will still use Mapperly where it was migrated.
    • If you use context-based registration like AddAutoMapperObjectMapper<TModule>(), make sure consumers map with the same ObjectMapperContext to avoid “No object mapping was found…” errors in some layers (e.g., Blazor).

  Links:

  • https://abp.io/docs/10.0/release-info/migration-guides/abp-10-0
  • 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

  ---

  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 is for "Text Template Management " assume I'm not going to use Mapperly and will continue with AutoMapper (with license) will I be able to use Text TemplateManagement?

  Markdown supported.

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

  Save Cancel
• 

  0

  AI-Bot created 4 months ago

  Support Team ABP Agent

  • Yes, you can use the Text Template Management module even if you keep using AutoMapper in your own code. In ABP 10, ABP modules (including Text Template Management) were migrated to Mapperly, but that doesn’t prevent your solution from also using AutoMapper for your DTO/entity mappings.
  • What you cannot do in practice is “not use Mapperly at all” in an ABP 10 solution if you want to use ABP modules that were migrated. Those module assemblies are built against ABP’s Mapperly integration and will use it internally. You don’t need to write Mapperly mappers for Text Template Management just to use it—but Mapperly will still be present/used by the module under the hood.

  So the supported setup is:

  1. Keep AutoMapper (licensed) for your own mappings (profiles, CreateMap, etc.).
  2. Let ABP modules use Mapperly internally (Text Template Management, etc.).
  3. Avoid removing Mapperly packages/dependencies from the solution if ABP modules require them.

  If you want your own application layer to keep mapping via AutoMapper, register AutoMapper in your modules as you did in ABP 9; ABP’s object mapping abstraction is designed to allow different mapping providers by module/app.

  (verified)

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

  ---

  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 4 months ago

  Support Team Fullstack Developer

  Hi,

  Yes, you can keep using AutoMapper. Starting from ABP 10.3.0, we shipped a new package Volo.Abp.LuckyPenny.AutoMapper exactly for this case — it's a drop-in replacement built on the commercial AutoMapper (15.x+) by LuckyPenny Software, which is the patched version (the free 14.x has a DoS vulnerability that won't be fixed).

  Migration is just two steps in your own modules:

  // *.csproj
  -<PackageReference Include="Volo.Abp.AutoMapper" />
  +<PackageReference Include="Volo.Abp.LuckyPenny.AutoMapper" />
  

  // YourModule.cs
  -[DependsOn(typeof(AbpAutoMapperModule))]
  +[DependsOn(typeof(AbpLuckyPennyAutoMapperModule))]
  

  All the types stay in the same namespaces (AbpAutoMapperOptions, IMapperAccessor, etc.), so your existing Profiles and CreateMap calls keep working as-is. License key goes through AbpAutoMapperOptions.Configurators:

  Configure<AbpAutoMapperOptions>(options =>
  {
      options.Configurators.Add(ctx =>
      {
          ctx.MapperConfiguration.LicenseKey = "YOUR_LICENSE_KEY";
      });
  });
  

  Note: Volo.Abp.LuckyPenny.AutoMapper and Volo.Abp.AutoMapper are mutually exclusive — pick one.

  About Text Template Management (and other ABP modules migrated to Mapperly): you can use them just fine alongside AutoMapper in your own code. The Mapperly usage is internal to those modules — you don't need to write any Mapperly mappers yourself. The only thing you can't do is fully remove Mapperly from the solution, since the module assemblies are compiled against it. But it's just a transitive dependency, not something you have to interact with.

  So the supported setup is:

  • Your application code → AutoMapper (via Volo.Abp.LuckyPenny.AutoMapper if you hold a commercial license)
  • ABP modules → Mapperly internally
  • Both coexist in the same solution without conflict

  Docs: https://abp.io/docs/latest/framework/infrastructure/luckypenny-automapper

  Thanks

  Markdown supported.

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

  Save Cancel