We are planning to enable audit on our app , but we want to use a separate MSSQL DB to store the audit data. What is the best recommended way to setup a new separate database , and do we need to implement a custom IAuditingStore store just because we use a different database ? there is a way to pass the connection string of the other database ?
thanks
17 Answer(s)
-
0
- Solution
You do not need a custom IAuditingStore just because you want to persist audit logs into a different SQL Server database. ABP’s EF Core integration already supports multiple databases and separate DbContexts per module.
Recommended approach (ABP 9.1.1):
- Add the Audit Logging EF Core module to your EFCore layer:
[DependsOn( typeof(AbpEntityFrameworkCoreSqlServerModule), typeof(AbpEntityFrameworkCoreModule), typeof(AbpAuditLoggingEntityFrameworkCoreModule) // important )] public class YourAppEntityFrameworkCoreModule : AbpModule { public override void ConfigureServices(ServiceConfigurationContext context) { Configure<AbpDbContextOptions>(options => { // Default DB for your main DbContext(s) options.Configure<YourAppDbContext>(c => c.UseSqlServer()); // Configure the audit logging DbContext to use a different connection string options.Configure<AbpAuditLoggingDbContext>(c => { c.UseSqlServer(); }); // Fallback provider if needed options.UseSqlServer(); }); // Map connection strings by name (Default vs. AuditLogging) // appsettings.json: // "ConnectionStrings": { // "Default": "Server=...;Database=MainDb;...", // "AuditLogging": "Server=...;Database=AuditDb;..." // } Configure<AbpDbConnectionOptions>(opt => { // Tell ABP to use "AuditLogging" connection for AbpAuditLoggingDbContext opt.Databases.Configure("AuditLogging", database => { database.MappedConnections.Add(typeof(AbpAuditLoggingDbContext)); }); }); } }- Set up connection strings in appsettings.json:
- In your HttpApi.Host (and any process that writes audit logs):
{ "ConnectionStrings": { "Default": "Server=.;Database=MainDb;Trusted_Connection=True;", "AuditLogging": "Server=.;Database=AuditDb;Trusted_Connection=True;" } }- Ensure the audit tables are created in the separate DB:
- Include the AbpAuditLoggingDbContext in your migration process so that:
- AbpAuditLogs
- AbpAuditLogActions
- AbpEntityChanges
- AbpEntityPropertyChanges are created in the AuditDb. Run migrations for the audit logging DbContext (or use ABP’s consolidated migrator if you already use it and it’s configured to handle multiple databases).
- Enable auditing as usual:
Configure<AbpAuditingOptions>(options => { options.IsEnabled = true; options.EntityHistorySelectors.AddAllEntities(); // etc. }); public override void OnApplicationInitialization(ApplicationInitializationContext context) { var app = context.GetApplicationBuilder(); app.UseAuditing(); // required }Why no custom IAuditingStore is required:
- The default AuditingStore provided by the Volo.Abp.AuditLogging module persists audit logs via IAuditLogRepository, which is backed by AbpAuditLoggingDbContext. By mapping AbpAuditLoggingDbContext to a different connection string (AuditLogging), the default store will automatically save to that separate database.
Optional: schema customization
- If you want to change the schema for audit tables, set it early in Program.cs (or module pre-config) of all projects that reference AbpAuditLogging EFCore:
AbpAuditLoggingDbProperties.DbSchema = "audit";Ensure your migrations align with the chosen schema.
- Sources
- Validated: Entity Framework Core integration and multiple databases:
- https://docs.abp.io/en/abp/latest/Entity-Framework-Core
- Validated: Support guidance showing provider configuration for AbpAuditLoggingDbContext and auditing middleware:
- https://abp.io/support/questions/6880
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.
-
0
Do I need to create another DBMigrator project for auditing DB or you recommended using one DB Migrator for both prod and auditing databases , any example ?
-
0
- Solution
Use a single DbMigrator to migrate both databases (your main “Default” DB and the separate Audit Logging DB). ABP’s DbMigrator already supports multiple DbContexts and multiple databases; you only need to map the AbpAuditLoggingDbContext to its own connection and ensure its migrations are included.
Steps:
- Configure connections and mapping
- appsettings.json (DbMigrator and any process that runs migrations):
{ "ConnectionStrings": { "Default": "Server=.;Database=MainDb;Trusted_Connection=True;TrustServerCertificate=true", "AuditLogging": "Server=.;Database=AuditDb;Trusted_Connection=True;TrustServerCertificate=true" } }- In your EF Core module (e.g., YourApp.EntityFrameworkCoreModule):
[DependsOn( typeof(AbpEntityFrameworkCoreSqlServerModule), typeof(AbpAuditLoggingEntityFrameworkCoreModule) )] public class YourAppEntityFrameworkCoreModule : AbpModule { public override void ConfigureServices(ServiceConfigurationContext context) { Configure<AbpDbContextOptions>(options => { options.UseSqlServer(); options.Configure<AbpAuditLoggingDbContext>(c => c.UseSqlServer()); }); Configure<AbpDbConnectionOptions>(options => { options.Databases.Configure("AuditLogging", db => { db.MappedConnections.Add(typeof(AbpAuditLoggingDbContext)); }); }); } }- Include migrations for both DbContexts
- Create migrations for your main app DbContext as usual.
- Create migrations for AbpAuditLoggingDbContext in your migrations project (or unified EFCore project), for example:
dotnet ef migrations add "Init_Audit_Logging" --context AbpAuditLoggingDbContextEnsure the design-time factory (IDesignTimeDbContextFactory) for AbpAuditLoggingDbContext reads the “AuditLogging” connection.
- Make the DbMigrator run all contexts
- The standard ABP DbMigrator template iterates registered IDbSchemaMigrator implementations for each context. Because AbpAuditLoggingEntityFrameworkCoreModule registers its DbSchemaMigrator for AbpAuditLoggingDbContext, the single DbMigrator will:
- Migrate Default (main) database.
- Then migrate the AuditLogging database.
- No second DbMigrator is needed.
- Run the single migrator
cd your-solution/src/YourApp.DbMigrator dotnet runIt should apply migrations to MainDb and AuditDb respectively.
- Notes:
- Do not call options.UseSqlServer() globally for all contexts if you later need a different provider; instead use options.Configure<TDbContext>(...) per context as above (ABP supports per-DbContext provider selection).
- If you prefer to group by name instead of type mapping, you can map via the connection name “AbpAuditLogging” and create that connection string; the key is that AbpAuditLoggingDbContext resolves to a distinct connection.
- Sources
- Validated: EF Core integration and per-context database mapping
- https://docs.abp.io/en/abp/latest/Entity-Framework-Core
- Validated: Connection string grouping and mapping with AbpDbConnectionOptions
- https://abp.io/docs/latest/framework/fundamentals/connection-strings
- Validated: Multiple DbContexts and providers discussion (shows per-context configuration approach)
- 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.
-
0
I get syntax error on this line : database.MappedConnections.Add(typeof(AbpAuditLoggingDbContext));
because Add method accept string , but we are passing type
-
0
- Solution
You’re right: AbpDbConnectionOptions.Databases.Configure(...).MappedConnections.Add(...) expects connection name strings, not DbContext types. Use the module’s connection name for Audit Logging.
Correct configuration for storing Audit Logs in a separate database:
- Define a dedicated connection string name (e.g., "AuditLogging") and set it in appsettings.json:
{ "ConnectionStrings": { "Default": "Server=.;Database=MainDb;Trusted_Connection=True;TrustServerCertificate=true", "AuditLogging": "Server=.;Database=AuditDb;Trusted_Connection=True;TrustServerCertificate=true" } }- Map the Audit Logging module’s connection name to "AuditLogging":
Configure<AbpDbConnectionOptions>(options => { options.Databases.Configure("AuditLogging", db => { // Map module connection names (strings), not types db.MappedConnections.Add("AbpAuditLogging"); }); });- Ensure EF Core uses SQL Server for the audit DbContext:
Configure<AbpDbContextOptions>(options => { options.UseSqlServer(); options.Configure<Volo.Abp.AuditLogging.EntityFrameworkCore.AbpAuditLoggingDbContext>(opt => { opt.UseSqlServer(); }); });- Make sure the Audit Logging EF Core module is added:
[DependsOn( typeof(Volo.Abp.EntityFrameworkCore.SqlServer.AbpEntityFrameworkCoreSqlServerModule), typeof(Volo.Abp.AuditLogging.EntityFrameworkCore.AbpAuditLoggingEntityFrameworkCoreModule) )] public class YourAppEntityFrameworkCoreModule : AbpModule { }- Why this works:
- ABP resolves connection strings by name. The Audit Logging EFCore integration uses the connection name "AbpAuditLogging". Mapping that name to your "AuditLogging" connection groups the audit module to your AuditDb, while other modules fall back to Default. No custom IAuditingStore is needed.
- Sources
- ABP Connection Strings (mapping module connections to a grouped connection):
- https://abp.io/docs/latest/framework/fundamentals/connection-strings
- ABP EF Core integration (per-DbContext provider configuration):
- https://docs.abp.io/en/abp/latest/Entity-Framework-Core
- ABP Audit Logging module:
- https://docs.abp.io/en/abp/latest/Modules/Audit-Logging
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.
-
0
But I see no relationship between connectionstring and auditing DB context, how to set the connection string name to auditing DB context or there is a default value for audit db context connectionstring
-
0
- Solution
The AbpAuditLoggingDbContext uses a predefined connection string name: "AbpAuditLogging". If you don’t define it, it falls back to the "Default" connection string.
To store audit logs in a separate database, add a dedicated connection string named AbpAuditLogging in your configuration. No extra wiring to the DbContext is needed beyond using the EF Core provider for that context.
Steps:
- Add connection strings
{ "ConnectionStrings": { "Default": "Server=.;Database=MainDb;Trusted_Connection=True;TrustServerCertificate=true", "AbpAuditLogging": "Server=.;Database=AuditDb;Trusted_Connection=True;TrustServerCertificate=true" } }- Ensure EF Core provider is configured for the audit DbContext
[DependsOn( typeof(Volo.Abp.EntityFrameworkCore.SqlServer.AbpEntityFrameworkCoreSqlServerModule), typeof(Volo.Abp.AuditLogging.EntityFrameworkCore.AbpAuditLoggingEntityFrameworkCoreModule) )] public class YourAppEntityFrameworkCoreModule : AbpModule { public override void ConfigureServices(ServiceConfigurationContext context) { Configure<AbpDbContextOptions>(options => { // Global provider or per-context options.UseSqlServer(); options.Configure<Volo.Abp.AuditLogging.EntityFrameworkCore.AbpAuditLoggingDbContext>(c => { c.UseSqlServer(); }); }); } }- (Optional) If you use connection string grouping/mapping
- Not required just to separate the DB. Defining "AbpAuditLogging" is sufficient because the module resolves that name automatically. Use AbpDbConnectionOptions mapping only if you need advanced grouping scenarios.
Why this works:
- The Audit Logging module resolves connection strings by the name "AbpAuditLogging". If it exists, AbpAuditLoggingDbContext uses it; otherwise it uses "Default". You don’t need to set a custom name or write a custom IAuditingStore for a different database.
- Sources
- Connection strings (default and per-module names):
- https://abp.io/docs/latest/framework/fundamentals/connection-strings
- EF Core integration and per-DbContext provider configuration:
- https://docs.abp.io/en/abp/latest/Entity-Framework-Core
- Audit Logging module (connection string name and fallback behavior):
- https://docs.abp.io/en/abp/latest/Modules/Audit-Logging
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.
-
0
followed all the above, yet when running DB Migrator no new DB is created, also when I run migration script from cmd I get this error :
dotnet ef migrations add "Init_Audit_Logging" --context AbpAuditLoggingDbContext Build started... Build succeeded. No DbContext named 'AbpAuditLoggingDbContext' was found.
-
0
- Solution
Why DbMigrator didn’t create the audit DB
- DbMigrator only runs migrations for DbContexts that:
- are registered in the solution and
- have migrations compiled into the assembly and
- have a configured provider/connection string.
- If AbpAuditLoggingDbContext has no migrations in your solution, DbMigrator won’t create the database.
- DbMigrator only runs migrations for DbContexts that:
Fix step-by-step
- Ensure EF Core provider/config for AbpAuditLoggingDbContext
[DependsOn( typeof(Volo.Abp.EntityFrameworkCore.SqlServer.AbpEntityFrameworkCoreSqlServerModule), typeof(Volo.Abp.AuditLogging.EntityFrameworkCore.AbpAuditLoggingEntityFrameworkCoreModule) )] public class YourAppEntityFrameworkCoreModule : AbpModule { public override void ConfigureServices(ServiceConfigurationContext context) { Configure<AbpDbContextOptions>(options => { // Global default or per-context config options.UseSqlServer(); options.Configure<Volo.Abp.AuditLogging.EntityFrameworkCore.AbpAuditLoggingDbContext>(c => { c.UseSqlServer(); }); }); } }- Provide a connection string named AbpAuditLogging (or it will fall back to Default)
- appsettings.json (DbMigrator and all hosts that write audit logs):
{ "ConnectionStrings": { "Default": "Server=.;Database=MainDb;Trusted_Connection=True;TrustServerCertificate=true", "AbpAuditLogging": "Server=.;Database=AuditDb;Trusted_Connection=True;TrustServerCertificate=true" } }- Add migrations for AbpAuditLoggingDbContext into your migrations project
Add the AbpAuditLogging.EntityFrameworkCore package reference to the project where you keep migrations (commonly the EFCore or DbMigrator project references it).
Make sure the project builds and can resolve the context at design-time. Typically you either:
- run the dotnet ef command in the project that contains the DbContext OR
- create a design-time factory.
Example design-time factory (only for migration generation):
using Microsoft.EntityFrameworkCore; using Microsoft.EntityFrameworkCore.Design; using Microsoft.Extensions.Configuration; using System.IO; using Volo.Abp.AuditLogging.EntityFrameworkCore; public class AbpAuditLoggingDbContextFactory : IDesignTimeDbContextFactory<AbpAuditLoggingDbContext> { public AbpAuditLoggingDbContext CreateDbContext(string[] args) { var configuration = new ConfigurationBuilder() .SetBasePath(Directory.GetCurrentDirectory()) .AddJsonFile("appsettings.json", optional: false) .AddEnvironmentVariables() .Build(); var builder = new DbContextOptionsBuilder<AbpAuditLoggingDbContext>() .UseSqlServer(configuration.GetConnectionString("AbpAuditLogging")); return new AbpAuditLoggingDbContext(builder.Options); } }- Generate the migrations (run in the project that references Volo.Abp.AuditLogging.EntityFrameworkCore and contains the factory above):
dotnet ef migrations add Init_Audit_Logging --context Volo.Abp.AuditLogging.EntityFrameworkCore.AbpAuditLoggingDbContextNotes:
- Use the full type name if the short name isn’t found.
- Ensure the startup project specified by --startup-project (if needed) can load your module configuration and has the connection strings.
- Run DbMigrator once migrations exist
- DbMigrator, by default, discovers and runs all registered IDbSchemaMigrator implementations (including AuditLogging’s). With the migrations compiled, it will create the AuditDb and apply its migrations automatically:
dotnet run --project src/YourApp.DbMigrator- Common pitfalls causing “No DbContext named 'AbpAuditLoggingDbContext' was found”
- You ran dotnet ef in a project that does not reference Volo.Abp.AuditLogging.EntityFrameworkCore.
- The context is not discoverable at design-time. Add a design-time factory (shown above), or set --startup-project and run the command from the EFCore project that references the module.
- You used the short context name; prefer the fully-qualified name: Volo.Abp.AuditLogging.EntityFrameworkCore.AbpAuditLoggingDbContext
- Ensure auditing is enabled and middleware added (for actual runtime logging)
Configure<AbpAuditingOptions>(options => { options.IsEnabled = true; options.EntityHistorySelectors.AddAllEntities(); }); public override void OnApplicationInitialization(ApplicationInitializationContext context) { var app = context.GetApplicationBuilder(); app.UseAuditing(); }- Summary
- Add the AuditLogging EFCore module and provider config.
- Add/use the AbpAuditLogging connection string (or it falls back to Default).
- Create migrations for AbpAuditLoggingDbContext (design-time factory often required).
- Run DbMigrator; it will then create and migrate the separate audit DB.
- Sources
- EF Core integration and per-context provider configuration:
- https://docs.abp.io/en/abp/latest/Entity-Framework-Core
- Connection strings (default and per-module names):
- https://abp.io/docs/latest/framework/fundamentals/connection-strings
- Audit Logging module (usage and DB objects):
- https://docs.abp.io/en/abp/latest/Modules/Audit-Logging
- Support thread confirming provider config and UseAuditing requirement:
- https://abp.io/support/questions/6880
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.
-
0
hi
, but we want to use a separate MSSQL DB to store the audit data
What is your current app database type? Is MSSQL too?
If so, you only need to add a new connection string.
See https://abp.io/docs/latest/framework/fundamentals/connection-strings#configure-the-connection-strings
- Create a new DbContext for a separate module, include
DbContextFactory - Create new migrations for the new DbContext
- Add a new
IMyProjectNameDbSchemaMigratorfor the new DbContext, thenDbMigratorwill use it to create the database.
Thanks
- Create a new DbContext for a separate module, include
-
0
Yes it is MSSQL , but based on previous comments, I am just using builtin
AbpAuditLoggingDbContextdo I really need to create a seperate module and DbContextFactory ? -
0
- Solution
No, you do not need to create a separate module or your own DbContext for auditing when you use the built-in AbpAuditLoggingDbContext. You also do not need a custom IAuditingStore. Use the provided Audit Logging module and its EF Core integration.
Minimal, working setup to persist audit logs in a separate MSSQL database with a single DbMigrator:
- Add packages and module dependencies (in your EFCore project):
[DependsOn( typeof(Volo.Abp.EntityFrameworkCore.SqlServer.AbpEntityFrameworkCoreSqlServerModule), typeof(Volo.Abp.AuditLogging.EntityFrameworkCore.AbpAuditLoggingEntityFrameworkCoreModule) )] public class YourAppEntityFrameworkCoreModule : AbpModule { public override void ConfigureServices(ServiceConfigurationContext context) { Configure<AbpDbContextOptions>(options => { // Set provider globally (covers AbpAuditLoggingDbContext too) options.UseSqlServer(); // or explicitly per context if you prefer options.Configure<Volo.Abp.AuditLogging.EntityFrameworkCore.AbpAuditLoggingDbContext>(c => { c.UseSqlServer(); }); }); } }- Provide a dedicated connection string named AbpAuditLogging. If it’s missing, the context falls back to Default:
{ "ConnectionStrings": { "Default": "Server=.;Database=MainDb;Trusted_Connection=True;TrustServerCertificate=true", "AbpAuditLogging": "Server=.;Database=AuditDb;Trusted_Connection=True;TrustServerCertificate=true" } }Put this in the appsettings.json of:
- Your DbMigrator project
- Every host that will write audit logs
- Create migrations for AbpAuditLoggingDbContext (no custom context required). Run the command in the project that references Volo.Abp.AuditLogging.EntityFrameworkCore (you can keep these migrations in your EFCore project). If the short context name is not found, use the fully-qualified name:
dotnet ef migrations add Init_Audit_Logging \ --context Volo.Abp.AuditLogging.EntityFrameworkCore.AbpAuditLoggingDbContextIf design-time discovery fails, add a design-time factory for AbpAuditLoggingDbContext pointing to the AbpAuditLogging connection.
- Use a single DbMigrator. Once the AbpAuditLoggingDbContext migrations are compiled into your solution, the standard ABP DbMigrator will execute schema migrators for all registered contexts, creating and updating both MainDb and AuditDb:
dotnet run --project src/YourApp.DbMigrator- Ensure auditing is enabled and middleware is added in your host:
Configure<AbpAuditingOptions>(o => { o.IsEnabled = true; }); app.UseAuditing();- Summary:
- Keep using the built-in AbpAuditLoggingDbContext.
- Provide the connection string named AbpAuditLogging.
- Generate migrations for AbpAuditLoggingDbContext.
- Run a single DbMigrator; no extra module, no custom IAuditingStore, and no second migrator needed.
- Sources
- Connection strings and named mapping (AbpAuditLogging falls back to Default if not defined):
- https://abp.io/docs/latest/framework/fundamentals/connection-strings
- EF Core integration and per-DbContext provider configuration:
- https://docs.abp.io/en/abp/latest/Entity-Framework-Core
- Audit Logging module (connection string name and usage):
- https://docs.abp.io/en/abp/latest/Modules/Audit-Logging
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.
-
0
the DB migrator now see the db and created the DB , but with only history table, I am trying to create migration script but says cannot fine this dbcontext :
dotnet ef migrations add Init_Audit_Logging
--context Volo.Abp.AuditLogging.EntityFrameworkCore.AbpAuditLoggingDbContext No DbContext named 'AbpAuditLoggingDbContext' was found.under which project should that script be run and is there another way to generate the migration script ?
-
0
- Solution
- You don’t need a new project. Generate AbpAuditLoggingDbContext migrations in the project that:
- References Volo.Abp.AuditLogging.EntityFrameworkCore, and
- Can resolve AbpAuditLoggingDbContext at design-time (either via the host as startup project or via a design-time factory).
Recommended, reliable ways:
A) Use a design-time factory (most reliable)
- Add this to your EFCore (migrations) project:
using Microsoft.EntityFrameworkCore; using Microsoft.EntityFrameworkCore.Design; using Microsoft.Extensions.Configuration; using System.IO; using Volo.Abp.AuditLogging.EntityFrameworkCore; public class AbpAuditLoggingDbContextFactory : IDesignTimeDbContextFactory<AbpAuditLoggingDbContext> { public AbpAuditLoggingDbContext CreateDbContext(string[] args) { var configuration = new ConfigurationBuilder() .SetBasePath(Directory.GetCurrentDirectory()) .AddJsonFile("appsettings.json", optional: true) .AddJsonFile("appsettings.Development.json", optional: true) .AddEnvironmentVariables() .Build(); var cs = configuration.GetConnectionString("AbpAuditLogging") ?? configuration.GetConnectionString("Default"); var builder = new DbContextOptionsBuilder<AbpAuditLoggingDbContext>() .UseSqlServer(cs); return new AbpAuditLoggingDbContext(builder.Options); } }- Ensure this project references Volo.Abp.AuditLogging.EntityFrameworkCore.
- Run in that project folder:
dotnet ef migrations add Init_Audit_Logging \ --context Volo.Abp.AuditLogging.EntityFrameworkCore.AbpAuditLoggingDbContext- This creates the migration files for the audit tables in that project.
B) Use your host as startup project
- If you don’t add a factory, run from the EFCore project that references the audit EFCore package and specify the host (HttpApi.Host or DbMigrator) as startup:
dotnet ef migrations add Init_Audit_Logging \ --project path/to/YourApp.EntityFrameworkCore \ --startup-project path/to/YourApp.HttpApi.Host \ --context Volo.Abp.AuditLogging.EntityFrameworkCore.AbpAuditLoggingDbContextRequirements:
- Host config contains ConnectionStrings:AbpAuditLogging (or Default).
- Your EFCore module config includes:
Configure<AbpDbContextOptions>(opts => { opts.UseSqlServer(); opts.Configure<Volo.Abp.AuditLogging.EntityFrameworkCore.AbpAuditLoggingDbContext>(c => c.UseSqlServer()); });- DependsOn includes AbpAuditLoggingEntityFrameworkCoreModule.
Why you only saw the __EFMigrationsHistory table
- It’s created when EF first touches the database, but actual audit tables will be created only after you add and apply migrations for AbpAuditLoggingDbContext.
After migrations exist
- Run your single DbMigrator; it will pick up the AbpAuditLoggingDbContext migrator and create the audit tables in the AbpAuditLogging (or Default) database:
dotnet run --project src/YourApp.DbMigratorQuick checklist
- EFCore project references Volo.Abp.AuditLogging.EntityFrameworkCore.
- Module depends on AbpAuditLoggingEntityFrameworkCoreModule and provider set via AbpDbContextOptions.
- ConnectionStrings contains AbpAuditLogging (or falls back to Default).
- Generate migrations using either A) factory or B) host as startup with fully qualified context name.
- Sources
- https://docs.abp.io/en/abp/latest/Entity-Framework-Core
- https://abp.io/docs/latest/framework/fundamentals/connection-strings
- https://docs.abp.io/en/abp/latest/Modules/Audit-Logging
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.
-
0
hi
Can you create a new project and create a private GitHub repository?
I will add some code.
My GitHub: https://github.com/maliming
Thanks
-
0
Fixed ,thanks
-
0
Great 👍