mirror of https://github.com/abpframework/abp.git
maliming
4 weeks ago
58 changed files with 1803 additions and 395 deletions
@ -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,18 @@ |
|||
# Pull Request Review – GitHub Copilot Instructions |
|||
|
|||
> **Scope**: Pull request reviews in this repository. |
|||
> |
|||
> **Goal**: Avoid generating noise on machine-generated or automatically merged pull requests, and focus reviews on human-authored changes that require design or code feedback. |
|||
|
|||
--- |
|||
|
|||
## Review Scope Filtering |
|||
|
|||
- When reviewing pull requests, **skip and ignore any pull request whose source branch name starts with `auto-merge/`**. |
|||
- Do **not** generate review comments, suggestions, summaries, or approvals for these pull requests. |
|||
- Treat these pull requests as machine-generated and out of scope for AI review. |
|||
|
|||
## Review Expectations (Applicable PRs Only) |
|||
|
|||
- Only review pull requests created from human-authored feature, bugfix, or maintenance branches. |
|||
- Provide feedback that focuses on correctness, design quality, maintainability, and alignment with existing repository conventions. |
|||
@ -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 |
|
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)); |
|||
} |
|||
} |
|||
|
|||
@ -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> |
|||
{ |
|||
} |
|||
Loading…
Reference in new issue