Reuse the same document management module from host app 1 in another host app 2 #10165

1 Answer(s)

• 

  0

  AI-Bot created 3 days ago

  Support Team ABP Agent

  1. Solution

  • Reuse one Document Management module in multiple hosts
    • Package the module and consume it from both Host 1 and Host 2:
      1. Split the module into the standard ABP layers: MyDoc.Domain.Shared, MyDoc.Domain, MyDoc.Application.Contracts, MyDoc.Application, MyDoc.HttpApi, MyDoc.HttpApi.Client, MyDoc.EntityFrameworkCore (and optional UI layer).
      2. Publish each layer as a NuGet package (internal feed or private NuGet) and reference them from both hosts.
      3. In each host, add [DependsOn] to include the module in the host’s module classes (Web/HttpApi.Host, Application, Domain, EF Core).

  [DependsOn(
             typeof(MyDocApplicationModule),
             typeof(MyDocHttpApiModule),
             typeof(MyDocEntityFrameworkCoreModule)
         )]
         public class HostAppHttpApiHostModule : AbpModule
         {
         }
  

  4) Add the module’s EF Core Configure call into each host’s migrations DbContext (or migrations project) so the host’s DbMigrator migrates the module tables:
  

  protected override void OnModelCreating(ModelBuilder builder)
         {
             base.OnModelCreating(builder);
             builder.ConfigureMyDoc(); // your module's extension method
         }
  

  5) Run each host’s DbMigrator to create/update databases.
  

  • This is the recommended way to reuse functionality across multiple ABP applications (module as a package rather than project reference), keeping hosts loosely coupled.

  • Generating Angular proxies without ABP Suite entities

    • ABP Angular proxies are generated from your backend’s OpenAPI/Swagger, not from Suite entities. As long as your module exposes HTTP APIs (e.g., via Conventional Controllers in MyDoc.HttpApi), you can generate Angular proxies:
      1. Ensure the host that exposes the module APIs runs and serves Swagger (e.g., https://localhost:44300/swagger/v1/swagger.json).
      2. In your Angular app, configure the proxy generator to point to the service’s Swagger:
         • Using ABP CLI:
           • Run: abp generate-proxy -t angular -u https://localhost:44300 -m YourAngularProjectRoot
         • Or configure angular.json/ng-proxy to point to the remote; ABP Angular package will pull the OpenAPI and generate TypeScript clients.
      3. If you package and distribute MyDoc.HttpApi.Client as a NuGet and also publish an NPM package for the Angular UI of your module, you can reuse even more easily; however, it is not mandatory. The key is your module must publish HTTP APIs; proxies are generated from those APIs’ Swagger definition, regardless of ABP Suite usage.

  • Database segregation approaches when reusing the same module in two hosts

    • Option A: One database per host
      • Each host has its own connection string(s). Both include the module and run their own migrations. Tables for the module will exist in each host’s DB (fully isolated).
    • Option B: Shared database across hosts (same connection string)
      • Both hosts include the module, but only one host (or a dedicated migrator) should be responsible for running migrations to avoid conflicts. Both apps work on the same module tables.
    • Option C: Multiple DbContexts or multiple DBMS per host (advanced)
      • If you want the module to use a dedicated database different from the host’s main DB, define a specific DbContext in the module and mark it with [ConnectionStringName("MyDoc")]. In the host appsettings.json, provide "ConnectionStrings:MyDoc". In the module’s EF Core module, configure provider per DbContext:

  Configure<AbpDbContextOptions>(options =>
        {
            options.Configure<MyDocDbContext>(opt => { opt.UseSqlServer(); /* or UseMySQL etc. */ });
        });
  

  - This allows Host 1 and Host 2 to point the module to different databases or even different DBMS per host while sharing the same binary module. See also the note below for multiple providers per solution.
  

  • Deployment separation

    • If you choose separate DBs per host, deploy DbMigrator (or EF tooling) per host environment to apply that host’s migrations.
    • Package versioning: keep the module versioned and update both hosts independently via NuGet upgrades.
    • Angular: Each host’s Angular app can either:
      • Generate proxies directly from the host’s own backend that exposes the module’s APIs, or
      • Consume proxies from a static generated client library published to a private NPM feed. Both are valid; ABP recommends static client proxies for loose coupling.

  • Notes and tips

    • You do not need ABP Suite entities to generate Angular proxies. Proxies are generated from Swagger of your HTTP APIs.
    • When using multiple DbContexts and/or multiple DB providers in one solution, configure AbpDbContextOptions per DbContext (not globally) to prevent one provider overriding another. Use [ConnectionStringName] on each DbContext and provide separate connection strings in appsettings per host.
    • For migrations placement: for Angular UI solutions, you typically keep migrations in the HttpApi.Host (or a dedicated DbMigrations project used by DbMigrator). If your module is reused in different host types, each host should include the module’s ConfigureXxx(builder) in its migrations context and run its own migrations.

  2. Sources

  • Validated: ABP Module System basics
    • https://abp.io/docs/latest/framework/architecture/modularity/basics
  • Validated: Customizing/reusing existing modules
    • https://abp.io/docs/latest/framework/architecture/modularity/extending/customizing-application-modules-guide
  • Validated: Multiple DbContexts and provider configuration discussion (per-DbContext configuration tip referenced)
    • https://abp.io/support/questions/3579

  ---

  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