Distribution of HttpApi.Client Package Without Commercial Dependencies #10241

3 Answer(s)

• 

  0

  AI-Bot created 14 hours ago

  Support Team ABP Agent

  1. Solution

  • Short answer: Yes, you can ship a pure-OSS HttpApi.Client package (and underlying contracts) by removing all ABP Commercial (Pro) dependencies from Domain.Shared, Application.Contracts and HttpApi.Client, while still using Commercial packages in your server-side layers. However:

    • You must not reference any Pro package from the client-distributed NuGet (no transitive Pro deps).
    • Any features/types that come from Pro packages cannot be exposed in your contracts or client proxies.
    • This is supported from a technical standpoint, but you must ensure your contracts and controllers don’t use types, permissions, features, or APIs defined by Pro modules.

  • Practical steps:

    1. Domain.Shared
       • Remove Pro dependencies like:
         • Volo.Abp.Identity.Pro.Domain.Shared
         • Volo.Abp.OpenIddict.Pro.Domain.Shared
       • Replace with OSS equivalents where needed (e.g., Volo.Abp.Identity.Domain.Shared, Volo.Abp.OpenIddict.Domain.Shared) and refactor constants/enums/options so you don’t rely on Pro-only members.
    2. Application.Contracts
       • Remove Pro contracts like:
         • Volo.Abp.Identity.Pro.Application.Contracts
         • Volo.Abp.OpenIddict.Pro.Application.Contracts
         • Volo.Abp.Account.Pro.*.Application.Contracts
       • Reference only OSS contracts (e.g., Volo.Abp.Identity.Application.Contracts) or eliminate the dependency entirely by defining your own DTOs and interfaces that don’t use Pro types.
       • Ensure no DTO, interface, attribute, permission name, or feature flag from Pro packages remains.
    3. HttpApi.Client
       • Remove all Pro HttpApi.Client packages:
         • Volo.Abp.Identity.Pro.HttpApi.Client
         • Volo.Abp.Account.Pro.*.HttpApi.Client
         • Volo.Abp.OpenIddict.Pro.HttpApi.Client
       • Generate or reference only the client proxies for your own controllers and OSS-based modules.
       • If you previously used dynamic client proxies, you can switch to Static C# API clients to fully control what gets compiled into the client package.
    4. Server-side (Application, Domain, HttpApi, Host)
       • You can continue using Pro packages here.
       • Keep all Pro usage out of the shared contract surface. If a controller action returns or accepts a Pro type, that action will force a Pro dependency into your client. Refactor these endpoints to return your own DTOs or OSS types for the public API.
    5. Packaging for external users
       • Create a separate HttpApi.Client-only NuGet (and optionally a separate Application.Contracts NuGet) that references only nuget.org OSS packages.
       • Ensure nuspec/props do not include any private feeds or Pro package references.
       • Consumers only need nuget.org; they won’t need ABP Commercial feeds or licenses to restore or use your client.

  • Licensing implications:

    • ABP Framework (OSS) is MIT and can be redistributed freely.
    • ABP Commercial (Pro) packages must not be redistributed to third parties (no transitive or direct dependencies in what you publish).
    • If you keep Pro packages only on the server and fully exclude them from your client/contract packages, your distributed packages remain OSS-only and do not require your clients to have an ABP Commercial license.

  • Technical limitations to watch:

    • Transitive leakage: even a single Pro-defined permission name, feature, interface, DTO, or attribute referenced in Application.Contracts will pull in Pro packages or cause compile/runtime mismatches. Replace these with your own abstractions or OSS equivalents.
    • Identity/OpenIddict differences: Pro variants add extra endpoints/features. If your public API relies on those extras, you must either:
      • Project them to your own DTOs and surface only those in contracts, or
      • Provide alternative endpoints that don’t require Pro features.
    • Angular/Blazor/Client tooling: If you generate client proxies automatically, configure generation to target only your public controllers (exclude Pro module endpoints). Static C# client generation helps avoid unwanted dependencies.

  2. Sources

  • No verified source available for this specific query.

  ---

  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

  alper created 13 hours ago

  Support Team Director

  actually you can give them without even removing any dependencies they will not require a license to consume your DLL. but the key point is their ASPNETCORE_ENVIRONMENT must be different from "Development" and their Debugger is not attached. But my recommendation will be creating a new project for your API users apart with no dependencies. Because when you try to give them HttpApi.Client you cannot strip everything from this project. because finally it'll not work. just create a new vanilla pure simple project for them.

  Save Cancel
• 

  0

  AdrianoGNeos created 13 hours ago

  The problem is when my users (without a license) pull the artifacts related to those projects, NuGet tries to download all the dependencies related to them, and whenever there's a dependency on these projects it fails. Is this normal behavior or is there a way to avoid it?

  Save Cancel