@ -0,0 +1,270 @@ |
|||
# ABP Framework – Cursor Rules |
|||
# Scope: ABP Framework repository (abpframework/abp) — for developing ABP itself, not ABP-based applications. |
|||
# Goal: Enforce ABP module architecture best practices (DDD, layering, DB/ORM independence), |
|||
# maintain backward compatibility, ensure extensibility, and align with ABP contribution guidelines. |
|||
|
|||
## Global Defaults |
|||
- Follow existing patterns in this repository first. Before generating new code, search for similar implementations and mirror their structure, naming, and conventions. |
|||
- Prefer minimal, focused diffs. Avoid drive-by refactors and formatting churn. |
|||
- Preserve public APIs. Avoid breaking changes unless explicitly requested and justified. |
|||
- Keep layers clean. Do not introduce forbidden dependencies between packages. |
|||
|
|||
## Module / Package Architecture (Layering) |
|||
- Use a layered module structure with explicit dependencies: |
|||
- *.Domain.Shared: constants, enums, shared types safe for all layers and 3rd-party clients. MUST NOT contain entities, repositories, domain services, or business objects. |
|||
- *.Domain: entities/aggregate roots, repository interfaces, domain services. |
|||
- *.Application.Contracts: application service interfaces and DTOs. |
|||
- *.Application: application service implementations. |
|||
- *.EntityFrameworkCore / *.MongoDb: ORM integration packages depend on *.Domain only. MUST NOT depend on other layers. |
|||
- *.HttpApi: REST controllers. MUST depend ONLY on *.Application.Contracts (NOT *.Application). |
|||
- *.HttpApi.Client: remote client proxies. MUST depend ONLY on *.Application.Contracts. |
|||
- *.Web: UI. MUST depend ONLY on *.HttpApi. |
|||
- Enforce dependency direction: |
|||
- Web -> HttpApi -> Application.Contracts |
|||
- Application -> Domain + Application.Contracts |
|||
- Domain -> Domain.Shared |
|||
- ORM integration -> Domain |
|||
- Do not leak web concerns into application/domain. |
|||
|
|||
## Domain Layer – Entities & Aggregate Roots |
|||
- Define entities in the domain layer. |
|||
- Entities must be valid at creation: |
|||
- Provide a primary constructor that enforces invariants. |
|||
- Always include a protected parameterless constructor for ORMs. |
|||
- Always initialize sub-collections in the primary constructor. |
|||
- Do NOT generate Guid keys inside constructors; accept `id` and generate using `IGuidGenerator` from the calling code. |
|||
- Make members `virtual` where appropriate (ORM/proxy compatibility). |
|||
- Protect consistency: |
|||
- Use non-public setters (private/protected/internal) when needed. |
|||
- Provide meaningful domain methods for state transitions; prefer returning `this` from setters when applicable. |
|||
- Aggregate roots: |
|||
- Always use a single `Id` property. Do NOT use composite keys. |
|||
- Prefer `Guid` keys for aggregate roots. |
|||
- Inherit from `AggregateRoot<TKey>` or audited base classes as required. |
|||
- Aggregate boundaries: |
|||
- Keep aggregates small. Avoid large sub-collections unless necessary. |
|||
- References: |
|||
- Reference other aggregate roots by Id only. |
|||
- Do NOT add navigation properties to other aggregate roots. |
|||
|
|||
## Repositories |
|||
- Define repository interfaces in the domain layer. |
|||
- Create one dedicated repository interface per aggregate root (e.g., `IProductRepository`). |
|||
- Public repository interfaces exposed by modules: |
|||
- SHOULD inherit from `IBasicRepository<TEntity, TKey>` (or `IReadOnlyRepository<...>` when suitable). |
|||
- SHOULD NOT expose `IQueryable` in the public contract. |
|||
- Internal implementations MAY use `IRepository<TEntity, TKey>` and `IQueryable` as needed. |
|||
- Do NOT define repositories for non-aggregate-root entities. |
|||
- Repository method conventions: |
|||
- All methods async. |
|||
- Include optional `CancellationToken cancellationToken = default` in every method. |
|||
- For single-entity returning methods: include `bool includeDetails = true`. |
|||
- For list returning methods: include `bool includeDetails = false`. |
|||
- Do NOT return composite projection classes like `UserWithRoles`. Use `includeDetails` for eager-loading. |
|||
- Avoid projection-only view models from repositories by default; only allow when performance is critical. |
|||
|
|||
## Domain Services |
|||
- Define domain services in the domain layer. |
|||
- Default: do NOT create interfaces for domain services unless necessary (mocking/multiple implementations). |
|||
- Naming: use `*Manager` suffix. |
|||
- Domain service methods: |
|||
- Focus on operations that enforce domain invariants and business rules. |
|||
- Query methods are acceptable when they encapsulate domain-specific lookup logic (e.g., normalized lookups, caching, complex resolution). Simple queries belong in repositories. |
|||
- Define methods that mutate state and enforce domain rules. |
|||
- Use specific, intention-revealing names (avoid generic `UpdateXAsync`). |
|||
- Accept valid domain objects as parameters; do NOT accept/return DTOs. |
|||
- On rule violations, throw `BusinessException` (or custom business exceptions). |
|||
- Use unique, namespaced error codes suitable for localization (e.g., `IssueTracking:ConcurrentOpenIssueLimit`). |
|||
- Do NOT depend on authenticated user logic; pass required values from application layer. |
|||
|
|||
## Application Services (Contracts + Implementation) |
|||
### Contracts |
|||
- Define one interface per application service in *.Application.Contracts. |
|||
- Interfaces must inherit from `IApplicationService`. |
|||
- Naming: `I*AppService`. |
|||
- Do NOT accept/return entities. Use DTOs and primitive parameters. |
|||
|
|||
### Method Naming & Shapes |
|||
- All service methods async and end with `Async`. |
|||
- Do not repeat entity names in method names (use `GetAsync`, not `GetProductAsync`). |
|||
- Standard CRUD: |
|||
- `GetAsync(Guid id)` returns a detailed DTO. |
|||
- `GetListAsync(QueryDto queryDto)` returns a list of detailed DTOs. |
|||
- `CreateAsync(CreateDto dto)` returns detailed DTO. |
|||
- `UpdateAsync(Guid id, UpdateDto dto)` returns detailed DTO (id MUST NOT be inside update DTO). |
|||
- `DeleteAsync(Guid id)` returns void/Task. |
|||
- `GetListAsync` query DTO: |
|||
- Filtering/sorting/paging fields optional with defaults. |
|||
- Enforce a maximum page size for performance. |
|||
|
|||
### DTO Usage |
|||
- Inputs: |
|||
- Do not include unused properties. |
|||
- Do NOT share input DTOs between methods. |
|||
- Do NOT use inheritance between input DTOs (except rare abstract base DTO cases; be very cautious). |
|||
|
|||
### Implementation |
|||
- Application layer must be independent of web. |
|||
- Implement interfaces in *.Application, name `ProductAppService` for `IProductAppService`. |
|||
- Inherit from `ApplicationService`. |
|||
- Make all public methods `virtual`. |
|||
- Avoid private helper methods; prefer `protected virtual` helpers for extensibility. |
|||
- Data access: |
|||
- Use dedicated repositories (e.g., `IProductRepository`). |
|||
- Do NOT use generic repositories. |
|||
- Do NOT put LINQ/SQL queries inside application service methods; repositories perform queries. |
|||
- Entity mutation: |
|||
- Load required entities from repositories. |
|||
- Mutate using domain methods. |
|||
- Call repository `UpdateAsync` after updates (do not assume change tracking). |
|||
- Extra properties: |
|||
- Use `MapExtraPropertiesTo` or configure object mapper for `MapExtraProperties`. |
|||
- Files: |
|||
- Do NOT use web types like `IFormFile` or `Stream` in application services. |
|||
- Controllers handle upload; pass `byte[]` (or similar) to application services. |
|||
- Cross-application-service calls: |
|||
- Do NOT call other application services within the same module. |
|||
- For reuse, push logic into domain layer or extract shared helpers carefully. |
|||
- You MAY call other modules’ application services only via their Application.Contracts. |
|||
|
|||
## DTO Conventions |
|||
- Define DTOs in *.Application.Contracts. |
|||
- Prefer ABP base DTO types (`EntityDto<TKey>`, audited DTOs). |
|||
- For aggregate roots, prefer extensible DTO base types so extra properties can map. |
|||
- DTO properties: public getters/setters. |
|||
- Input DTO validation: |
|||
- Use data annotations. |
|||
- Reuse constants from Domain.Shared wherever possible. |
|||
- Avoid logic in DTOs; only implement `IValidatableObject` when necessary. |
|||
- Do NOT use `[Serializable]` attribute (BinaryFormatter is obsolete); ABP uses JSON serialization. |
|||
- Output DTO strategy: |
|||
- Prefer a Basic DTO and a Detailed DTO; avoid many variants. |
|||
- Detailed DTOs: include reference details as nested basic DTOs; avoid duplicating raw FK ids unnecessarily. |
|||
|
|||
## EF Core Integration |
|||
- Define a separate DbContext interface + class per module. |
|||
- Do NOT rely on lazy loading; do NOT enable lazy loading. |
|||
- DbContext interface: |
|||
- Inherit from `IEfCoreDbContext`. |
|||
- Add `[ConnectionStringName("...")]`. |
|||
- Expose `DbSet<TEntity>` ONLY for aggregate roots. |
|||
- Do NOT include setters in the interface. |
|||
- DbContext class: |
|||
- Inherit `AbpDbContext<TDbContext>`. |
|||
- Add `[ConnectionStringName("...")]` and implement the interface. |
|||
- Table prefix/schema: |
|||
- Provide static `TablePrefix` and `Schema` defaulted from constants. |
|||
- Use short prefixes; `Abp` prefix reserved for ABP core modules. |
|||
- Default schema should be `null`. |
|||
- Model mapping: |
|||
- Do NOT configure entities directly inside `OnModelCreating`. |
|||
- Create `ModelBuilder` extension method `ConfigureX()` and call it. |
|||
- Call `b.ConfigureByConvention()` for each entity. |
|||
- Repository implementations: |
|||
- Inherit from `EfCoreRepository<TDbContextInterface, TEntity, TKey>`. |
|||
- Use DbContext interface as generic parameter. |
|||
- Pass cancellation tokens using `GetCancellationToken(cancellationToken)`. |
|||
- Implement `IncludeDetails(include)` extension per aggregate root with sub-collections. |
|||
- Override `WithDetailsAsync()` where needed. |
|||
|
|||
## MongoDB Integration |
|||
- Define a separate MongoDbContext interface + class per module. |
|||
- MongoDbContext interface: |
|||
- Inherit from `IAbpMongoDbContext`. |
|||
- Add `[ConnectionStringName("...")]`. |
|||
- Expose `IMongoCollection<TEntity>` ONLY for aggregate roots. |
|||
- MongoDbContext class: |
|||
- Inherit `AbpMongoDbContext` and implement the interface. |
|||
- Collection prefix: |
|||
- Provide static `CollectionPrefix` defaulted from constants. |
|||
- Use short prefixes; `Abp` prefix reserved for ABP core modules. |
|||
- Mapping: |
|||
- Do NOT configure directly inside `CreateModel`. |
|||
- Create `IMongoModelBuilder` extension method `ConfigureX()` and call it. |
|||
- Repository implementations: |
|||
- Inherit from `MongoDbRepository<TMongoDbContextInterface, TEntity, TKey>`. |
|||
- Pass cancellation tokens using `GetCancellationToken(cancellationToken)`. |
|||
- Ignore `includeDetails` for MongoDB in most cases (documents load sub-collections). |
|||
- Prefer `GetQueryableAsync()` to ensure ABP data filters are applied. |
|||
|
|||
## ABP Module Classes |
|||
- Every package must have exactly one `AbpModule` class. |
|||
- Naming: `Abp[ModuleName][Layer]Module` (e.g., `AbpIdentityDomainModule`, `AbpIdentityApplicationModule`). |
|||
- Use `[DependsOn(typeof(...))]` to declare module dependencies explicitly. |
|||
- Override `ConfigureServices` for DI registration and configuration. |
|||
- Override `OnApplicationInitialization` sparingly; prefer `ConfigureServices` when possible. |
|||
- Each module must be usable standalone; avoid hidden cross-module coupling. |
|||
|
|||
## Framework Extensibility |
|||
- All public and protected members should be `virtual` for inheritance-based extensibility. |
|||
- Prefer `protected virtual` over `private` for helper methods to allow overriding. |
|||
- Use `[Dependency(ReplaceServices = true)]` patterns for services intended to be replaceable. |
|||
- Provide extension points via interfaces and virtual methods. |
|||
- Document extension points with XML comments explaining intended usage. |
|||
- Consider providing `*Options` classes for configuration-based extensibility. |
|||
|
|||
## Backward Compatibility |
|||
- Do NOT remove or rename public API members without a deprecation cycle. |
|||
- Use `[Obsolete("Message. Use X instead.")]` with clear migration guidance before removal. |
|||
- Maintain binary and source compatibility within major versions. |
|||
- Add new optional parameters with defaults; do not change existing method signatures. |
|||
- When adding new abstract members to base classes, provide default implementations if possible. |
|||
- Prefer adding new interfaces over modifying existing ones. |
|||
|
|||
## Localization Resources |
|||
- Define localization resources in Domain.Shared. |
|||
- Resource class naming: `[ModuleName]Resource` (e.g., `IdentityResource`, `PermissionManagementResource`). |
|||
- JSON files under `/Localization/[ModuleName]/` directory. |
|||
- Use `LocalizableString.Create<TResource>("Key")` for localizable exceptions and messages. |
|||
- All user-facing strings must be localized; no hardcoded English text in code. |
|||
- Error codes should be namespaced: `ModuleName:ErrorCode` (e.g., `Identity:UserNameAlreadyExists`). |
|||
|
|||
## Settings & Features |
|||
- Define settings in `*SettingDefinitionProvider` in Domain.Shared or Domain. |
|||
- Setting names must follow `Abp.[ModuleName].[SettingName]` convention. |
|||
- Define features in `*FeatureDefinitionProvider` in Domain.Shared. |
|||
- Feature names must follow `[ModuleName].[FeatureName]` convention. |
|||
- Use constants for setting/feature names; never hardcode strings. |
|||
|
|||
## Permissions |
|||
- Define permissions in `*PermissionDefinitionProvider` in Application.Contracts. |
|||
- Permission names must follow `[ModuleName].[Permission]` convention. |
|||
- Use constants for permission names (e.g., `IdentityPermissions.Users.Create`). |
|||
- Group related permissions logically. |
|||
|
|||
## Event Bus & Distributed Events |
|||
- Use `ILocalEventBus` for intra-module communication within the same process. |
|||
- Use `IDistributedEventBus` for cross-module or cross-service communication. |
|||
- Define Event Transfer Objects (ETOs) in Domain.Shared for distributed events. |
|||
- ETO naming: `[EntityName][Action]Eto` (e.g., `UserCreatedEto`, `OrderCompletedEto`). |
|||
- Event handlers belong in the Application layer. |
|||
- ETOs should be simple, serializable, and contain only primitive types or nested ETOs. |
|||
|
|||
## Testing |
|||
- Unit tests: `*.Tests` projects for isolated logic testing with mocked dependencies. |
|||
- Integration tests: `*.EntityFrameworkCore.Tests` / `*.MongoDB.Tests` for repository and DB tests. |
|||
- Use `AbpIntegratedTest<TModule>` or `AbpApplicationTestBase<TModule>` base classes. |
|||
- Test modules should use `[DependsOn]` on the module under test. |
|||
- Use `Shouldly` assertions (ABP convention). |
|||
- Test both EF Core and MongoDB implementations when the module supports both. |
|||
- Include tests for permission checks, validation, and edge cases. |
|||
- Name test methods: `MethodName_Scenario_ExpectedResult` or `Should_ExpectedBehavior_When_Condition`. |
|||
|
|||
## Contribution Discipline (PR / Issues / Tests) |
|||
- Before significant changes, align via GitHub issue/discussion. |
|||
- PRs: |
|||
- Keep changes scoped and reviewable. |
|||
- Add/update unit/integration tests relevant to the change. |
|||
- Build and run tests for the impacted area when possible. |
|||
- Localization: |
|||
- Prefer the `abp translate` workflow for adding missing translations (generate `abp-translation.json`, fill, apply, then PR). |
|||
|
|||
## Review Checklist |
|||
- Layer dependencies respected (no forbidden references). |
|||
- No `IQueryable` or generic repository usage leaking into application/domain. |
|||
- Entities maintain invariants; Guid id generation not inside constructors. |
|||
- Repositories follow async + CancellationToken + includeDetails conventions. |
|||
- No web types in application services. |
|||
- DTOs in contracts, serializable, validated, minimal, no logic. |
|||
- EF/Mongo integration follows context + mapping + repository patterns. |
|||
- Minimal diff; no unnecessary API surface expansion. |
|||
@ -0,0 +1,372 @@ |
|||
# ABP Framework – GitHub Copilot Instructions |
|||
|
|||
> **Scope**: ABP Framework repository (abpframework/abp) — for developing ABP itself, not ABP-based applications. |
|||
> |
|||
> **Goal**: Enforce ABP module architecture best practices (DDD, layering, DB/ORM independence), maintain backward compatibility, ensure extensibility, and align with ABP contribution guidelines. |
|||
|
|||
--- |
|||
|
|||
## Global Defaults |
|||
|
|||
- Follow existing patterns in this repository first. Before generating new code, search for similar implementations and mirror their structure, naming, and conventions. |
|||
- Prefer minimal, focused diffs. Avoid drive-by refactors and formatting churn. |
|||
- Preserve public APIs. Avoid breaking changes unless explicitly requested and justified. |
|||
- Keep layers clean. Do not introduce forbidden dependencies between packages. |
|||
|
|||
--- |
|||
|
|||
## Module / Package Architecture (Layering) |
|||
|
|||
Use a layered module structure with explicit dependencies: |
|||
|
|||
| Layer | Purpose | Allowed Dependencies | |
|||
|-------|---------|---------------------| |
|||
| `*.Domain.Shared` | Constants, enums, shared types safe for all layers and 3rd-party clients. MUST NOT contain entities, repositories, domain services, or business objects. | None | |
|||
| `*.Domain` | Entities/aggregate roots, repository interfaces, domain services. | Domain.Shared | |
|||
| `*.Application.Contracts` | Application service interfaces and DTOs. | Domain.Shared | |
|||
| `*.Application` | Application service implementations. | Domain, Application.Contracts | |
|||
| `*.EntityFrameworkCore` / `*.MongoDb` | ORM integration packages. MUST NOT depend on other layers. | Domain only | |
|||
| `*.HttpApi` | REST controllers. MUST depend ONLY on Application.Contracts (NOT Application). | Application.Contracts | |
|||
| `*.HttpApi.Client` | Remote client proxies. MUST depend ONLY on Application.Contracts. | Application.Contracts | |
|||
| `*.Web` | UI layer. MUST depend ONLY on HttpApi. | HttpApi | |
|||
|
|||
### Dependency Direction |
|||
``` |
|||
Web -> HttpApi -> Application.Contracts |
|||
Application -> Domain + Application.Contracts |
|||
Domain -> Domain.Shared |
|||
ORM integration -> Domain |
|||
``` |
|||
|
|||
Do not leak web concerns into application/domain. |
|||
|
|||
--- |
|||
|
|||
## Domain Layer – Entities & Aggregate Roots |
|||
|
|||
- Define entities in the domain layer. |
|||
- Entities must be valid at creation: |
|||
- Provide a primary constructor that enforces invariants. |
|||
- Always include a `protected` parameterless constructor for ORMs. |
|||
- Always initialize sub-collections in the primary constructor. |
|||
- Do NOT generate Guid keys inside constructors; accept `id` and generate using `IGuidGenerator` from the calling code. |
|||
- Make members `virtual` where appropriate (ORM/proxy compatibility). |
|||
- Protect consistency: |
|||
- Use non-public setters (`private`/`protected`/`internal`) when needed. |
|||
- Provide meaningful domain methods for state transitions. |
|||
|
|||
### Aggregate Roots |
|||
- Always use a single `Id` property. Do NOT use composite keys. |
|||
- Prefer `Guid` keys for aggregate roots. |
|||
- Inherit from `AggregateRoot<TKey>` or audited base classes as required. |
|||
- Keep aggregates small. Avoid large sub-collections unless necessary. |
|||
|
|||
### References |
|||
- Reference other aggregate roots by Id only. |
|||
- Do NOT add navigation properties to other aggregate roots. |
|||
|
|||
--- |
|||
|
|||
## Repositories |
|||
|
|||
- Define repository interfaces in the domain layer. |
|||
- Create one dedicated repository interface per aggregate root (e.g., `IProductRepository`). |
|||
- Public repository interfaces exposed by modules: |
|||
- SHOULD inherit from `IBasicRepository<TEntity, TKey>` (or `IReadOnlyRepository<...>` when suitable). |
|||
- SHOULD NOT expose `IQueryable` in the public contract. |
|||
- Internal implementations MAY use `IRepository<TEntity, TKey>` and `IQueryable` as needed. |
|||
- Do NOT define repositories for non-aggregate-root entities. |
|||
|
|||
### Method Conventions |
|||
- All methods async. |
|||
- Include optional `CancellationToken cancellationToken = default` in every method. |
|||
- For single-entity returning methods: include `bool includeDetails = true`. |
|||
- For list returning methods: include `bool includeDetails = false`. |
|||
- Do NOT return composite projection classes like `UserWithRoles`. Use `includeDetails` for eager-loading. |
|||
- Avoid projection-only view models from repositories by default; only allow when performance is critical. |
|||
|
|||
--- |
|||
|
|||
## Domain Services |
|||
|
|||
- Define domain services in the domain layer. |
|||
- Default: do NOT create interfaces for domain services unless necessary (mocking/multiple implementations). |
|||
- Naming: use `*Manager` suffix. |
|||
|
|||
### Method Guidelines |
|||
- Focus on operations that enforce domain invariants and business rules. |
|||
- Query methods are acceptable when they encapsulate domain-specific lookup logic (e.g., normalized lookups, caching, complex resolution). Simple queries belong in repositories. |
|||
- Define methods that mutate state and enforce domain rules. |
|||
- Use specific, intention-revealing names (avoid generic `UpdateXAsync`). |
|||
- Accept valid domain objects as parameters; do NOT accept/return DTOs. |
|||
- On rule violations, throw `BusinessException` (or custom business exceptions). |
|||
- Use unique, namespaced error codes suitable for localization (e.g., `IssueTracking:ConcurrentOpenIssueLimit`). |
|||
- Do NOT depend on authenticated user logic; pass required values from application layer. |
|||
|
|||
--- |
|||
|
|||
## Application Services |
|||
|
|||
### Contracts |
|||
- Define one interface per application service in `*.Application.Contracts`. |
|||
- Interfaces must inherit from `IApplicationService`. |
|||
- Naming: `I*AppService`. |
|||
- Do NOT accept/return entities. Use DTOs and primitive parameters. |
|||
|
|||
### Method Naming & Shapes |
|||
- All service methods async and end with `Async`. |
|||
- Do not repeat entity names in method names (use `GetAsync`, not `GetProductAsync`). |
|||
|
|||
**Standard CRUD:** |
|||
```csharp |
|||
Task<ProductDto> GetAsync(Guid id); |
|||
Task<PagedResultDto<ProductDto>> GetListAsync(GetProductListInput input); |
|||
Task<ProductDto> CreateAsync(CreateProductInput input); |
|||
Task<ProductDto> UpdateAsync(Guid id, UpdateProductInput input); // id NOT inside DTO |
|||
Task DeleteAsync(Guid id); |
|||
``` |
|||
|
|||
### DTO Usage (Inputs) |
|||
- Do not include unused properties. |
|||
- Do NOT share input DTOs between methods. |
|||
- Do NOT use inheritance between input DTOs (except rare abstract base DTO cases; be very cautious). |
|||
|
|||
### Implementation |
|||
- Application layer must be independent of web. |
|||
- Implement interfaces in `*.Application`, name `ProductAppService` for `IProductAppService`. |
|||
- Inherit from `ApplicationService`. |
|||
- Make all public methods `virtual`. |
|||
- Avoid private helper methods; prefer `protected virtual` helpers for extensibility. |
|||
|
|||
### Data Access |
|||
- Use dedicated repositories (e.g., `IProductRepository`). |
|||
- Do NOT put LINQ/SQL queries inside application service methods; repositories perform queries. |
|||
|
|||
### Entity Mutation |
|||
- Load required entities from repositories. |
|||
- Mutate using domain methods. |
|||
- Call repository `UpdateAsync` after updates (do not assume change tracking). |
|||
|
|||
### Files |
|||
- Do NOT use web types like `IFormFile` or `Stream` in application services. |
|||
- Controllers handle upload; pass `byte[]` (or similar) to application services. |
|||
|
|||
### Cross-Service Calls |
|||
- Do NOT call other application services within the same module. |
|||
- For reuse, push logic into domain layer or extract shared helpers carefully. |
|||
- You MAY call other modules' application services only via their Application.Contracts. |
|||
|
|||
--- |
|||
|
|||
## DTO Conventions |
|||
|
|||
- Define DTOs in `*.Application.Contracts`. |
|||
- Prefer ABP base DTO types (`EntityDto<TKey>`, audited DTOs). |
|||
- For aggregate roots, prefer extensible DTO base types so extra properties can map. |
|||
- DTO properties: public getters/setters. |
|||
|
|||
### Input DTO Validation |
|||
- Use data annotations. |
|||
- Reuse constants from Domain.Shared wherever possible. |
|||
|
|||
### General Rules |
|||
- Avoid logic in DTOs; only implement `IValidatableObject` when necessary. |
|||
- Do NOT use `[Serializable]` attribute (BinaryFormatter is obsolete); ABP uses JSON serialization. |
|||
|
|||
### Output DTO Strategy |
|||
- Prefer a Basic DTO and a Detailed DTO; avoid many variants. |
|||
- Detailed DTOs: include reference details as nested basic DTOs; avoid duplicating raw FK ids unnecessarily. |
|||
|
|||
--- |
|||
|
|||
## EF Core Integration |
|||
|
|||
- Define a separate DbContext interface + class per module. |
|||
- Do NOT rely on lazy loading; do NOT enable lazy loading. |
|||
|
|||
### DbContext Interface |
|||
```csharp |
|||
[ConnectionStringName("ModuleName")] |
|||
public interface IModuleNameDbContext : IEfCoreDbContext |
|||
{ |
|||
DbSet<Product> Products { get; } // No setters, aggregate roots only |
|||
} |
|||
``` |
|||
|
|||
### DbContext Class |
|||
```csharp |
|||
[ConnectionStringName("ModuleName")] |
|||
public class ModuleNameDbContext : AbpDbContext<ModuleNameDbContext>, IModuleNameDbContext |
|||
{ |
|||
public static string TablePrefix { get; set; } = ModuleNameConsts.DefaultDbTablePrefix; |
|||
public static string? Schema { get; set; } = ModuleNameConsts.DefaultDbSchema; |
|||
|
|||
public DbSet<Product> Products { get; set; } |
|||
} |
|||
``` |
|||
|
|||
### Table Prefix/Schema |
|||
- Provide static `TablePrefix` and `Schema` defaulted from constants. |
|||
- Use short prefixes; `Abp` prefix reserved for ABP core modules. |
|||
- Default schema should be `null`. |
|||
|
|||
### Model Mapping |
|||
- Do NOT configure entities directly inside `OnModelCreating`. |
|||
- Create `ModelBuilder` extension method `ConfigureX()` and call it. |
|||
- Call `b.ConfigureByConvention()` for each entity. |
|||
|
|||
### Repository Implementations |
|||
- Inherit from `EfCoreRepository<TDbContextInterface, TEntity, TKey>`. |
|||
- Use DbContext interface as generic parameter. |
|||
- Pass cancellation tokens using `GetCancellationToken(cancellationToken)`. |
|||
- Implement `IncludeDetails(include)` extension per aggregate root with sub-collections. |
|||
- Override `WithDetailsAsync()` where needed. |
|||
|
|||
--- |
|||
|
|||
## MongoDB Integration |
|||
|
|||
- Define a separate MongoDbContext interface + class per module. |
|||
|
|||
### MongoDbContext Interface |
|||
```csharp |
|||
[ConnectionStringName("ModuleName")] |
|||
public interface IModuleNameMongoDbContext : IAbpMongoDbContext |
|||
{ |
|||
IMongoCollection<Product> Products { get; } // Aggregate roots only |
|||
} |
|||
``` |
|||
|
|||
### MongoDbContext Class |
|||
```csharp |
|||
public class ModuleNameMongoDbContext : AbpMongoDbContext, IModuleNameMongoDbContext |
|||
{ |
|||
public static string CollectionPrefix { get; set; } = ModuleNameConsts.DefaultDbTablePrefix; |
|||
} |
|||
``` |
|||
|
|||
### Mapping |
|||
- Do NOT configure directly inside `CreateModel`. |
|||
- Create `IMongoModelBuilder` extension method `ConfigureX()` and call it. |
|||
|
|||
### Repository Implementations |
|||
- Inherit from `MongoDbRepository<TMongoDbContextInterface, TEntity, TKey>`. |
|||
- Pass cancellation tokens using `GetCancellationToken(cancellationToken)`. |
|||
- Ignore `includeDetails` for MongoDB in most cases (documents load sub-collections). |
|||
- Prefer `GetQueryableAsync()` to ensure ABP data filters are applied. |
|||
|
|||
--- |
|||
|
|||
## ABP Module Classes |
|||
|
|||
- Every package must have exactly one `AbpModule` class. |
|||
- Naming: `Abp[ModuleName][Layer]Module` (e.g., `AbpIdentityDomainModule`, `AbpIdentityApplicationModule`). |
|||
- Use `[DependsOn(typeof(...))]` to declare module dependencies explicitly. |
|||
- Override `ConfigureServices` for DI registration and configuration. |
|||
- Override `OnApplicationInitialization` sparingly; prefer `ConfigureServices` when possible. |
|||
- Each module must be usable standalone; avoid hidden cross-module coupling. |
|||
|
|||
--- |
|||
|
|||
## Framework Extensibility |
|||
|
|||
- All public and protected members should be `virtual` for inheritance-based extensibility. |
|||
- Prefer `protected virtual` over `private` for helper methods to allow overriding. |
|||
- Use `[Dependency(ReplaceServices = true)]` patterns for services intended to be replaceable. |
|||
- Provide extension points via interfaces and virtual methods. |
|||
- Document extension points with XML comments explaining intended usage. |
|||
- Consider providing `*Options` classes for configuration-based extensibility. |
|||
|
|||
--- |
|||
|
|||
## Backward Compatibility |
|||
|
|||
- Do NOT remove or rename public API members without a deprecation cycle. |
|||
- Use `[Obsolete("Message. Use X instead.")]` with clear migration guidance before removal. |
|||
- Maintain binary and source compatibility within major versions. |
|||
- Add new optional parameters with defaults; do not change existing method signatures. |
|||
- When adding new abstract members to base classes, provide default implementations if possible. |
|||
- Prefer adding new interfaces over modifying existing ones. |
|||
|
|||
--- |
|||
|
|||
## Localization Resources |
|||
|
|||
- Define localization resources in Domain.Shared. |
|||
- Resource class naming: `[ModuleName]Resource` (e.g., `IdentityResource`, `PermissionManagementResource`). |
|||
- JSON files under `/Localization/[ModuleName]/` directory. |
|||
- Use `LocalizableString.Create<TResource>("Key")` for localizable exceptions and messages. |
|||
- All user-facing strings must be localized; no hardcoded English text in code. |
|||
- Error codes should be namespaced: `ModuleName:ErrorCode` (e.g., `Identity:UserNameAlreadyExists`). |
|||
|
|||
--- |
|||
|
|||
## Settings & Features |
|||
|
|||
- Define settings in `*SettingDefinitionProvider` in Domain.Shared or Domain. |
|||
- Setting names must follow `Abp.[ModuleName].[SettingName]` convention. |
|||
- Define features in `*FeatureDefinitionProvider` in Domain.Shared. |
|||
- Feature names must follow `[ModuleName].[FeatureName]` convention. |
|||
- Use constants for setting/feature names; never hardcode strings. |
|||
|
|||
--- |
|||
|
|||
## Permissions |
|||
|
|||
- Define permissions in `*PermissionDefinitionProvider` in Application.Contracts. |
|||
- Permission names must follow `[ModuleName].[Permission]` convention. |
|||
- Use constants for permission names (e.g., `IdentityPermissions.Users.Create`). |
|||
- Group related permissions logically. |
|||
|
|||
--- |
|||
|
|||
## Event Bus & Distributed Events |
|||
|
|||
- Use `ILocalEventBus` for intra-module communication within the same process. |
|||
- Use `IDistributedEventBus` for cross-module or cross-service communication. |
|||
- Define Event Transfer Objects (ETOs) in Domain.Shared for distributed events. |
|||
- ETO naming: `[EntityName][Action]Eto` (e.g., `UserCreatedEto`, `OrderCompletedEto`). |
|||
- Event handlers belong in the Application layer. |
|||
- ETOs should be simple, serializable, and contain only primitive types or nested ETOs. |
|||
|
|||
--- |
|||
|
|||
## Testing |
|||
|
|||
- Unit tests: `*.Tests` projects for isolated logic testing with mocked dependencies. |
|||
- Integration tests: `*.EntityFrameworkCore.Tests` / `*.MongoDB.Tests` for repository and DB tests. |
|||
- Use `AbpIntegratedTest<TModule>` or `AbpApplicationTestBase<TModule>` base classes. |
|||
- Test modules should use `[DependsOn]` on the module under test. |
|||
- Use `Shouldly` assertions (ABP convention). |
|||
- Test both EF Core and MongoDB implementations when the module supports both. |
|||
- Include tests for permission checks, validation, and edge cases. |
|||
- Name test methods: `MethodName_Scenario_ExpectedResult` or `Should_ExpectedBehavior_When_Condition`. |
|||
|
|||
--- |
|||
|
|||
## Contribution Discipline (PR / Issues / Tests) |
|||
|
|||
- Before significant changes, align via GitHub issue/discussion. |
|||
|
|||
### PRs |
|||
- Keep changes scoped and reviewable. |
|||
- Add/update unit/integration tests relevant to the change. |
|||
- Build and run tests for the impacted area when possible. |
|||
|
|||
### Localization |
|||
- Prefer the `abp translate` workflow for adding missing translations (generate `abp-translation.json`, fill, apply, then PR). |
|||
|
|||
--- |
|||
|
|||
## Review Checklist |
|||
|
|||
- [ ] Layer dependencies respected (no forbidden references). |
|||
- [ ] No `IQueryable` leaking into public repository contracts. |
|||
- [ ] Entities maintain invariants; Guid id generation not inside constructors. |
|||
- [ ] Repositories follow async + CancellationToken + includeDetails conventions. |
|||
- [ ] No web types in application services. |
|||
- [ ] DTOs in contracts, validated, minimal, no logic. |
|||
- [ ] EF/Mongo integration follows context + mapping + repository patterns. |
|||
- [ ] Public members are `virtual` for extensibility. |
|||
- [ ] Backward compatibility maintained; no breaking changes without deprecation. |
|||
- [ ] Minimal diff; no unnecessary API surface expansion. |
|||
@ -0,0 +1,342 @@ |
|||
# ABP Platform 10.1 RC Has Been Released |
|||
|
|||
We are happy to release [ABP](https://abp.io) version **10.1 RC** (Release Candidate). This blog post introduces the new features and important changes in this new version. |
|||
|
|||
Try this version and provide feedback for a more stable version of ABP v10.1! Thanks to you in advance. |
|||
|
|||
## Get Started with the 10.1 RC |
|||
|
|||
You can check the [Get Started page](https://abp.io/get-started) to see how to get started with ABP. You can either download [ABP Studio](https://abp.io/get-started#abp-studio-tab) (**recommended**, if you prefer a user-friendly GUI application - desktop application) or use the [ABP CLI](https://abp.io/docs/latest/cli). |
|||
|
|||
By default, ABP Studio uses stable versions to create solutions. Therefore, if you want to create a solution with a preview version, first you need to create a solution and then switch your solution to the preview version from the ABP Studio UI: |
|||
|
|||
 |
|||
|
|||
## Migration Guide |
|||
|
|||
There are a few breaking changes in this version that may affect your application. Please read the migration guide carefully, if you are upgrading from v10.0 or earlier: [ABP Version 10.1 Migration Guide](https://abp.io/docs/10.1/release-info/migration-guides/abp-10-1). |
|||
|
|||
## What's New with ABP v10.1? |
|||
|
|||
In this section, I will introduce some major features released in this version. |
|||
Here is a brief list of titles explained in the next sections: |
|||
|
|||
- Resource-Based Authorization |
|||
- Introducing the TickerQ Background Worker Provider |
|||
- Angular UI: Improving Authentication Token Handling |
|||
- Angular Version Upgrade to v21 |
|||
- File Management Module: Public File Sharing Support |
|||
- Payment Module: Public Page Implementation for Blazor & Angular UIs |
|||
- AI Management Module: Blazor & Angular UIs |
|||
- Identity PRO Module: Password History Support |
|||
- Account PRO Module: Introducing WebAuthn Passkeys |
|||
|
|||
### Resource-Based Authorization |
|||
|
|||
ABP v10.1 introduces **Resource-Based Authorization**, a powerful feature that enables fine-grained access control based on specific resource instances. This enhancement addresses a long-requested feature ([#236](https://github.com/abpframework/abp/issues/236)) that allows you to implement authorization logic that depends on the resource being accessed, not just static roles or permissions. |
|||
|
|||
**What is Resource-Based Authorization?** |
|||
|
|||
Unlike traditional permission-based authorization where you check if a user has a general permission (like "CanEditDocuments"), resource-based authorization allows you to make authorization decisions based on the specific resource instance. For example: |
|||
|
|||
- Allow users to edit only their own blog posts |
|||
- Grant access to documents based on ownership or sharing settings |
|||
- Implement complex authorization rules that depend on resource properties |
|||
|
|||
 |
|||
|
|||
#### How It Works? |
|||
|
|||
**1. Define resource permissions (`AddResourcePermission`)**: |
|||
|
|||
```csharp |
|||
public class MyPermissionDefinitionProvider : PermissionDefinitionProvider |
|||
{ |
|||
public override void Define(IPermissionDefinitionContext context) |
|||
{ |
|||
//other permissions... |
|||
|
|||
context.AddResourcePermission( |
|||
name: BookManagementPermissions.Manage.Resources.Consume, |
|||
resourceName: BookManagementPermissions.Manage.Resources.Name, |
|||
managementPermissionName: BookManagementPermissions.Manage.ManagePermissions, |
|||
L("LocalizedPermissionDisplayName") |
|||
); |
|||
} |
|||
} |
|||
``` |
|||
|
|||
**2. Use `IResourcePermissionChecker.IsGrantedAsync` in your code to perform the resource permission check**: |
|||
|
|||
```csharp |
|||
protected IResourcePermissionChecker ResourcePermissionChecker { get; } |
|||
|
|||
public async Task MyService() |
|||
{ |
|||
if(await ResourcePermissionChecker.IsGrantedAsync( |
|||
BookManagementPermissions.Manage.Resources.Consume, |
|||
BookManagementPermissions.Manage.Resources.Name, |
|||
workspaceConfiguration.WorkspaceId!.Value.ToString())) |
|||
{ |
|||
return; |
|||
} |
|||
|
|||
//... |
|||
} |
|||
``` |
|||
|
|||
**3. Use the relevant `ResourcePermissionManagementModel` in your UI:** |
|||
|
|||
> The following code block demonstrates its usage in the Blazor UI, but the same component is also implemented for MVC & Angular UIs (however, component name might be different, please refer to the documentation before using the component). |
|||
|
|||
```xml |
|||
<ResourcePermissionManagementModal @ref="PermissionManagementModal" /> |
|||
|
|||
@code { |
|||
ResourcePermissionManagementModal PermissionManagementModal { get; set; } = null!; |
|||
|
|||
private Task OpenResourcePermissionModel() |
|||
{ |
|||
await PermissionManagementModal.OpenAsync( |
|||
resourceName: BookManagementPermissions.Manage.Resources.Name, |
|||
resourceKey: entity.Id.ToString(), |
|||
resourceDisplayName: entity.Name |
|||
); |
|||
} |
|||
} |
|||
``` |
|||
|
|||
This feature integrates perfectly with ABP's existing authorization infrastructure and provides a standard way to implement complex, context-aware authorization scenarios in your applications. |
|||
|
|||
### Introducing the TickerQ Background Worker Provider |
|||
|
|||
ABP v10.1 now includes **[TickerQ](https://tickerq.net/)** as a new background job and background worker provider option. TickerQ is a fast, reflection-free background task scheduler for .NET — built with source generators, EF Core integration, cron + time-based execution, and a real-time dashboard. It offers reliable job execution with built-in retry mechanisms, persistent job storage, and efficient resource usage. |
|||
|
|||
To use TickerQ in your ABP-based solution, refer to the following documentation: |
|||
|
|||
- [TickerQ Background Job Integration](https://abp.io/docs/10.1/framework/infrastructure/background-jobs/tickerq) |
|||
- [TickerQ Background Worker Integration](https://abp.io/docs/10.1/framework/infrastructure/background-workers/tickerq) |
|||
|
|||
### Angular UI: Improving Authentication Token Handling |
|||
|
|||
ABP v10.1 brings significant improvements to **Angular authentication token handling**, making token refresh more reliable and providing better error handling for expired or invalid tokens. |
|||
|
|||
#### What's Improved? |
|||
|
|||
Prior to this version, access tokens issued by the auth-server were stored in localStorage, making them vulnerable to XSS attacks. We've made the following enhancements to improve safety and reduce security risks: |
|||
|
|||
- Store sensitive tokens in memory |
|||
- Use web-workers for state sharing between tabs |
|||
|
|||
These enhancements are automatically available in new Angular projects and can be applied to existing projects by updating ABP packages. |
|||
|
|||
> See [#23930](https://github.com/abpframework/abp/issues/23930) for more details. |
|||
|
|||
### Angular Version Upgrade to v21 |
|||
|
|||
ABP v10.1 **upgrades Angular to version 21**, bringing the latest improvements and features from the Angular ecosystem to your ABP applications. We've upgraded the relevant core Angular packages and 3rd party packages such as **angular-oauth2-oidc** and **ng-bootstrap**. We will also update the ABP Studio templates along with the stable v10.1 release. |
|||
|
|||
> See [#24384](https://github.com/abpframework/abp/issues/24384) for the complete change list. |
|||
|
|||
### File Management Module: Public File Sharing Support |
|||
|
|||
_This is a **PRO** feature available for ABP Commercial customers._ |
|||
|
|||
The **File Management Module** now supports **public file sharing** via shareable links, similar to popular cloud storage services like Google Drive or Dropbox. This feature enables you to generate public URLs for files that can be accessed without authentication. |
|||
|
|||
 |
|||
|
|||
**Example Share URL:** |
|||
|
|||
```text |
|||
https://abp.io/api/file-management/file-descriptor/share?shareToken=CfDJ8AK%2BOEpCD... |
|||
``` |
|||
|
|||
**Configuration:** |
|||
|
|||
You can configure the public share domain through options: |
|||
|
|||
```csharp |
|||
Configure<FileManagementWebOptions>(options => |
|||
{ |
|||
options.FileDownloadRootUrl = "https://files.yourdomain.com"; |
|||
}); |
|||
``` |
|||
|
|||
This feature is available for all supported UI types (MVC, Angular, Blazor) and integrates seamlessly with the existing [File Management Module](https://abp.io/docs/latest/modules/file-management). |
|||
|
|||
### Payment Module: Public Page Implementation for Blazor & Angular UIs |
|||
|
|||
The **Payment Module** now includes **public page implementations for Angular and Blazor UIs**, completing UI coverage across all ABP-supported frameworks. Previously, public payment pages (payment gateway selection, pre-payment, and post-payment pages) were only available for MVC/Razor Pages UI. With this version, both admin and public pages are now available for MVC, Angular, and Blazor UIs. |
|||
|
|||
The public payment pages seamlessly integrate with ABP's [Payment Module](https://abp.io/docs/latest/modules/payment) and support all configured payment gateways. The documentation will be updated soon with detailed integration guides and examples at [abp.io/docs/latest/modules/payment](https://abp.io/docs/latest/modules/payment). |
|||
|
|||
### AI Management Module: Blazor & Angular UIs |
|||
|
|||
With this version, Angular and Blazor UIs for the [AI Management module](https://abp.io/docs/latest/modules/ai-management) have been implemented, completing the cross-platform support for this powerful AI integration module. |
|||
|
|||
 |
|||
|
|||
The AI Management Module builds on top of [ABP's AI Infrastructure](https://abp.io/docs/latest/framework/infrastructure/artificial-intelligence) and provides: |
|||
|
|||
- **Multi-Provider Support**: Integrate with OpenAI, Google Gemini, Anthropic Claude, and more from a unified API |
|||
- **Workspace-Based Organization**: Organize AI capabilities into separate workspaces for different use cases |
|||
- **Built-In Chat Interface**: Ready-to-use chat UI for conversational AI |
|||
- **Chat Widget**: Drop-in chat widget component for customer support or AI assistance |
|||
- **Resource-Based Permissions**: Control access to specific AI workspaces for users, roles, or clients |
|||
|
|||
Learn more about the AI Management Module in the [announcement post](https://abp.io/community/announcements/introducing-the-ai-management-module-nz9404a9) and [official documentation](https://abp.io/docs/latest/modules/ai-management). |
|||
|
|||
### Identity PRO Module: Password History Support |
|||
|
|||
The [**Identity PRO Module**](https://abp.io/docs/latest/modules/identity-pro) now includes **Password History** support, preventing users from reusing previous passwords. This security feature helps enforce stronger password policies and meet compliance requirements for your organization. |
|||
|
|||
Administrators can enable password reuse prevention by toggling the related setting on the _Administration -> Settings -> Identity Management_ page: |
|||
|
|||
 |
|||
|
|||
When changing a password, the system checks the specified number of previous passwords and displays an error message if the new password matches any of them: |
|||
|
|||
 |
|||
|
|||
 |
|||
|
|||
### Account PRO Module: Introducing WebAuthn Passkeys |
|||
|
|||
ABP v10.1 introduces **Passkey authentication**, enabling passwordless sign-in using modern biometric authentication methods. Built on the **WebAuthn standard (FIDO2)**, this feature allows users to authenticate using Face ID, Touch ID, Windows Hello, Android biometrics, security keys, or other platform authenticators. |
|||
|
|||
**What are Passkeys?** |
|||
|
|||
Passkeys are a modern, phishing-resistant authentication method that replaces traditional passwords: |
|||
|
|||
- **Passwordless**: No passwords to remember, type, or manage |
|||
- **Secure**: Uses public/private key cryptography stored on the user's device |
|||
- **Convenient**: Sign in with a fingerprint, face scan, or device PIN |
|||
- **Cross-Platform**: Can sync across devices depending on platform support (Apple, Google, Microsoft) |
|||
|
|||
**How It Works:** |
|||
|
|||
**1. Enable or disable the WebAuthn passkeys feature in the _Settings -> Account -> Passkeys_ page:** |
|||
|
|||
 |
|||
|
|||
**2. Add your passkeys in the _Account/Manage_ page:** |
|||
|
|||
 |
|||
|
|||
 |
|||
|
|||
**3. Use the _Passkey login_ option for passwordless authentication the next time you log in:** |
|||
|
|||
 |
|||
|
|||
> For more information, refer to the [Web Authentication API (WebAuthn) passkeys](https://abp.io/docs/10.1/modules/account/passkey) documentation. |
|||
|
|||
## Community News |
|||
|
|||
### Special Offer: Level Up Your ABP Skills with 33% Off Live Trainings! |
|||
|
|||
 |
|||
|
|||
We're excited to announce a special limited-time offer for developers looking to master the ABP Platform! Get **33% OFF** on all ABP live training sessions and accelerate your learning journey with hands-on guidance from ABP experts. |
|||
|
|||
**Why Join ABP Live Trainings?** |
|||
|
|||
Our live training sessions provide an immersive learning experience where you can: |
|||
|
|||
- **Learn from the Experts**: Get direct instruction from ABP team members and experienced trainers who know the platform inside and out. |
|||
- **Hands-On Practice**: Work through real-world scenarios and build actual applications during the sessions. |
|||
- **Interactive Q&A**: Ask questions in real-time and get immediate answers to your specific challenges. |
|||
- **Comprehensive Coverage**: From fundamentals to advanced topics, our trainings cover everything you need to build production-ready applications with ABP. |
|||
- **Certificate of Completion**: Receive a certificate upon completing the training to showcase your ABP expertise. |
|||
|
|||
Don't miss this opportunity to invest in your skills and career. Whether you're new to ABP or looking to advance your expertise, our live trainings provide the structured learning path you need to succeed. |
|||
|
|||
> 👉 [Learn more and claim your discount here](https://abp.io/community/announcements/improve-your-abp-skills-with-33-off-live-trainings-hjnw57xu) |
|||
|
|||
### Introducing the ABP Referral Program |
|||
|
|||
 |
|||
|
|||
We're thrilled to announce the launch of the **ABP.IO Referral Program**, a new way for our community members to earn rewards while helping others discover the ABP Platform! |
|||
|
|||
**How It Works:** |
|||
|
|||
ABP's Referral Program is simple and rewarding: |
|||
|
|||
1. **Get Your Unique Referral Link**: Sign up for the program and receive your personalized referral link. |
|||
2. **Share with Your Network**: Share your link with colleagues, friends, and fellow developers who could benefit from ABP. |
|||
3. **Earn Rewards**: When someone purchases an ABP Commercial license through your referral link, **you earn 5% commission**! |
|||
|
|||
By joining the referral program, you're not just earning rewards and also you're helping other developers discover a platform that can significantly improve their productivity and project success. |
|||
|
|||
> 👉 [Join the ABP.IO Referral Program](https://abp.io/community/announcements/introducing-abp.io-referral-program-b59obhe7) |
|||
|
|||
### Announcing AI Management Module |
|||
|
|||
We are excited to announce the [AI Management Module](https://abp.io/docs/10.0/modules/ai-management), a powerful new module to the ABP Platform that makes managing AI capabilities in your applications easier than ever! |
|||
|
|||
 |
|||
|
|||
**What is the AI Management Module?** |
|||
|
|||
Built on top of the [ABP Framework's AI infrastructure](https://abp.io/docs/latest/framework/infrastructure/artificial-intelligence), the **AI Management Module** allows you to manage AI workspaces dynamically without touching your code. Whether you're building a customer support chatbot, adding AI-powered search, or creating intelligent automation workflows, this module provides everything you need to manage AI integrations through a user-friendly interface. |
|||
|
|||
**Key Features:** |
|||
|
|||
- **Multi-Provider Support**: Allows integrating with multiple AI providers including OpenAI, Google Gemini, Anthropic Claude, and more from a single unified API. |
|||
- **Buit-In Chat Interface** |
|||
- **Ready to Use Chat Widget** |
|||
- and more... (RAG & MCP supports are on the way!) |
|||
|
|||
👉 [Read the announcement post for more...](https://abp.io/community/announcements/introducing-the-ai-management-module-nz9404a9) |
|||
|
|||
### We Were At .NET Conf China 2025! |
|||
|
|||
 |
|||
|
|||
The ABP team participated in **.NET Conf China 2025** in Shanghai, celebrating the release of .NET 10 (LTS) and the achievements of the .NET community in China. |
|||
|
|||
**Event Highlights:** |
|||
|
|||
The conference brought together hundereds of developers and featured Scott Hanselman's opening keynote announcing .NET 10's availability, focused on four pillars: AI, cloud-native, cross-platform, and performance. The event covered three main themes: performance improvements, AI integration, and cross-platform development, with in-depth sessions on topics ranging from Avalonia and Blazor to AI agents and enterprise adoption. |
|||
|
|||
**ABP's Participation:** |
|||
|
|||
At the ABP booth, we showcased our developer platform with live demonstrations of modular architecture, multi-tenancy support, and built-in authentication systems. We hosted interactive raffles with prizes including ABP stickers, the _Mastering ABP Framework_ book, and Bluetooth headphones. The booth was a hub for sharing experiences, impromptu code walkthroughs, and meaningful conversations with Chinese developers about ABP's future. |
|||
|
|||
> 👉 [Read the full event recap](https://abp.io/community/announcements/.net-conf-china-2025-fz03gfge) |
|||
|
|||
### Community Talks 2025.10: AI-Powered .NET Apps with ABP & Microsoft Agent Framework |
|||
|
|||
 |
|||
|
|||
In our latest ABP Community Talks session, we dove deep into the world of **Artificial Intelligence** and its integration with the ABP Framework. This session explored Microsoft's cutting-edge AI libraries: **Extensions AI**, **Semantic Kernel**, and the **Microsoft Agent Framework**. |
|||
|
|||
**What We Covered:** |
|||
|
|||
We introduced the new **AI Management Module**, discussing its current status and roadmap. The session included practical demonstrations on building intelligent applications with the Microsoft Agent Framework within ABP projects, showing how these technologies empower developers to create AI-powered .NET applications. |
|||
|
|||
> 👉 [Missed the live session? Click here to watch the full session](https://www.youtube.com/live/tEcd2H6yXQk) |
|||
|
|||
### New ABP Community Articles |
|||
|
|||
There are exciting articles contributed by the ABP community as always. I will highlight some of them here: |
|||
|
|||
- [Salih Özkara](https://github.com/salihozkara) has published 3 new articles: |
|||
- [Building Dynamic XML Sitemaps with ABP Framework](https://abp.io/community/articles/building-dynamic-xml-sitemaps-with-abp-framework-n3q6schd) |
|||
- [Implement Automatic Method-Level Caching in ABP Framework](https://abp.io/community/articles/implement-automatic-methodlevel-caching-in-abp-framework-4uzd3wx8) |
|||
- [Building Production-Ready LLM Applications with .NET: A Practical Guide](https://abp.io/community/articles/building-production-ready-llm-applications-with-net-ya7qemfa) |
|||
- [Adnan Ali](https://abp.io/community/members/adnanaldaim) has published 2 new articles: |
|||
- [Integrating AI into ABP.IO Applications: The Complete Guide to Volo.Abp.AI and AI Management Module](https://abp.io/community/articles/integrating-ai-into-abp.io-applications-the-complete-guide-jc9fbjq0) |
|||
- [How ABP.IO Framework Cuts Your MVP Development Time by 60%](https://abp.io/community/articles/how-abp.io-framework-cuts-your-mvp-development-time-by-60-8l7m3ugj) |
|||
- [My First Look and Experience with Google AntiGravity](https://abp.io/community/articles/my-first-look-and-experience-with-google-antigravity-0hr4sjtf) by [Alper Ebiçoğlu](https://twitter.com/alperebicoglu) |
|||
- [TOON vs JSON for LLM Prompts in ABP: Token-Efficient Structured Context](https://abp.io/community/articles/toon-vs-json-b4rn2avd) by [Suhaib Mousa](https://abp.io/community/members/suhaib-mousa) |
|||
|
|||
Thanks to the ABP Community for all the content they have published. You can also [post your ABP-related (text or video) content](https://abp.io/community/posts/create) to the ABP Community. |
|||
|
|||
## Conclusion |
|||
|
|||
This version comes with some new features and a lot of enhancements to the existing features. You can see the [Road Map](https://abp.io/docs/10.1/release-info/road-map) documentation to learn about the release schedule and planned features for the next releases. Please try ABP v10.1 RC and provide feedback to help us release a more stable version. |
|||
|
|||
Thanks for being a part of this community! |
|||
|
After Width: | Height: | Size: 1.8 MiB |
|
After Width: | Height: | Size: 20 KiB |
|
After Width: | Height: | Size: 35 KiB |
|
After Width: | Height: | Size: 129 KiB |
|
After Width: | Height: | Size: 194 KiB |
|
After Width: | Height: | Size: 665 KiB |
|
After Width: | Height: | Size: 76 KiB |
|
After Width: | Height: | Size: 21 KiB |
|
After Width: | Height: | Size: 18 KiB |
|
After Width: | Height: | Size: 16 KiB |
|
After Width: | Height: | Size: 23 KiB |
|
After Width: | Height: | Size: 15 KiB |
|
After Width: | Height: | Size: 24 KiB |
|
After Width: | Height: | Size: 112 KiB |
|
After Width: | Height: | Size: 24 KiB |
|
After Width: | Height: | Size: 7.6 KiB |
|
After Width: | Height: | Size: 22 KiB |
@ -0,0 +1,170 @@ |
|||
# Async Chain of Persistence Pattern: Designing for Failure in Event-Driven Systems |
|||
|
|||
## Introduction |
|||
Messages can get lost while being processed when you use asynchronous messaging or event handling. |
|||
The Async Chain of Persistence Pattern makes sure that no message is ever lost from the system by making sure that the message is always stored at every step of the workflow. |
|||
|
|||
## The Fundamental Principle of Pattern |
|||
The Async Chain of Persistence Pattern guarantees that no message is ever lost by ensuring that the message is always persistently stored at every step of the workflow. This is where the pattern gets its name. A message cannot be removed from its previous location until it is confirmed to be persistently stored in the subsequent stages of the chain. |
|||
|
|||
It is commonly used in event-driven systems and message-driven systems. |
|||
|
|||
### Event-Driven versus Message-Driven Systems |
|||
To understand the pattern, it's important to know the differences between events and messages. |
|||
|
|||
#### The Core Difference |
|||
|
|||
**Event:** Says "something happened", describes the past. Example: `OrderPlaced`, `PaymentCompleted` |
|||
|
|||
**Message:** Says "do this", commands for the future. Example: `CreateOrder`, `SendEmail` |
|||
|
|||
| Property | Event | Message | |
|||
|----------|-------|---------| |
|||
| **Coupling** | Loose - no one knows who's listening | Tighter - there's a specific receiver | |
|||
| **Publishing** | Pub/Sub - 0-N services listen | Point-to-Point - usually 1 service | |
|||
| **Tense** | Past tense, immutable | Present/future tense | |
|||
| **Error Handling** | If one consumer fails, others continue | If not processed, system breaks | |
|||
|
|||
|
|||
### Relationship with Async Chain of Persistence |
|||
|
|||
**In event-driven systems:** Each service receives the event → persists it → publishes a new event |
|||
|
|||
 |
|||
|
|||
**In message-driven systems:** At each step, the message is kept safe on queue + disk |
|||
|
|||
In both systems, the goal is the same: no message should be lost! |
|||
|
|||
 |
|||
|
|||
--- |
|||
|
|||
## When Do Messages Get Lost? |
|||
There are 3 main scenarios for message loss: |
|||
|
|||
### 1. While Processing a Message (Receiving a Message) |
|||
While processing a message in a reply, by default, there is an automatic acknowledgment and subsequent deletion of a message that is in a queue. But in cases where there is a fatal or unrecoverable error in the message processing operation or a service instance crashes, this message gets lost. |
|||
|
|||
### 2. Message Broker Crashes |
|||
In the majority of message brokers, the default option for the message persistence state is set to nonpersisting. In other words, the message will be held in the memory of the message broker without any persistence. It has been used for the purpose of obtaining rapid responses and improved throughput. However, in the event of failure of the message broker process, the nonpersistent message will be lost permanently. |
|||
|
|||
### 3. Event Chaining |
|||
In event-driven systems, an event is published as a derived message after an operation is done by a service. Message loss in two ways is possible in this scenario: |
|||
1. **Risk of Asynchronous Send:** The publish operation is often carried out using the asynchronous send feature. When a fatal error takes place prior to the receipt of acknowledgment of the message publish operation by the publish services, it becomes difficult to determine if the message has been successfully transmitted to the message broker. |
|||
2. **Transaction Coordination:** In case an error is detected after the commit of the database but before the derived event is published, the derived event might be lost. |
|||
|
|||
## Implementing the Pattern: 4 Critical Steps |
|||
Four critical steps are required to implement the Async Chain of Persistence Pattern: |
|||
|
|||
### 1. Message Persistence |
|||
The initial step to ensure that there are no lost messages is to specify the messages as PERSISTENT: When the message broker receives the message, it is saved on disk. |
|||
|
|||
```javascript |
|||
var delivery_mode = PERSISTENT |
|||
var producer = create_producer(delivery_mode) |
|||
|
|||
// All sent messages are persisted on the message broker |
|||
producer.send_message(APPLY_PAYMENT) |
|||
|
|||
// Alternatively |
|||
var delivery_mode = PERSISTENT |
|||
var producer = create_producer() |
|||
producer.send_message(APPLY_PAYMENT, delivery_mode) |
|||
``` |
|||
With this approach, even if the message broker crashes, all messages will still be there when it comes back up. |
|||
|
|||
### 2. Client Acknowledgement Mode |
|||
Instead, client-acknowledgement mode needs to be employed. When a message is received in this mode, that message will be retained in the queue until a proper acknowledgment from the processing service has been made. Instead of "auto acknowledge" mode, "client-acknowledgement" mode |
|||
|
|||
Client acknowledgement mode ensures that the message is not lost while processing by the service. When a fatal error is detected during message processing, the service exits without sending an acknowledgement message and thus results in a message redispatched. |
|||
|
|||
**Important Note:** The message has to be acknowledged while the message processing operation is completed so that a repeat message will not be processed. |
|||
|
|||
### 3. Synchronous Send |
|||
The synchronous send must be preferred over the asynchronous send. |
|||
|
|||
Although it takes longer to send via synchronous send, since it's a blocking call, it ensures that the message broker received and persisted the message on disk. |
|||
|
|||
```javascript |
|||
// Blocking call to publish the derived event |
|||
var ack = publish_event(PAYMENT_APPLIED) |
|||
if (ack not_successful) { |
|||
retry_or_persist(PAYMENT_APPLIED) |
|||
} |
|||
``` |
|||
With this approach, the risk of message loss during event chaining is eliminated. |
|||
|
|||
### 4. Last Participant Support |
|||
This is the most complex step of the Async Chain of Persistence pattern. It determines when the message should be acknowledged. |
|||
|
|||
#### For Message-Driven Systems: |
|||
```javascript |
|||
var message = receive_message() |
|||
process_message(message) |
|||
database.commit() |
|||
message.acknowledge() |
|||
``` |
|||
Recommended order: **commit first, ack last.** Otherwise, if the database operation fails, the message will be lost because it has already been removed from the queue. |
|||
|
|||
#### For Event-Driven Systems |
|||
In event-driven systems, there are two distinct parties involved: one that acknowledges an event and another that publishes the event that’s been derived. The party that publishes the event that’s been derived should be treated as “last participant.” |
|||
```javascript |
|||
var event = receive_event() |
|||
process_event(event) |
|||
database.commit() |
|||
message.acknowledge() |
|||
|
|||
var ack = publish_event(PAYMENT_APPLIED) |
|||
if (ack not_successful) { |
|||
retry_or_persist(PAYMENT_APPLIED) |
|||
} |
|||
``` |
|||
In this sequence, the original event is acknowledged after it is completed. If publishing the derived event fails, it can be retried or persisted for later delivery. |
|||
|
|||
--- |
|||
|
|||
## Trade-offs |
|||
|
|||
### Advantages |
|||
|
|||
**Preventing Message Loss:** |
|||
The major benefit of this pattern is that it doesn't let a message get lost while messages are under processing. This issue, being a serious concern in asynchronous systems, is ruled out due to the pattern. |
|||
|
|||
### Disadvantages |
|||
|
|||
#### 1. Possible Duplicate Messages |
|||
Enabling the client-acknowledgement mode can result in the processing of the same message multiple times. If the service instance fails after the database commit but before the message could be acknowledged, the message will be repeated and duplicates can be processed. |
|||
|
|||
**Solution:** In order to determine whether the arriving messages are previously processed or not, the message IDs can be logged and traced back. This also has the drawback of requiring one extra read operation per message in the system. |
|||
|
|||
#### 2. Performance and Throughput |
|||
It has also been noted that the time duration in which the persistent message takes to be sent from the message broker could be **up to four times longer** than in the nonpersistent message transmission. |
|||
|
|||
Persisted messages also affect performance in terms of sending and reading the message. It is also common for message brokers to maintain message data in their memory for efficient reading, but there is no assurance that messages will always be resident in memory, depending on memory size, among other factors. |
|||
|
|||
#### 3. Impact of Synchronous Send |
|||
Because a synchronous send makes a blocking call until a confirmation is received, there is no other work that can be accomplished before a confirmation is received from the broker for a synchronous send. A persisted message makes this even more apparent. |
|||
|
|||
#### 4. Overall Scalability |
|||
This is because, upon receipt, the message broker has to spend more time persisting messages to disk, thus negatively affecting scalability. Persistent messages always give lower total throughput, which can limit scalability under high usage loads and high message volumes. |
|||
|
|||
--- |
|||
|
|||
## Conclusion |
|||
|
|||
The Async Chain of Persistence Pattern provides a powerful solution for preventing message loss. Although it has negative effects on performance, throughput, and scalability, these trade-offs are generally acceptable in systems where data loss is critical. |
|||
|
|||
Before implementing the pattern, carefully analyze your system requirements: |
|||
|
|||
- **How critical is message loss?** |
|||
- **What are the performance and throughput requirements?** |
|||
- **How should the system behave in case of duplicate processing?** |
|||
|
|||
The answers to these questions will help you determine whether the Async Chain of Persistence Pattern is suitable for your system. |
|||
|
|||
## Sample Project |
|||
|
|||
To see an example project where this pattern is implemented, you can check out the repository: |
|||
|
|||
🔗 **[GitHub Repository](https://github.com/fahrigedik/SoftwareArchitecturePatterns)** |
|||
|
After Width: | Height: | Size: 29 KiB |
|
After Width: | Height: | Size: 13 KiB |
@ -0,0 +1,17 @@ |
|||
We are thrilled to announce that **ABP.IO will be sponsoring [NDC London 2026](https://ndclondon.com/),** making the start of 2026 a very exciting time for us\! |
|||
|
|||
NDC London is going to take place from **26th-30th January 2026 at Queen Elizabeth II Center.** This 5-Day event for software developers will have over 90 speakers and 100 sessions. We are excited to be a part of this amazing event once more as devoted supporters of the software development community\! |
|||
|
|||
## Conference Tracks, Topics, and What Developers Can Expect |
|||
|
|||
Developers attending **NDC London 2026** can expect five focused tracks packed with practical, real-world sessions. The conference covers the modern development stack, including **.NET, JavaScript, Cloud, DevOps, Security, Testing, UX, Web**, and emerging technologies, delivered by industry experts with actionable insights developers can apply immediately. |
|||
|
|||
## Discover Previous NDC Events |
|||
|
|||
We have shared **our takeaways from past NDC events** and other conferences [**here**](https://abp.io/community/events/sponsored#gsc.tab=0). You can check them out to learn what we discovered along the way\! |
|||
|
|||
## Stop By Our Booth and Say Hello |
|||
|
|||
We can’t wait to meet fellow developers at NDC London 2026, have meaningful conversations and connect in person. **If you are stopping by our booth, don’t miss our raffle\!** We will be giving away a nice surprise during the event\! |
|||
|
|||
We are looking forward to meeting you there and sharing a few great days focused on software development. See you there\! |
|||
|
After Width: | Height: | Size: 60 KiB |
|
After Width: | Height: | Size: 269 KiB |
@ -0,0 +1,153 @@ |
|||
# Which Open-Source PDF Libraries Are Recently Popular ? A Data-Driven Look At PDF Topic |
|||
|
|||
So you're looking for a PDF library in .NET, right? Here's the thing - just because something has a million downloads doesn't mean it's what you should use *today*. I'm looking at **recent download momentum** (how many people are actually using it NOW via NuGet) and **GitHub activity** (are they still maintaining this thing or did they abandon it?). |
|||
|
|||
I pulled data from the last ~90 days for the main players in the .NET PDF space. Here's what's actually happening: |
|||
|
|||
## Popularity Comparison of .NET PDF Libraries (*ordered by score*) |
|||
|
|||
| Library | GitHub Stars | Avg Daily NuGet Downloads | Total NuGet Downloads | **Popularity Score** | |
|||
|---------|---------------|-----------------------------|----------------------------|---------------------| |
|||
| **[Microsoft.Playwright](https://github.com/microsoft/playwright-dotnet)** | [2.9k](https://github.com/microsoft/playwright-dotnet) | [23k](https://www.nuget.org/packages/Microsoft.Playwright) | 39M | **71/100** | |
|||
| **[QuestPDF](https://github.com/QuestPDF/QuestPDF)** | [13.7k](https://github.com/QuestPDF/QuestPDF) | [8.2k](https://www.nuget.org/packages/QuestPDF) | 15M | **54/100** | |
|||
| **[PDFsharp](https://github.com/empira/PDFsharp)** | [862](https://github.com/empira/PDFsharp) | [9k](https://www.nuget.org/packages/PdfSharp) | 47M | **48/100** | |
|||
| **[iText](https://github.com/itext/itext-dotnet)** | [1.9k](https://github.com/itext/itext-dotnet) | [17.2k](https://www.nuget.org/packages/itext) | 16M | **44/100** | |
|||
| **[PuppeteerSharp](https://github.com/hardkoded/puppeteer-sharp)** | [3.8k](https://github.com/hardkoded/puppeteer-sharp) | [8.7k](https://www.nuget.org/packages/PuppeteerSharp) | 26M | **40/100** | |
|||
|
|||
**How I calculated the score:** I weighted GitHub Stars (30%), Daily Downloads (40% - because that's what matters NOW), and Total Downloads (30% - for historical context). Everything normalized to 0-100 before weighting. Higher = better momentum overall. |
|||
|
|||
## The Breakdown - What You Actually Need to Know |
|||
|
|||
### [PDFsharp](https://docs.pdfsharp.net/) |
|||
|
|||
 |
|||
|
|||
**NuGet:** [PdfSharp](https://www.nuget.org/packages/PdfSharp) | **GitHub:** [empira/PDFsharp](https://github.com/empira/PDFsharp) |
|||
|
|||
**What it does:** Code-first PDF stuff - drawing, manipulating, merging, that kind of thing. Not for HTML/browser rendering though, so don't try to convert your React app to PDF with this. |
|||
|
|||
**What's the vibe?** **Stable, but kinda old school.** It's got the biggest total download count (47M!) but only pulling ~9k/day now. They updated it 2 weeks ago (Jan 6) so it's alive, and it supports .NET 8-10 which is nice. The GitHub stars (862) are pretty low compared to the shiny new kids, but honestly? It's been around forever and people still use it. It's the reliable old workhorse. |
|||
|
|||
**Pick this if:** |
|||
- You need to build PDFs from scratch with code (not HTML) |
|||
- You want to draw graphics, manipulate existing PDFs, merge files |
|||
- You don't want browser engines anywhere near your project |
|||
|
|||
--- |
|||
|
|||
### [iText](https://itextpdf.com/) |
|||
|
|||
 |
|||
|
|||
**NuGet:** [itext](https://www.nuget.org/packages/itext/) | **GitHub:** [itext/itext-dotnet](https://github.com/itext/itext-dotnet) |
|||
|
|||
**What it does:** The enterprise beast. Digital signatures, PDF compliance (PDF/A, PDF/UA), forms, all that fancy stuff. Can do HTML-to-PDF too if you need it. |
|||
|
|||
**What's the vibe?** **Actually doing pretty well!** ~17.2k downloads/day (highest for code-first libs), updated literally yesterday (Jan 18). They're moving fast. 1.9k stars isn't huge but the community seems active. The catch? This is the enterprise option - check the licensing before you commit if you're doing commercial work. |
|||
|
|||
**Pick this if:** |
|||
- You need digital signatures, PDF compliance, or advanced form stuff |
|||
- Your company is cool with licensing fees (or you're doing open source) |
|||
- You need serious PDF manipulation features |
|||
- You want HTML-to-PDF AND code-based generation in one package |
|||
|
|||
--- |
|||
|
|||
### [Microsoft.Playwright](https://playwright.dev/dotnet/) |
|||
|
|||
 |
|||
|
|||
**NuGet:** [Microsoft.Playwright](https://www.nuget.org/packages/Microsoft.Playwright) | **GitHub:** [microsoft/playwright-dotnet](https://github.com/microsoft/playwright-dotnet) |
|||
|
|||
**What it does:** Browser automation that can turn HTML/CSS/JS into PDFs. Uses real browser engines (Chromium, WebKit, Firefox) so your PDFs look exactly like they would in a browser. |
|||
|
|||
**What's the vibe?** **Killing it.** ~23k downloads/day (highest in this whole list!). It's Microsoft-backed so you know they're not gonna abandon it anytime soon. Last commit was December 3rd but honestly that's fine, they're actively maintaining. 2.9k stars and climbing. If you need to turn web pages into PDFs, this is probably your best bet right now. |
|||
|
|||
**Pick this if:** |
|||
- You need to convert HTML/CSS/JS to PDF and want it to look EXACTLY like the browser |
|||
- You're working with SPAs, dynamic content, or web templates |
|||
- You also need browser automation/testing (bonus!) |
|||
- Layout accuracy is critical (forms, dashboards, etc.) |
|||
|
|||
--- |
|||
|
|||
### [PuppeteerSharp](https://www.puppeteersharp.com/) |
|||
|
|||
 |
|||
|
|||
**NuGet:** [PuppeteerSharp](https://www.nuget.org/packages/PuppeteerSharp) | **GitHub:** [hardkoded/puppeteer-sharp](https://github.com/hardkoded/puppeteer-sharp) |
|||
|
|||
**What it does:** Basically Playwright's older sibling. Uses headless Chromium to turn HTML into PDFs. Same idea, different API. |
|||
|
|||
**What's the vibe?** **Stable but losing ground.** Got updated last week (Jan 12) so it's maintained, but ~8.7k/day is way less than Playwright's ~23k. 3.8k stars is decent though. It works fine, but Playwright is eating its lunch. Still, if you know Puppeteer already or only need Chromium, this might be fine. |
|||
|
|||
**Pick this if:** |
|||
- You already know Puppeteer from Node.js and want the same vibe in .NET |
|||
- You only need Chromium (don't care about Firefox/WebKit) |
|||
- You have existing Puppeteer code you're porting |
|||
|
|||
--- |
|||
|
|||
|
|||
|
|||
### [QuestPDF](https://github.com/QuestPDF/QuestPDF) |
|||
|
|||
 |
|||
|
|||
**NuGet:** [QuestPDF](https://www.nuget.org/packages/QuestPDF) | **GitHub:** [QuestPDF/QuestPDF](https://github.com/QuestPDF/QuestPDF) |
|||
|
|||
**What it does:** Build PDFs with fluent C# APIs. Think of it like building a UI layout, but for PDFs. No HTML needed - it's all code, all .NET. |
|||
|
|||
**What's the vibe?** **The community favorite.** 13.7k stars (most by far!), updated yesterday (Jan 18). ~8.2k downloads/day isn't the highest but the community is clearly excited about it. Modern API, active dev, people seem to actually enjoy using it. If you're building reports/invoices from code and want something that feels modern, this is it. |
|||
|
|||
**Pick this if:** |
|||
- You want to build PDFs with code (not HTML) and you like fluent APIs |
|||
- You're generating reports, invoices, structured documents |
|||
- You want zero browser dependencies |
|||
- You care about type safety and maintainable code |
|||
- You want something that feels modern and well-designed |
|||
|
|||
|
|||
|
|||
## Who's Winning Right Now? |
|||
|
|||
Here's what the numbers are telling us: |
|||
|
|||
### Code-First Libraries (Building PDFs with Code) |
|||
|
|||
**[QuestPDF](https://github.com/QuestPDF/QuestPDF)** - Score: 54/100 |
|||
The people's choice. Most GitHub stars (13.7k), updated yesterday, community loves it. Downloads aren't the highest but the engagement is real. This is what people are excited about. |
|||
|
|||
**[iText](https://github.com/itext/itext-dotnet)** - Score: 44/100 |
|||
Actually pulling the most daily downloads (~17.2k/day) for code-first libs, also updated yesterday. The enterprise crowd is still using this heavily. Just watch that licensing. |
|||
|
|||
**[PDFsharp](https://github.com/empira/PDFsharp)** - Score: 48/100 |
|||
The old reliable. 47M total downloads but only ~9k/day now. It works, it's stable, but it's not where the momentum is. Still a solid choice if you need something battle-tested. |
|||
|
|||
### HTML/Browser-Based Libraries (Turning Web Pages into PDFs) |
|||
|
|||
**[Microsoft.Playwright](https://github.com/microsoft/playwright-dotnet)** - Score: 71/100 |
|||
Winner winner. ~23k downloads/day (highest overall), Microsoft backing, actively maintained. If you need HTML-to-PDF, this is probably the move. |
|||
|
|||
**[PuppeteerSharp](https://github.com/hardkoded/puppeteer-sharp)** - Score: 40/100 |
|||
Still kicking around at ~8.7k/day but Playwright is clearly the future. Updated last week so it's not dead, just... less popular. |
|||
|
|||
|
|||
|
|||
## TL;DR - What Should You Actually Use? |
|||
|
|||
**Building PDFs from code (not HTML):** |
|||
- **QuestPDF** - If you want something modern and the community is raving about it (13.7k stars!) |
|||
- **iText** - If you need enterprise features and can handle the licensing |
|||
- **PDFsharp** - If you want the battle-tested option that's been around forever |
|||
|
|||
**Converting HTML/web pages to PDF:** |
|||
- **Playwright** - Just use this. It's winning right now (~23k/day), Microsoft-backed, actively maintained. Game over. |
|||
- **PuppeteerSharp** - Only if you really need Chromium-only or you're migrating from Node.js Puppeteer |
|||
|
|||
**Bottom line:** For HTML-to-PDF, Playwright is dominating. For code-first, QuestPDF has the hype but iText has the downloads. Choose your fighter. |
|||
|
|||
--- |
|||
|
|||
*Numbers from GitHub and NuGet as of January 19, 2026. Daily downloads are from the last 90 days.* |
|||
|
|||
|
After Width: | Height: | Size: 494 KiB |
|
After Width: | Height: | Size: 72 KiB |
|
After Width: | Height: | Size: 8.9 KiB |
|
After Width: | Height: | Size: 22 KiB |
@ -0,0 +1,189 @@ |
|||
```json |
|||
//[doc-seo] |
|||
{ |
|||
"Description": "Learn how to add expandable row details to data tables using the Extensible Table Row Detail component in ABP Framework Angular UI." |
|||
} |
|||
``` |
|||
|
|||
# Extensible Table Row Detail for Angular UI |
|||
|
|||
## Introduction |
|||
|
|||
The `<abp-extensible-table-row-detail>` component allows you to add expandable row details to any `<abp-extensible-table>`. When users click the expand icon, additional content is revealed below the row. |
|||
|
|||
<img alt="Extensible Table Row Detail Example" src="./images/row-detail-image.png" width="800px" style="max-width:100%"> |
|||
|
|||
## Quick Start |
|||
|
|||
### Step 1. Import the Component |
|||
|
|||
Import `ExtensibleTableRowDetailComponent` in your component: |
|||
|
|||
```typescript |
|||
import { |
|||
ExtensibleTableComponent, |
|||
ExtensibleTableRowDetailComponent |
|||
} from '@abp/ng.components/extensible'; |
|||
|
|||
@Component({ |
|||
// ... |
|||
imports: [ |
|||
ExtensibleTableComponent, |
|||
ExtensibleTableRowDetailComponent, |
|||
], |
|||
}) |
|||
export class MyComponent { } |
|||
``` |
|||
|
|||
### Step 2. Add Row Detail Template |
|||
|
|||
Place `<abp-extensible-table-row-detail>` inside `<abp-extensible-table>` with an `ng-template`: |
|||
|
|||
```html |
|||
<abp-extensible-table [data]="data.items" [recordsTotal]="data.totalCount" [list]="list"> |
|||
<abp-extensible-table-row-detail> |
|||
<ng-template let-row="row" let-expanded="expanded"> |
|||
<div class="p-3"> |
|||
<h5>{%{{{ row.name }}}%}</h5> |
|||
<p>ID: {%{{{ row.id }}}%}</p> |
|||
<p>Status: {%{{{ row.isActive ? 'Active' : 'Inactive' }}}%}</p> |
|||
</div> |
|||
</ng-template> |
|||
</abp-extensible-table-row-detail> |
|||
</abp-extensible-table> |
|||
``` |
|||
|
|||
An expand/collapse chevron icon will automatically appear in the first column of each row. |
|||
|
|||
## API |
|||
|
|||
### ExtensibleTableRowDetailComponent |
|||
|
|||
| Input | Type | Default | Description | |
|||
|-------|------|---------|-------------| |
|||
| `rowHeight` | `string` | `number` | `'100%'` | Height of the expanded row detail area | |
|||
|
|||
### Template Context Variables |
|||
|
|||
| Variable | Type | Description | |
|||
|----------|------|-------------| |
|||
| `row` | `R` | The current row data object | |
|||
| `expanded` | `boolean` | Whether the row is currently expanded | |
|||
|
|||
## Usage Examples |
|||
|
|||
### Basic Example |
|||
|
|||
Display additional information when a row is expanded: |
|||
|
|||
```html |
|||
<abp-extensible-table [data]="data.items" [list]="list"> |
|||
<abp-extensible-table-row-detail> |
|||
<ng-template let-row="row"> |
|||
<div class="p-3 border rounded m-2"> |
|||
<strong>Details for: {%{{{ row.name }}}%}</strong> |
|||
<pre>{%{{{ row | json }}}%}</pre> |
|||
</div> |
|||
</ng-template> |
|||
</abp-extensible-table-row-detail> |
|||
</abp-extensible-table> |
|||
``` |
|||
|
|||
### With Custom Row Height |
|||
|
|||
Specify a fixed height for the detail area: |
|||
|
|||
```html |
|||
<abp-extensible-table-row-detail [rowHeight]="200"> |
|||
<ng-template let-row="row"> |
|||
<div class="p-3">Fixed 200px height content</div> |
|||
</ng-template> |
|||
</abp-extensible-table-row-detail> |
|||
``` |
|||
|
|||
### Using Expanded State |
|||
|
|||
Apply conditional styling based on expansion state: |
|||
|
|||
```html |
|||
<abp-extensible-table-row-detail> |
|||
<ng-template let-row="row" let-expanded="expanded"> |
|||
<div class="p-3" [class.fade-in]="expanded"> |
|||
<p>This row is {%{{{ expanded ? 'expanded' : 'collapsed' }}}%}</p> |
|||
</div> |
|||
</ng-template> |
|||
</abp-extensible-table-row-detail> |
|||
``` |
|||
|
|||
### With Badges and Localization |
|||
|
|||
```html |
|||
<abp-extensible-table-row-detail> |
|||
<ng-template let-row="row"> |
|||
<div class="p-3 bg-light border rounded m-2"> |
|||
<div class="row"> |
|||
<div class="col-md-6"> |
|||
<p class="mb-1"><strong>{%{{{ 'MyModule::Name' | abpLocalization }}}%}</strong></p> |
|||
<p class="text-muted">{%{{{ row.name }}}%}</p> |
|||
</div> |
|||
<div class="col-md-6"> |
|||
<p class="mb-1"><strong>{%{{{ 'MyModule::Status' | abpLocalization }}}%}</strong></p> |
|||
<p> |
|||
@if (row.isActive) { |
|||
<span class="badge bg-success">{%{{{ 'AbpUi::Yes' | abpLocalization }}}%}</span> |
|||
} @else { |
|||
<span class="badge bg-secondary">{%{{{ 'AbpUi::No' | abpLocalization }}}%}</span> |
|||
} |
|||
</p> |
|||
</div> |
|||
</div> |
|||
</div> |
|||
</ng-template> |
|||
</abp-extensible-table-row-detail> |
|||
``` |
|||
|
|||
## Alternative: Direct Template Input |
|||
|
|||
For simpler use cases, you can use the `rowDetailTemplate` input on `<abp-extensible-table>` directly: |
|||
|
|||
```html |
|||
<abp-extensible-table |
|||
[data]="data.items" |
|||
[list]="list" |
|||
[rowDetailTemplate]="detailTemplate" |
|||
/> |
|||
|
|||
<ng-template #detailTemplate let-row="row"> |
|||
<div class="p-3">{%{{{ row.name }}}%}</div> |
|||
</ng-template> |
|||
``` |
|||
|
|||
## Events |
|||
|
|||
### rowDetailToggle |
|||
|
|||
The `rowDetailToggle` output emits when a row is expanded or collapsed: |
|||
|
|||
```html |
|||
<abp-extensible-table |
|||
[data]="data.items" |
|||
[list]="list" |
|||
(rowDetailToggle)="onRowToggle($event)" |
|||
> |
|||
<abp-extensible-table-row-detail> |
|||
<ng-template let-row="row">...</ng-template> |
|||
</abp-extensible-table-row-detail> |
|||
</abp-extensible-table> |
|||
``` |
|||
|
|||
```typescript |
|||
onRowToggle(row: MyDto) { |
|||
console.log('Row toggled:', row); |
|||
} |
|||
``` |
|||
|
|||
## See Also |
|||
|
|||
- [Data Table Column Extensions](data-table-column-extensions.md) |
|||
- [Entity Action Extensions](entity-action-extensions.md) |
|||
- [Extensions Overview](extensions-overall.md) |
|||
|
After Width: | Height: | Size: 7.1 KiB |
|
After Width: | Height: | Size: 18 KiB |
@ -1,86 +1,16 @@ |
|||
using System; |
|||
using System.Threading.Tasks; |
|||
using Duende.IdentityModel.Client; |
|||
using Microsoft.AspNetCore.Authentication.OpenIdConnect; |
|||
using Microsoft.Extensions.DependencyInjection; |
|||
using Microsoft.Extensions.Logging; |
|||
using Microsoft.Extensions.Options; |
|||
using Volo.Abp.Threading; |
|||
|
|||
namespace Microsoft.AspNetCore.Authentication.Cookies; |
|||
|
|||
public static class CookieAuthenticationOptionsExtensions |
|||
{ |
|||
/// <summary>
|
|||
/// Introspect access token on validating the principal.
|
|||
/// Check the access_token is expired or inactive.
|
|||
/// </summary>
|
|||
/// <param name="options"></param>
|
|||
/// <param name="oidcAuthenticationScheme"></param>
|
|||
/// <returns></returns>
|
|||
[Obsolete("Use CheckTokenExpiration method instead.")] |
|||
public static CookieAuthenticationOptions IntrospectAccessToken(this CookieAuthenticationOptions options, string oidcAuthenticationScheme = "oidc") |
|||
{ |
|||
options.Events.OnValidatePrincipal = async principalContext => |
|||
{ |
|||
if (principalContext.Principal == null || principalContext.Principal.Identity == null || !principalContext.Principal.Identity.IsAuthenticated) |
|||
{ |
|||
return; |
|||
} |
|||
|
|||
var logger = principalContext.HttpContext.RequestServices.GetRequiredService<ILogger<CookieAuthenticationOptions>>(); |
|||
|
|||
var accessToken = principalContext.Properties.GetTokenValue("access_token"); |
|||
if (!accessToken.IsNullOrWhiteSpace()) |
|||
{ |
|||
var openIdConnectOptions = await GetOpenIdConnectOptions(principalContext, oidcAuthenticationScheme); |
|||
var response = await openIdConnectOptions.Backchannel.IntrospectTokenAsync(new TokenIntrospectionRequest |
|||
{ |
|||
Address = openIdConnectOptions.Configuration?.IntrospectionEndpoint ?? openIdConnectOptions.Authority!.EnsureEndsWith('/') + "connect/introspect", |
|||
ClientId = openIdConnectOptions.ClientId!, |
|||
ClientSecret = openIdConnectOptions.ClientSecret, |
|||
Token = accessToken |
|||
}); |
|||
|
|||
if (response.IsError) |
|||
{ |
|||
logger.LogError(response.Error); |
|||
await SignOutAsync(principalContext); |
|||
return; |
|||
} |
|||
|
|||
if (!response.IsActive) |
|||
{ |
|||
logger.LogError("The access_token is not active."); |
|||
await SignOutAsync(principalContext); |
|||
return; |
|||
} |
|||
|
|||
logger.LogInformation("The access_token is active."); |
|||
} |
|||
else |
|||
{ |
|||
logger.LogError("The access_token is not found in the cookie properties, Please make sure SaveTokens of OpenIdConnectOptions is set as true."); |
|||
await SignOutAsync(principalContext); |
|||
} |
|||
}; |
|||
|
|||
return options; |
|||
} |
|||
|
|||
private async static Task<OpenIdConnectOptions> GetOpenIdConnectOptions(CookieValidatePrincipalContext principalContext, string oidcAuthenticationScheme) |
|||
{ |
|||
var openIdConnectOptions = principalContext.HttpContext.RequestServices.GetRequiredService<IOptionsMonitor<OpenIdConnectOptions>>().Get(oidcAuthenticationScheme); |
|||
if (openIdConnectOptions.Configuration == null && openIdConnectOptions.ConfigurationManager != null) |
|||
{ |
|||
var cancellationTokenProvider = principalContext.HttpContext.RequestServices.GetRequiredService<ICancellationTokenProvider>(); |
|||
openIdConnectOptions.Configuration = await openIdConnectOptions.ConfigurationManager.GetConfigurationAsync(cancellationTokenProvider.Token); |
|||
} |
|||
|
|||
return openIdConnectOptions; |
|||
} |
|||
|
|||
private async static Task SignOutAsync(CookieValidatePrincipalContext principalContext) |
|||
{ |
|||
principalContext.RejectPrincipal(); |
|||
await principalContext.HttpContext.SignOutAsync(principalContext.Scheme.Name); |
|||
return options.CheckTokenExpiration(oidcAuthenticationScheme, null, TimeSpan.FromMinutes(1)); |
|||
} |
|||
} |
|||
|
|||
@ -0,0 +1,55 @@ |
|||
using System.Linq; |
|||
using System.Threading.Tasks; |
|||
using Volo.Abp.MultiTenancy; |
|||
using Volo.Abp.Security.Claims; |
|||
|
|||
namespace Volo.Abp.Authorization.Permissions.Resources; |
|||
|
|||
public class ClientResourcePermissionValueProvider : ResourcePermissionValueProvider |
|||
{ |
|||
public const string ProviderName = "C"; |
|||
|
|||
public override string Name => ProviderName; |
|||
|
|||
protected ICurrentTenant CurrentTenant { get; } |
|||
|
|||
public ClientResourcePermissionValueProvider(IResourcePermissionStore resourcePermissionStore, ICurrentTenant currentTenant) |
|||
: base(resourcePermissionStore) |
|||
{ |
|||
CurrentTenant = currentTenant; |
|||
} |
|||
|
|||
public override async Task<PermissionGrantResult> CheckAsync(ResourcePermissionValueCheckContext context) |
|||
{ |
|||
var clientId = context.Principal?.FindFirst(AbpClaimTypes.ClientId)?.Value; |
|||
|
|||
if (clientId == null) |
|||
{ |
|||
return PermissionGrantResult.Undefined; |
|||
} |
|||
|
|||
using (CurrentTenant.Change(null)) |
|||
{ |
|||
return await ResourcePermissionStore.IsGrantedAsync(context.Permission.Name, context.ResourceName, context.ResourceKey, Name, clientId) |
|||
? PermissionGrantResult.Granted |
|||
: PermissionGrantResult.Undefined; |
|||
} |
|||
} |
|||
|
|||
public override async Task<MultiplePermissionGrantResult> CheckAsync(ResourcePermissionValuesCheckContext context) |
|||
{ |
|||
var permissionNames = context.Permissions.Select(x => x.Name).Distinct().ToArray(); |
|||
Check.NotNullOrEmpty(permissionNames, nameof(permissionNames)); |
|||
|
|||
var clientId = context.Principal?.FindFirst(AbpClaimTypes.ClientId)?.Value; |
|||
if (clientId == null) |
|||
{ |
|||
return new MultiplePermissionGrantResult(permissionNames); |
|||
} |
|||
|
|||
using (CurrentTenant.Change(null)) |
|||
{ |
|||
return await ResourcePermissionStore.IsGrantedAsync(permissionNames, context.ResourceName, context.ResourceKey, Name, clientId); |
|||
} |
|||
} |
|||
} |
|||
@ -1,84 +1,43 @@ |
|||
using System; |
|||
using System.Globalization; |
|||
using System.Linq; |
|||
using System.Text.Json; |
|||
using System.Text.Json.Serialization; |
|||
using Microsoft.Extensions.Options; |
|||
using Volo.Abp.DependencyInjection; |
|||
using Volo.Abp.Timing; |
|||
|
|||
namespace Volo.Abp.Json.SystemTextJson.JsonConverters; |
|||
|
|||
public class AbpDateTimeConverter : JsonConverter<DateTime>, ITransientDependency |
|||
public class AbpDateTimeConverter : AbpDateTimeConverterBase<DateTime>, ITransientDependency |
|||
{ |
|||
private readonly IClock _clock; |
|||
private readonly AbpJsonOptions _options; |
|||
private bool _skipDateTimeNormalization; |
|||
|
|||
public AbpDateTimeConverter(IClock clock, IOptions<AbpJsonOptions> abpJsonOptions) |
|||
public AbpDateTimeConverter( |
|||
IClock clock, |
|||
IOptions<AbpJsonOptions> abpJsonOptions, |
|||
ICurrentTimezoneProvider currentTimezoneProvider, |
|||
ITimezoneProvider timezoneProvider) |
|||
: base(clock, abpJsonOptions, currentTimezoneProvider, timezoneProvider) |
|||
{ |
|||
_clock = clock; |
|||
_options = abpJsonOptions.Value; |
|||
} |
|||
|
|||
public virtual AbpDateTimeConverter SkipDateTimeNormalization() |
|||
{ |
|||
_skipDateTimeNormalization = true; |
|||
IsSkipDateTimeNormalization = true; |
|||
return this; |
|||
} |
|||
|
|||
public override DateTime Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options) |
|||
{ |
|||
if (_options.InputDateTimeFormats.Any()) |
|||
{ |
|||
if (reader.TokenType == JsonTokenType.String) |
|||
{ |
|||
foreach (var format in _options.InputDateTimeFormats) |
|||
{ |
|||
var s = reader.GetString(); |
|||
if (DateTime.TryParseExact(s, format, CultureInfo.CurrentUICulture, DateTimeStyles.None, out var d1)) |
|||
{ |
|||
return Normalize(d1); |
|||
} |
|||
} |
|||
} |
|||
else |
|||
{ |
|||
throw new JsonException("Reader's TokenType is not String!"); |
|||
} |
|||
} |
|||
|
|||
if (reader.TryGetDateTime(out var d3)) |
|||
{ |
|||
return Normalize(d3); |
|||
} |
|||
|
|||
var dateText = reader.GetString(); |
|||
if (!dateText.IsNullOrWhiteSpace()) |
|||
if (Options.InputDateTimeFormats.Any() && reader.TokenType != JsonTokenType.String) |
|||
{ |
|||
if (DateTime.TryParse(dateText, CultureInfo.CurrentUICulture, DateTimeStyles.None, out var d4)) |
|||
{ |
|||
return Normalize(d4); |
|||
} |
|||
throw new JsonException("Reader's TokenType is not String!"); |
|||
} |
|||
|
|||
throw new JsonException("Can't get datetime from the reader!"); |
|||
return TryReadDateTime(ref reader, out var result) |
|||
? result |
|||
: throw new JsonException("Can't get datetime from the reader!"); |
|||
} |
|||
|
|||
public override void Write(Utf8JsonWriter writer, DateTime value, JsonSerializerOptions options) |
|||
{ |
|||
if (_options.OutputDateTimeFormat.IsNullOrWhiteSpace()) |
|||
{ |
|||
writer.WriteStringValue(Normalize(value)); |
|||
} |
|||
else |
|||
{ |
|||
writer.WriteStringValue(Normalize(value).ToString(_options.OutputDateTimeFormat, CultureInfo.CurrentUICulture)); |
|||
} |
|||
} |
|||
|
|||
protected virtual DateTime Normalize(DateTime dateTime) |
|||
{ |
|||
return _skipDateTimeNormalization ? dateTime : _clock.Normalize(dateTime); |
|||
WriteDateTime(writer, value); |
|||
} |
|||
} |
|||
|
|||
@ -0,0 +1,116 @@ |
|||
using System; |
|||
using System.Globalization; |
|||
using System.Linq; |
|||
using System.Text.Json; |
|||
using System.Text.Json.Serialization; |
|||
using Microsoft.Extensions.Logging; |
|||
using Microsoft.Extensions.Logging.Abstractions; |
|||
using Microsoft.Extensions.Options; |
|||
using Volo.Abp.Timing; |
|||
|
|||
namespace Volo.Abp.Json.SystemTextJson.JsonConverters; |
|||
|
|||
public abstract class AbpDateTimeConverterBase<T> : JsonConverter<T> |
|||
{ |
|||
public ILogger<AbpDateTimeConverterBase<T>> Logger { get; set; } |
|||
|
|||
protected IClock Clock { get; } |
|||
protected AbpJsonOptions Options { get; } |
|||
protected ICurrentTimezoneProvider CurrentTimezoneProvider { get; } |
|||
protected ITimezoneProvider TimezoneProvider { get; } |
|||
protected bool IsSkipDateTimeNormalization { get; set; } |
|||
|
|||
protected AbpDateTimeConverterBase( |
|||
IClock clock, |
|||
IOptions<AbpJsonOptions> abpJsonOptions, |
|||
ICurrentTimezoneProvider currentTimezoneProvider, |
|||
ITimezoneProvider timezoneProvider) |
|||
{ |
|||
Logger = NullLogger<AbpDateTimeConverterBase<T>>.Instance; |
|||
|
|||
Clock = clock; |
|||
CurrentTimezoneProvider = currentTimezoneProvider; |
|||
TimezoneProvider = timezoneProvider; |
|||
Options = abpJsonOptions.Value; |
|||
} |
|||
|
|||
protected bool TryReadDateTime(ref Utf8JsonReader reader, out DateTime value) |
|||
{ |
|||
value = default; |
|||
|
|||
if (Options.InputDateTimeFormats.Any()) |
|||
{ |
|||
if (reader.TokenType != JsonTokenType.String) |
|||
{ |
|||
return false; |
|||
} |
|||
|
|||
var s = reader.GetString(); |
|||
foreach (var format in Options.InputDateTimeFormats) |
|||
{ |
|||
if (!DateTime.TryParseExact(s, format, CultureInfo.CurrentUICulture, DateTimeStyles.None, out var d1)) |
|||
{ |
|||
continue; |
|||
} |
|||
|
|||
value = Normalize(d1); |
|||
return true; |
|||
} |
|||
} |
|||
|
|||
if (reader.TryGetDateTime(out var d2)) |
|||
{ |
|||
value = Normalize(d2); |
|||
return true; |
|||
} |
|||
|
|||
var dateText = reader.GetString(); |
|||
if (dateText.IsNullOrWhiteSpace()) |
|||
{ |
|||
return false; |
|||
} |
|||
|
|||
if (!DateTime.TryParse(dateText, CultureInfo.CurrentUICulture, DateTimeStyles.None, out var d3)) |
|||
{ |
|||
return false; |
|||
} |
|||
|
|||
value = Normalize(d3); |
|||
return true; |
|||
|
|||
} |
|||
|
|||
protected void WriteDateTime(Utf8JsonWriter writer, DateTime value) |
|||
{ |
|||
if (Options.OutputDateTimeFormat.IsNullOrWhiteSpace()) |
|||
{ |
|||
writer.WriteStringValue(Normalize(value)); |
|||
} |
|||
else |
|||
{ |
|||
writer.WriteStringValue(Normalize(value).ToString(Options.OutputDateTimeFormat, CultureInfo.CurrentUICulture)); |
|||
} |
|||
} |
|||
|
|||
protected virtual DateTime Normalize(DateTime dateTime) |
|||
{ |
|||
if (dateTime.Kind != DateTimeKind.Unspecified || |
|||
!Clock.SupportsMultipleTimezone || |
|||
CurrentTimezoneProvider.TimeZone.IsNullOrWhiteSpace()) |
|||
{ |
|||
return IsSkipDateTimeNormalization ? dateTime : Clock.Normalize(dateTime); |
|||
} |
|||
|
|||
try |
|||
{ |
|||
var timezoneInfo = TimezoneProvider.GetTimeZoneInfo(CurrentTimezoneProvider.TimeZone); |
|||
dateTime = new DateTimeOffset(dateTime, timezoneInfo.GetUtcOffset(dateTime)).UtcDateTime; |
|||
} |
|||
catch |
|||
{ |
|||
Logger.LogWarning("Could not convert DateTime with unspecified Kind using timezone '{TimeZone}'.", CurrentTimezoneProvider.TimeZone); |
|||
} |
|||
|
|||
return IsSkipDateTimeNormalization ? dateTime : Clock.Normalize(dateTime); |
|||
} |
|||
} |
|||
@ -0,0 +1,27 @@ |
|||
using System; |
|||
using System.Collections.Generic; |
|||
using Volo.Abp.Domain.Entities.Auditing; |
|||
|
|||
namespace Volo.Abp.Auditing.App.Entities; |
|||
|
|||
public class AppEntityWithJsonProperty : FullAuditedAggregateRoot<Guid> |
|||
{ |
|||
public string Name { get; set; } |
|||
|
|||
public JsonPropertyObject Data { get; set; } |
|||
|
|||
public int Count { get; set; } |
|||
|
|||
public AppEntityWithJsonProperty() |
|||
{ |
|||
} |
|||
|
|||
public AppEntityWithJsonProperty(Guid id, string name) : base(id) |
|||
{ |
|||
Name = name; |
|||
} |
|||
} |
|||
|
|||
public class JsonPropertyObject : Dictionary<string, object> |
|||
{ |
|||
} |
|||
@ -0,0 +1,10 @@ |
|||
using System; |
|||
|
|||
namespace Volo.Abp.IdentityServer.Clients; |
|||
|
|||
public class ClientFinderResult |
|||
{ |
|||
public Guid Id { get; set; } |
|||
|
|||
public string ClientId { get; set; } |
|||
} |
|||
@ -0,0 +1,9 @@ |
|||
using System.Collections.Generic; |
|||
using System.Threading.Tasks; |
|||
|
|||
namespace Volo.Abp.IdentityServer.Clients; |
|||
|
|||
public interface IClientFinder |
|||
{ |
|||
Task<List<ClientFinderResult>> SearchAsync(string filter, int page = 1); |
|||
} |
|||