ABP Studio is a development platform built around ABP Framework. With the introduction of ABP AI Coding Agent, it became something more: a platform where an AI agent works inside the same environment you already use to build, run, monitor, and ship ABP solutions.

General-purpose AI coding tools are excellent for horizontal, file-shaped work. They read source files, edit them, and run shell commands. But ABP solutions are system-shaped, not just file-shaped. A typical ABP solution is split across multiple modules and layers with strict dependency rules, composed of many runnable units (HTTP services, gateways, identity servers, background workers, Docker containers), and built on a strong set of conventions: aggregate roots, repositories, application services, DTOs, permissions, localization, event bus, distributed cache, and background jobs.

A generic agent has none of that vocabulary. It does not know what a module is, which project is the Domain layer, or that an ApplicationService should not depend on a DbContext directly. It cannot start your microservices, gateway, and auth server together. It cannot tell you that the latest edit caused a runtime exception in the Identity service, because it has no concept of a running application.

ABP AI Coding Agent was built to close exactly that gap. The agent is born inside a platform that already understands modules, run profiles, builds, migrations, proxies, Docker containers, monitoring, and Git workflows, and it uses every one of them.

We wrote a nine-part deep dive series to explain how each part of this system works, not as a product tour, but as a practical look at the decisions, controls, and architecture behind the experience.

The Series

1. Agent, Plan and Ask Modes — The three interaction modes that control how much action the agent is allowed to take: Ask for understanding (read-only), Plan for designing the approach before editing, and Agent for full implementation with builds, tools, and iteration.

2. Supported AI Models + Usage Recommendations — How ABP Studio separates models by role (main, research, browser, text processor, Git review) and why treating model selection as a practical decision based on the task leads to a better balance of capability, speed, and cost.

3. Rules, Skills and Lessons — The three mechanisms that give the agent solution-specific memory: Rules (always-on conventions), Skills (on-demand procedures), and Lessons (corrections the agent records and carries forward).

4. Integrated ABP Studio Tools — The tools that connect the agent to ABP Studio's runtime environment: monitoring (exceptions, logs, requests), applications, containers, tasks, and build actions, with a practical walkthrough showing the difference between debugging with and without tool access.

5. MCP (Model Context Protocol) — How MCP extends the agent beyond the solution boundary to reach external systems like Prometheus, SEO analyzers, or documentation services, with per-tool enable/disable controls and stdio/HTTP server support.

6. ABP Studio Git Integration — The full Git loop inside ABP Studio: branching, diffing, AI-generated commit messages, AI code review on staged changes, GitHub issue context for starting tasks, and pull request feedback for addressing reviewer comments.

7. Scopes — How AI Scopes restrict the agent's working area to specific modules, packages, or solution areas, reducing unrelated exploration, preventing accidental edits, and making diffs easier to review.

8. Parallel Agent Execution — Running multiple agent sessions at the same time, each with its own mode, model, scope, and workflow, plus read-only research subagents that fan out inside a single session.

9. Workflows — Repeatable before/after steps that wrap agent runs: start containers, build packages, add migrations, generate proxies, restart applications, and run validation tasks, so the agent focuses on the code change while the platform handles the deterministic parts.

The Bigger Picture

Each article focuses on one feature, but the real value comes from how they work together.

Modes decide how much action the agent takes. Models decide which brain handles the work. Rules, Skills, and Lessons shape what the agent knows. Tools and MCP extend what it can reach. Scopes define where it can work. Workflows define what happens around the work. Git Integration makes the result reviewable and recoverable. Parallel Execution lets multiple tasks move forward at the same time.

That is the ABP AI Coding Agent experience: not a single AI button, but a set of controls built into a platform that already understands how ABP solutions are developed, run, and maintained.

Real work rarely lines up one task at a time.

While the agent is busy adding a feature, a question comes up about a different module. A review is waiting. A small fix would take two minutes, but the agent is in the middle of something else. With a single session, you wait. You watch one task finish before you can start the next, even when the two have nothing to do with each other.

ABP Studio does not make you wait. It can run several agent sessions at the same time, each on its own task.

Parallel Agent Sessions

A session is one conversation with the agent. It has its own history, its own mode, its own model, its own scope, and its own workflow. ABP Studio keeps multiple sessions per solution, and they can run in parallel.

There is a limit, and it is there on purpose. By default you can run up to 3 sessions at once, and you can set that anywhere from 1 to 5. When you send more prompts than there are open slots, the extra ones are queued and start as soon as a slot frees up.

So "parallel" here is not a trick of switching back and forth quickly. The sessions actually run at the same time, up to the limit you choose.

Parallel Session Use Cases

The point is to stop letting one task block another. A few ways it plays out:

• One session implements a feature while another answers questions about a different part of the solution.
• Two unrelated modules get worked on at once, each in its own session.
• One session writes the code while another reviews a diff or does research.

Because each session is separate, you can even point them at different parts of the solution and give them different jobs:

Session 1 (Agent): Add a Category screen to the Catalog module.
Session 2 (Ask): Explain how permissions flow from the API to the UI.

The first one edits files. The second one only reads and answers. They do not interfere, because they are different sessions with different settings.

Per-Session Settings Isolation

This is the part that makes parallel work predictable instead of chaotic.

When a session sends its first message, two things happen at different levels. The session permanently locks its scope and workflow—these stay fixed for the entire session lifetime and cannot be changed once the first message is sent. On the other hand, the model, mode, and active tools are snapshotted fresh at each run (each turn the agent takes), so they reflect whatever is configured at the moment the run starts but remain stable for its duration.

That matters the moment you have more than one session open. Say one session is running in the background, scoped to the Catalog module. You switch the foreground to a different scope to start a second task. The background session does not notice. It keeps the scope and workflow it was locked to, and each of its runs uses whatever model and tools were configured at the moment that run began.

Without this, parallel sessions would quietly corrupt each other every time you changed a setting. With it, each session is a sealed unit of work.

The Prompt Queue

You do not have to wait for a session to be idle to line up its next step.

While a session is running, you can queue more prompts on it. They attach to the same session and are sent one after another, each after the current turn finishes. The queue keeps the session's settings, so a queued prompt runs with the same mode, scope, model, workflow, and active plan as the rest of that session.

This works together with the concurrency limit. Prompts that cannot start right away, because every slot is busy, simply wait their turn instead of failing.

Keeping Parallel Work Safe

Running several sessions at once is powerful, and it also gives you a new way to get in your own way: two sessions editing the same files.

ABP Studio helps here, but it does not pretend the problem away. It tracks file changes, so if one session edited a file after another session read it, the second is told to read it again before overwriting. It also serializes operations that cannot safely overlap, such as adding a migration while a build is running, so two sessions do not run conflicting dotnet commands at the same time. And because each session tracks its own pending questions, one session waiting on your input does not freeze the others.

Still, the simplest rule is the best one: keep parallel Agent-mode sessions on separate parts of the solution. This is exactly where scopes earn their place. Give each session its own scope, and they stay in their own lanes by design instead of by luck.

A Second Kind Of Parallel: Subagents

There is also a smaller, quieter form of parallel work that happens inside a single session.

When the agent needs to look something up, it can fan out multiple subagents in a single turn: read-only helpers that research in parallel and return their results before the main agent continues. There are a few kinds, each with a narrow job:

• one that researches your solution and code,
• one that searches the web,
• one that searches and reads the official ABP documentation.

These research-style subagents (code research, web search, documentation search) are read-only—they cannot modify files or solution state. They only read, gather, and hand back a short summary. That keeps the main session's context clean, because the digging happens elsewhere and only the answer comes back. (Note that the browser subagent is an exception: it is stateful and can mutate the shared browser session.)

ABP Studio can use a separate model for research subagents, configured apart from your main one. A fast, cheap model is the right choice for this kind of lookup work.

So there are two scales of parallel here. Sessions run independent tasks side by side. Subagents run read-only research inside one task. Both keep the slow parts from blocking the useful parts.

ABP Studio Parallel Execution Model

Plenty of tools let you open more than one chat, and that is genuinely useful. So the idea of running agents in parallel is not, by itself, an ABP feature.

The difference is that each session here carries the context of an ABP solution and stays inside it. A session locks its scope and workflow permanently, and snapshots its model and tools per run, so background work does not drift when you change the foreground. Studio coordinates the operations that would otherwise collide, like builds and migrations, across all the running sessions. And scopes give each session a clear boundary, so parallel does not turn into a pile of agents editing the same files.

In short, the parallelism is not just several chat windows. It is several controlled, solution-aware sessions that know how to stay out of each other's way.

Conclusion

Parallel execution is about respecting how work actually arrives: more than one thing at a time, often unrelated.

ABP Studio lets you run several agent sessions together, each sealed to its own settings, with a queue for what comes next and guardrails for the places where parallel work could collide. Inside each session, subagents add a second layer of parallel research without cluttering the main task.

When I use an AI coding agent inside ABP Studio, most of the work starts inside the solution.

The agent can read the code. It can edit files. It can use the ABP Studio tools I enabled. It can build the solution, run tasks, start applications, inspect containers, and check monitoring data when something fails. In the previous article of this series, we focused on exactly that: the integrated tools that connect the agent to the ABP Studio development environment.

But there is another point where plain solution awareness is not enough.

Sometimes the information I need is not in the repository. It is not in the running application. It is not in the build output, container state, or ABP Studio monitoring screen.

It may be in a live Prometheus workspace. It may be in Google Search Console. It may be in an SEO analyzer, a documentation system, a database, a customer support tool, or another service that has nothing to do with the ABP solution itself.

That is where MCP becomes useful.

MCP, short for Model Context Protocol, gives ABP AI Coding Agent a standard way to reach external tools and data sources. It does not replace the built-in ABP Studio tools. It extends the agent beyond the solution boundary when the task depends on something outside that boundary.

Note: ABP AI Coding Agent is available directly to ABP license holders. License holders have predefined credits so they can try the integrated experience without setting up a separate AI workflow first. MCP is one of the ways this experience can be extended when the agent needs access to systems outside ABP Studio.

Why MCP Matters

Most coding agents start from the same place: the files they can see.

That is a good start, but real development work often needs context from somewhere else: production metrics, SEO data, analytics, search performance, customer records, internal APIs, or product knowledge.

If the agent cannot reach those systems, the developer becomes the bridge:

• Copy this metric result.
• Paste that SEO report.
• Export this analytics data.
• Summarize this dashboard.
• Explain which production signal matters.
• Tell the agent what the external system says.

That works, but it is not the best workflow. The more information I manually copy into the chat, the easier it is to miss something, simplify too much, or give the agent an outdated snapshot.

MCP reduces that manual work. It lets the agent ask an external system for context directly, within the permission boundary I configure.

The important detail is that MCP is not "the agent can do anything now." It is a controlled extension point. A server is connected. Its tools are listed. Individual tools can be enabled or disabled. The agent can only use what is available in the current session.

That gives me a practical balance: the ABP-aware development experience stays in ABP Studio, and external context can be added only when the task needs it.

What MCP Actually Is

MCP is an open standard for connecting external tools and data to AI agents.

Instead of every tool inventing its own integration for every agent, MCP defines a common shape. A program that exposes tools or resources through this standard is called an MCP server. An agent that understands MCP can connect to that server and use what it provides.

For me, the easiest way to think about it is simple:

• ABP Studio tools connect the agent to the ABP development environment.
• MCP servers connect the agent to systems outside that environment.

The server might expose a tool for querying Prometheus, checking Search Console data, running an SEO audit, inspecting a database, or calling an internal API. The exact capability depends on the server.

MCP is not a prompt, a rule, a skill, or a lesson. Those shape what the agent knows or how it behaves. MCP changes what the agent can reach.

That makes MCP more like equipment than instruction. It gives the agent access to a tool or data source that was previously outside its working area.

There are already many community and vendor MCP servers for different systems. A useful place to discover examples is the awesome-mcp-servers repository, which collects MCP servers across many categories.

For concrete examples, there are MCP servers for Prometheus metrics, AWS Managed Prometheus, and SEO analysis. The exact server you choose depends on your environment, but the pattern is the same: expose a focused external capability to the agent through MCP.

When You Actually Need It

Most of the time, I would not start with MCP.

For normal ABP development, the built-in tools are usually the right first layer. The agent can already work with the solution, run profiles, applications, containers, tasks, builds, monitoring data, and documentation. If the task is completely inside the ABP solution, MCP may not add anything.

MCP becomes useful when the task crosses the solution boundary.

For example, I may ask:

Run an SEO audit for https://abp.io, summarize the weak areas, and suggest which content or technical improvements would matter most.

Without MCP, I would need to open a separate SEO tool, run the audit, copy the results, and paste them into the chat. With the right MCP server enabled, the agent can call the SEO tool directly and reason from the structured result.

Or I may ask:

Connect to our Prometheus MCP server, check the error rate and p95 latency for the AuthServer over the last 30 minutes, and tell me whether the last deployment changed anything.

That is a very different kind of task. The answer is not in the source code alone. It lives in a monitoring system. Prometheus MCP servers exist for this kind of workflow; for example, some expose tools for instant PromQL queries, range queries, metric discovery, and target inspection.

Another realistic prompt could be:

Use Search Console data to find pages that lost traffic this month, then inspect the related docs pages and suggest focused improvements.

Again, the important part is not that the agent magically knows everything. The important part is that I can connect a specific external system, expose a specific set of tools, and let the agent use them when they are relevant.

If the work starts outside the codebase but ends inside the codebase, MCP can help connect those two parts of the workflow.

Setting Up An MCP Server

MCP servers are configured under Settings > MCP Servers.

When no server is connected, the page is intentionally simple. It is an empty list waiting for the first server. That is important because MCP should be explicit. If I have not connected a server, the agent should not behave as if it has access to that external system.

Add integration opens a curated gallery of common MCP servers. Each entry shows information such as whether it is official, read-only, authenticated by the provider, or runs a local command. If the integration has configurable values, ABP Studio opens a focused setup form and lets me update those values later. New integrations are disabled until I review and enable them.

There are two main connection types:

• Stdio: ABP Studio runs the MCP server as a local process. I provide the command, arguments, and environment variables the server needs.
• HTTP: ABP Studio connects to an MCP server over the network. I provide the URL and any required headers.

This is useful because different MCP servers are packaged in different ways. Some are local command-line programs. Some are hosted services. Some need environment variables for tokens or configuration.

For integrations outside the gallery, Edit JSON opens the complete server collection as one mcpServers document. ABP Studio validates and applies the entire document together, so a server omitted from the document is removed. Environment-variable and HTTP-header secrets are stored separately and appear in the editor as ${secret:NAME} placeholders.

See ABP Studio: AI Agent Configuration for the supported JSON fields and secret-storage behavior.

What A Connected Server Shows

After a server is connected, ABP Studio shows the important parts of the connection.

I can see whether the server is connected, how many tools it exposes, which tools are available, and whether it provides resources. I can also inspect resources directly from the settings page.

This visibility matters because an MCP server is not just a checkbox. It is a surface area. It may expose one tool or many. Some tools may be read-only, and some may perform actions outside the repository.

The agent does not need me to call those tools manually. I describe the task, and if the tool is available and relevant, the agent can decide to use it. That is why a prompt can stay natural:

Read the product requirement from the connected knowledge base and compare it with the current implementation.

The prompt does not need to become a tool invocation script. The agent still owns the reasoning loop. MCP only gives it a new place to look.

Tool Access: What The Agent Is Allowed To Use

The most important part of MCP in ABP Studio is not only connecting servers. It is controlling what the agent is allowed to use.

Individual tools can be disabled. If a tool is disabled, it is not offered to the agent. The agent should not plan around it, call it, or assume it has access to it.

That is useful for safety, but also for quality.

Every enabled tool becomes part of the menu the agent considers. If a server exposes ten tools but the current task only needs two, I usually prefer to enable only those two. A shorter tool list is easier for the agent to choose from. It also makes the session easier for me to reason about.

The permission model is simple:

• If a server is not connected, the agent cannot use it.
• If a server is disabled, the agent cannot use its tools.
• If an individual tool is disabled, the agent cannot use that tool.
• If the session is not in Agent mode, MCP tools are not available.

That last point is important. MCP tools are available in Agent mode only.

Plan and Ask modes are read-only by design. They are useful for understanding, planning, and discussing changes, but they do not receive MCP tools. If I want the agent to call an external MCP tool, I need to work in Agent mode.

This keeps the model consistent with the rest of the ABP AI Coding Agent experience. The mode determines what kind of work the agent is allowed to perform.

Keeping MCP Safe

MCP is powerful because it lets an AI agent reach systems outside the solution.

That is also why it needs care.

An MCP server is a program. It may read files, call APIs, query databases, send requests, or perform actions depending on how it was built. The agent is not inventing those capabilities. It is using what the server exposes.

So trust matters at two levels.

First, I need to trust the actions. If a tool can update an issue, send a message, change a record, or trigger a workflow, that is a real side effect.

Second, I need to trust the descriptions. When an MCP server connects, the names and descriptions of its tools become part of what the model can read. A careless or hostile server can use that text to influence the model before I even write my prompt.

That means MCP safety is not only about "what can this tool do?" It is also about "what instructions or descriptions does this server place in front of the model?"

Two habits keep this manageable:

• Connect only servers I trust.
• Disable tools the agent should not use for the current task.

This sits on top of the agent's normal guardrails. Shell commands, URL fetches, downloads, and other sensitive actions can still require permission. Also, the tool list is fixed for a running session, so changing a server in the middle of a session does not quietly alter the tool surface already given to that session.

That is the behavior I want from this kind of integration. MCP can extend the agent, but it should do so through visible, intentional configuration.

A Practical MCP Walkthrough

Let me make this more concrete with a small scenario.

Imagine I am working on the public website or documentation side of an ABP-based product. The task is not a compiler error or a failing unit test. I want to understand how the website looks from an SEO perspective and what I would improve first.

Without MCP, I would open a separate SEO tool, run the audit, wait for the result, copy the score, paste the table into the chat, and then ask the agent to interpret it. That is not terrible, but it turns me into a copy-paste integration layer.

With an SEO Analyzer MCP server connected, I can start from a better prompt:

Please rate the SEO work on the https://abp.io website on a scale of 1 to 10. I'd also like to know what you would do if you were in charge.

At that point, the agent can use the SEO Analyzer MCP tool instead of guessing from general SEO knowledge alone. It can call the audit tool, read the structured result, and turn it into a concrete improvement plan.

The value is not only that the agent saved me a few seconds. The value is that the agent starts from live tool output instead of a manually summarized report.

First, Without The MCP Server

If no SEO MCP server is connected, the agent cannot run the audit directly.

It may still give a reasonable answer from general knowledge. It may say that the site should have good titles, descriptions, headings, performance, backlinks, structured data, and content targeting. That advice can be useful, but it is generic.

For example, I might write:

Review the SEO of abp.io and tell me what to improve.

The agent can reason about common SEO practices, but it does not have a fresh audit result. It does not know which categories scored well, which areas are weak, or whether the live page data confirms the concern.

This is similar to debugging without monitoring tools. The agent can reason, but it is reasoning from weaker evidence.

Then, With The MCP Server Enabled

Now imagine the SEO Analyzer MCP server is connected, enabled, and the relevant audit tool is enabled.

I can ask:

Run an audit on https://abp.io, rate the result, and suggest the highest-impact improvements.

This time the agent can gather the external context first. In the screenshot, the server exposes tools like run_audit_anonymous, run_audit, get_audit, list_audits, get_audit_pdf, and get_organic_traffic. The agent uses the audit tool and then explains the result in human terms.

That changes the workflow:

1. Run the external SEO audit.
2. Read the score and category breakdown.
3. Identify the weakest areas.
4. Suggest concrete technical or content improvements.
5. If needed, inspect the related website or documentation files.

The agent is no longer guessing from best practices alone. It can connect the outside report to the actual website and then, if the relevant files are in the solution, help improve them.

Another Example: Live Monitoring

SEO is only one example. Monitoring is another strong fit for MCP.

Prometheus MCP servers can expose tools for PromQL instant queries, range queries, metric discovery, targets, and server information. That means I can ask operational questions in natural language while the agent queries the monitoring system through MCP.

For example:

Use the Prometheus MCP server to check p95 latency, request rate, and error rate for the public web application after the last deployment. If something changed, identify the most likely area to inspect in the ABP solution.

That does not mean the agent should blindly change production behavior. It means the agent can start from live evidence: metrics, trends, targets, and recent changes. Then it can use ABP Studio context to inspect the related application, module, or configuration.

Combining MCP With ABP Studio Tools

The best part is that MCP does not replace the ABP Studio tools from the previous article. It works beside them.

In a real workflow, MCP may provide the outside signal, and ABP Studio tools may provide the inside development loop:

1. MCP brings in the external context.
2. ABP-aware reasoning maps it to the solution.
3. ABP Studio tools help implement and validate the change.

That is where the integration becomes more useful than a generic MCP checkbox. The agent is connected to an external tool while still understanding the ABP development environment.

How MCP Fits With Everything Else

MCP is an open standard, so connecting an MCP server is not an ABP-only idea.

Tools like Cursor, Claude, VS Code extensions, and other AI coding environments can also use MCP. That is part of its appeal. Teams can build or adopt a server once and use it across different tools.

What makes MCP especially useful in ABP Studio is the company it keeps. ABP AI Coding Agent already understands the ABP solution structure, application layers, modules, migrations, proxies, build actions, run profiles, containers, monitoring data, and official ABP documentation. MCP adds the outside world to that picture.

So I do not need to choose between:

• an agent that understands ABP,
• and an agent that can reach my team's external systems.

The better experience is both together, under visible configuration. Put simply:

• Built-in ABP Studio tools handle the solution and runtime environment.
• MCP servers handle external tools and data sources.
• Rules, skills, and lessons shape how the agent behaves.
• Agent mode decides whether tool use is available for the session.

Each part has a different role. Keeping those roles clear makes the agent easier to trust. This is also why I would start small in a real team workflow: one low-risk, high-value server, probably a read-only analytics, documentation, or monitoring server, with only the tools that support a clear workflow enabled.

MCP by itself is a protocol. The difference in ABP Studio is that MCP becomes part of an ABP development session. The agent can read an external SEO report or monitoring signal, but it can also understand which ABP application, module, page, or configuration owns the behavior and validate the change with ABP Studio tools.

Most real tasks are not only "call an external tool." They are more like:

1. Understand the requirement from outside the repository.
2. Find where that behavior lives in the ABP solution.
3. Make the smallest correct change.
4. Validate it in the same development environment.

MCP helps with the first part. ABP Studio AI helps connect the rest.

That makes MCP valuable not because it is another tool list, but because it extends the ABP AI Coding Agent beyond the repository without disconnecting it from the ABP workflow.

Conclusion

MCP is the agent's connection to everything that is not already inside the ABP solution.

You will not need it for every task. But when the work depends on SEO data, live metrics, external documentation, internal services, or team knowledge, MCP gives the agent a standard way to reach that context.

Every new chat starts from zero.

The model can write the API, the permissions, and the UI. What disappears between sessions is everything specific to this solution: your naming rules, your feature checklist, the demo-data fix from yesterday. You end up re-teaching before you start building.

That is not an intelligence problem. The model is already capable enough. What does not carry over is the setup around it.

Agent, Model, and Harness

Three terms get mixed up constantly. Keeping them separate makes everything else in this article click.

The model is the LLM: the weights, the training data, the reasoning engine. You do not get to change it. You pick which one to use, and that is about it.

The harness is everything wrapped around the model so it can actually finish work in your environment: the system prompt, the tools it can call, the files it may read, the checks that run on its output, the limits on what it may touch, and the instructions injected into every session. A raw model is not an agent. An agent is the model plus the harness. If you are not the model, you are building the harness.

The agent is the whole system: model plus harness, running in a loop until the task is done. The behaviour you experience is dominated by the harness, not just the model. Addy Osmani puts the same idea plainly: a decent model with a great harness beats a great model with a bad harness. The gap between what today's models can do and what you actually see them do in your codebase is mostly a harness gap.

The habit that makes a harness good is simple: treat every mistake as a reason to update the setup, not just to fix the output in chat. Each time the agent gets something wrong, change what it always knows, can look up, or carries forward so it cannot repeat the same error. Do that consistently and the agent stops repeating mistakes and starts working the way your team works.

In ABP Studio AI Coding Agent, the harness includes three pieces that hold what the agent knows about your solution: Rules, Skills, and Lessons. They live under Settings > Rules & Skills.

Rules: The House Rules On The Wall

A Rule is a standing instruction that the harness injects into the agent's context on every turn of every session. In harness-engineering terms, it is always-on context injection: the same role as an AGENTS.md or CLAUDE.md at the root of a repo, except scoped to your solution or your profile inside ABP Studio.

Think of the house rules pinned to a kitchen wall: how we do things here, every shift, no exceptions. Unlike a glance at a poster, though, a Rule is not ambient background. It is read on every turn, so it costs context budget every time the agent acts.

ABP Agent already follows the framework's own conventions by default. It goes through the data layer instead of hitting the database directly, uses the built-in permission system instead of hand-rolled checks, and reads user-facing text from the translation files instead of hardcoding it. You do not write those down.

Rules are where your conventions go. The ones the framework cannot guess because they belong to your solution and your team. The good part is that these read like plain conventions any developer would recognize, not framework trivia:

• New code goes in the same place, with the same naming, as the code already around it.
• Every endpoint that changes data checks permissions before it does anything.
• Money is stored in minor units (cents), never as a floating-point number.
• API errors use our standard response shape, never ad-hoc JSON.

With those on the wall, I stop repeating them. Instead of writing this:

Add a Category screen. Use our data layer, do not query the database
directly. Check permissions on every write. Keep money in cents. Put the
files where the other features live.

I can write this:

Add a Category screen.

The conventions are not renegotiated, one prompt at a time, in every session. The agent applies them the way a teammate who has read the contributor guide would.

This matters more than it looks. A model with no standing rules does not stay neutral. It falls back on the defaults from its training data. Ask a generic model for "an endpoint that returns categories" and you often get one with the database query written straight into the handler, because that is the most common shape on the public internet. Rules steer the agent's output back toward your codebase.

One caution: treat the rule list like a pilot's checklist, not a style guide. A Rule is injected on every turn, so keep the list short. Every line should earn its place, ideally traceable to a real failure or a hard constraint you cannot ignore. If a line does not change what the agent produces, it is noise, and it dilutes the rules that actually matter.

You also choose where a rule is saved. Global rules sit under your user profile and apply to every solution on your machine. Solution rules apply only to the current solution, and only while it is open.

Skills: Recipes You Pull Off The Shelf

A Skill is the same kind of note as a Rule, but loaded only when the task calls for it. The harness keeps a short description of each skill in context at all times; the agent reads the full text only when that description matches what you asked it to do. Harness engineers call this progressive disclosure: reveal instructions and detail only when they are needed, instead of stuffing everything into the opening prompt.

A recipe is not pinned to the wall. It sits in a drawer, and the cook pulls it out only when making that dish. That is a Skill.

In ABP Studio, a rule and a skill are the same kind of note with one switch between them.

You write a name (which becomes the file name) and some content, then set Always Apply. Turn it on and the note is a Rule, always in context. Turn it off and the note is a Skill, fetched on demand. So if a skill turns out to be something the agent should never skip, you flip one switch and it becomes a rule.

My favorite example of a skill is a "build a feature end to end" checklist: the ordered steps your team follows to ship one complete feature. The data model comes first, then the data access layer, then the application service, then the API, then the translations, then the UI, and finally the demo data. Write it once, and the agent follows it whenever it builds a feature, instead of inventing its own order each time.

Writing a skill is like writing an onboarding note for a new teammate. You are not making them smarter. You are saving them the week it would take to work out how your team does this one thing.

A skill can be long without slowing anything down. The agent sees only the short description of each skill at all times, and reads the full text only when the description matches the task. The detail stays in the drawer until it is needed.

Skills are also portable. A skill is plain Markdown, so you can import one written elsewhere instead of retyping it.

You point the importer at a file or a folder of .md files and choose whether they go into the current solution or your global profile. A procedure one person worked out can travel to the rest of the team, or to your next solution.

A simple test for which one to reach for:

• If it should hold no matter what you are doing, it is a Rule. ("Always return errors in our standard shape.")
• If it is a procedure you follow only for a certain kind of task, it is a Skill. ("Here is our checklist for adding a feature end to end.")

Lessons: What The Agent Learns On Its Own

Rules and Skills are written by a person. Lessons are written by the agent.

Think of a shift handoff log in the kitchen: after something goes wrong, someone writes down what happened and what to do differently next time. The next cook reads it before repeating the same work. In ABP Studio, you correct the mistake; the agent records the verified fix so future sessions do not trip over it again. That entry is a Lesson.

When the agent gets something wrong and is corrected, by you, by a failing build, or by the official ABP documentation, it can record the correction as a short, verified note. The harness carries that note into later turns and later sessions as high-priority context. That is the ai-learned-lessons entry you saw in the settings list, growing as the agent works in your solution.

The idea behind it is simple: when the agent gets something wrong, fix it once so it never gets it wrong the same way again. You already do a version of this when you edit a notes file by hand. Lessons do the recording for you, at the moment of the correction, when the reason is still fresh and you would otherwise forget to write it down.

Here is the shape of a real one. I ask the agent to add a Category screen. It builds the data model, the API, and the UI, but forgets to grant the new permission in the demo data. The screen compiles, the API responds, everything looks finished, and the only symptom is that real users get "access denied." I correct it, the agent fixes the demo data, and it records a note: in this solution, a new permission is not done until it is granted in the demo data. Next time, it remembers.

A Lesson is not a general fact about ABP. The documentation already covers that, and the agent reads it. A Lesson is a solution-specific, verified correction: the kind of knowledge a team usually keeps in people's heads and loses when they move on. Here it is written down the moment it is learned, instead of weeks later, if ever.

When To Use Which?

Once the three are clear, they sort themselves out:

| Mechanism | Who writes it | When it loads | Answers | | --- | --- | --- | --- | | Rules | You | Always, every turn | "What must always be true here?" | | Skills | You | When relevant to the task | "How do we do this kind of task?" | | Lessons | The agent | In later sessions, as high-priority context | "What did we get wrong before in this solution?" |

They feed into each other. A Lesson that keeps coming back is a sign it should be promoted. If the agent records the same correction again and again, it is no longer a one-off note. It belongs in a Rule, if it is an always-true convention, or in a Skill, if it is a procedure. Knowledge tends to move from Lessons toward Rules and Skills: the agent finds the pattern by tripping over it, and you write it down properly once it has earned the spot.

Keep an eye on the budget, because all three share the same limited space, the context window. Rules cost the most, since they are always present, so an overstuffed rule list weighs down every turn and crowds out the rules that matter. Skills are cheaper, paid for only when used, which is a good reason to move anything situational out of Rules and into a Skill. Lessons add up too, so clear out the stale ones now and then. The point is not to write down everything you know. It is to write down the few things that change what the agent produces, and put each one where it loads at the right time.

Why This Is Different From Generic Coding Agents?

To be fair, the ideas themselves are not unique to ABP. Tools like Cursor, Claude Code, Codex, and Windsurf are strong general-purpose coding tools, and they already have always-on instruction files and on-demand skill files. If all you compare is whether a tool can hold rules and skills, there is no real difference, and I would not pretend otherwise.

The difference is in the two places where a generic tool has to guess.

The first is memory of its own mistakes. In most tools, remembering a past mistake means you stop and edit a memory file by hand. Lessons remove that step. The agent records the correction itself, the moment it happens, so the knowledge survives without you having to maintain it.

The second, and the one that matters most, is what all of this sits on. A generic instruction file can say "use the data layer," but the tool still has to read your files and guess what the data layer is and where it lives. ABP Agent does not guess. It starts every session with an ABP-aware map of your solution, and when it is unsure how something should be done, it checks the official ABP documentation instead of the average of the public internet. So the rules and skills you write are not hints dropped into a tool that barely understands the project. They are backed by one that already knows the framework underneath them.

There is also a smaller convenience worth a line: a rule and a skill are the same note with one switch between them, scoped to the solution or your profile from the same place, instead of two separate file formats to keep track of.

Conclusion

It is best to see the three as one system, not three switches.

• Rules hold the conventions you refuse to repeat.
• Skills hold the procedures you want to reuse.
• Lessons hold the corrections the agent learns as it works.

Together they answer the blank-memory problem. They do not give the model new weights. They inject, at the start of each session, the smallest useful set of instructions so the agent can work as if it has been here before.

A generic agent with no harness tuning stays roughly as capable on its thousandth task in your codebase as on its first. With Rules, Skills, and Lessons, ABP Agent accumulates solution-specific knowledge over time, especially through Lessons and the promotions you make from them.

That is the real value: not just an AI that writes code, but one that learns how your solution is built and keeps that knowledge from one session to the next.

We are excited to announce the integration of Aspire into the ABP microservice solution, available starting with ABP Studio v2.0.0. This integration brings a unified development experience for building, running, debugging, and deploying distributed applications. With Aspire, you can now orchestrate your entire microservice ecosystem with a single command, eliminating complex configurations and making local development effortless.

What is Aspire?

Aspire is a cloud-ready stack designed to streamline the development of distributed applications. It provides:

• Orchestration: A code-first approach to defining and running distributed applications, managing dependencies, and launch order.
• Integrations: Pre-built components for common services (databases, caches, message brokers) with automatic configuration.
• Tooling: A developer dashboard for real-time monitoring of logs, traces, metrics, and resource health.
• Service Discovery: Automatic service-to-service communication without hardcoded endpoints.
• Observability: Built-in OpenTelemetry support for distributed tracing, metrics, and structured logging.

How Does It Work with ABP?

When you enable Aspire in an ABP microservice solution, you get a fully integrated development experience where:

• All microservices, gateways, and applications are orchestrated through a single entry point (AppHost).
• Infrastructure containers (databases, Redis, RabbitMQ, Elasticsearch, etc.) are managed as code.
• OpenTelemetry, health checks, and service discovery are automatically configured for all projects via the shared ServiceDefaults project.

Enabling Aspire in Your Solution

When creating a new microservice solution via ABP Studio:

1. In the solution creation wizard, look for the "Aspire Integration" step.
2. Toggle the option to enable Aspire.
3. Complete the wizard—Aspire projects will be generated along with your solution.

Solution Structure Changes

When Aspire is enabled, two additional projects are added to your solution:

AppHost (Orchestrator)

AppHost is the Aspire orchestrator project that declares all resources (services, databases, containers, applications) and their dependencies in C# code. It provides:

• Centralized orchestration: Start your entire microservice ecosystem with a single command.
• Code-first infrastructure: Databases, Redis, RabbitMQ, Elasticsearch, and observability tools are defined programmatically.
• Dependency management: Services start in the correct order using WaitFor() declarations.
• Automatic configuration: Connection strings, endpoints, and environment variables are injected automatically.

ServiceDefaults

ServiceDefaults is a shared library that provides common cloud-native configuration for all projects in the solution. Every service uses the same observability, health check, and resilience patterns.

| Feature | Description | |---------|-------------| | OpenTelemetry | Tracing, metrics, and structured logging with automatic instrumentation | | Health Checks | /health and /alive endpoints for Kubernetes-style probes | | Service Discovery | Automatic resolution of service endpoints | | HTTP Resilience | Retry policies, timeouts, and circuit breakers for HTTP clients |

Running the Solution with Aspire

Running your microservice solution has never been easier:

1. Open Solution Runner in ABP Studio.
2. Select the Aspire profile.
3. Run AppHost.

AppHost automatically:

• Starts all infrastructure containers (database, Redis, RabbitMQ, Elasticsearch, etc.).
• Launches all microservices, gateways, and applications in dependency order.
• Injects connection strings and environment variables.
• Opens the Aspire Dashboard for monitoring.

Aspire Dashboard

The Aspire Dashboard provides real-time tracking of your application's state. It enables you to monitor logs, traces, metrics, and environment configurations in an intuitive UI.

Key Dashboard Features

Console Logs

Display console logs from all resources in real-time. Filter by resource and log level to quickly find relevant information during development and debugging.

Structured Logs

View structured logs from all resources with advanced filtering capabilities. Search and filter logs by resource, log level, timestamp, and custom properties.

Distributed Traces

Explore distributed traces across your microservices to understand request flows and identify performance bottlenecks.

Metrics

Monitor real-time metrics including HTTP requests, response times, garbage collection, memory usage, and custom metrics.

Pre-Configured Observability Tools

AppHost comes with pre-configured observability and management tools:

Grafana

Visualization and analytics platform for monitoring metrics with interactive dashboards.

Jaeger

Distributed tracing system to monitor and troubleshoot problems across microservices.

Kibana

Visualization tool for Elasticsearch data with search and data visualization capabilities for logs.

Prometheus

Monitoring and alerting toolkit that collects and stores metrics as time series data.

RabbitMQ Management

Web-based interface for managing and monitoring the RabbitMQ message broker.

Redis Insight

Visual tool for Redis that allows you to browse data, run commands, and monitor performance.

Database Admin Tools

The database management admin tool varies by database type:

| Database | Tool | |----------|------| | SQL Server | DBeaver CloudBeaver | | MySQL | phpMyAdmin | | PostgreSQL | pgAdmin | | MongoDB | Mongo Express |

Get Started Today

Ready to experience the power of Aspire with ABP? Create a new microservice solution in ABP Studio and enable the Aspire integration option. For detailed documentation, visit our Aspire Integration documentation.

To learn more about Aspire, visit: https://aspire.dev

We are excited to bring this integration to you and can't wait to hear your feedback. If you have any questions or suggestions, please drop a comment below.

Happy coding!

The Volosoft Team

Experienced back-end developers often approach new frameworks with healthy skepticism. But many who try the ABP Framework quickly notice something different: things “just work” with minimal boilerplate. There’s a good reason ABP can feel magical – it silently handles a host of tedious tasks behind the scenes. In this article, we’ll explore how ABP’s out-of-the-box features and modular architecture dramatically boost productivity. We’ll compare with plain ASP.NET Core where relevant, so you can appreciate what ABP is doing for you under the hood.

Beyond the Basics: Why ABP Feels Magical

ABP isn’t a typical library; it’s a full application framework that goes beyond the basics. From the moment you start an ABP project, a lot is happening automatically. Have you ever built an ASP.NET Core app and spent time wiring up cross-cutting concerns like error handling, logging, security tokens, or multi-tenancy? With ABP, much of that comes pre-configured. You might find that you write just your business logic, and ABP has already enabled security, transactions, and even APIs for you by convention. This can be disorienting at first (“Where’s the code that does X?”) until you realize ABP’s design is doing it for you, in line with best practices.

For example, ABP completely automates CSRF (anti-forgery) protection and it works out-of-the-box without any configuration. In a plain ASP.NET Core project, you’d have to add anti-forgery tokens to your views or enable a global filter and manually include the token in AJAX calls. ABP’s startup template already includes a global antiforgery filter and even sets up the client-side code to send the token on each request, without you writing a line. This kind of “invisible” setup is repeated across many areas. ABP’s philosophy is to take care of the plumbing – like unit of work, data filters, audit logging, etc. – so you can focus on the real code. It feels magical because things that would normally require explicit code or packages in ASP.NET Core are just handled. As we peel back the layers in the next sections, you’ll see how ABP pulls off these tricks.

Zero to Hero: Rapid Application Development with ABP

One of the most striking benefits of ABP is how quickly you can go from zero to a fully functional application – it’s a true rapid application development platform. With ASP.NET Core alone, setting up a new project with identity management, localization, an API layer, and a clean architecture can be a day’s work or more. In contrast, ABP’s startup templates give you a solution with all those pieces pre-wired. You can create a new ABP project (using the ABP CLI or ABP Studio) and run it, and you already have: user login and registration, role-based permission management, an admin UI, a REST API layer with Swagger, and a clean domain-driven code structure. It’s essentially a jump-start that takes you from zero to hero in record time.

Rapid development is further enabled by ABP’s coding model. Define an entity and an application service, and ABP can generate the REST API endpoints for you automatically (via Conventional Controllers). You don’t need to write repetitive controllers that just call the service; ABP’s conventions map your service methods to HTTP verbs and routes by naming convention. For instance, a method name GetListAsync() in an AppService becomes an HTTP GET to /api/app/your-entity without extra attributes. The result: you implement application logic once in the application layer, and ABP instantly exposes it as an API (and even provides client proxies for UI).

The tooling in the ABP ecosystem multiplies this productivity. The ABP Suite tool, for example, allows you to visually design entities and then generate a full-stack CRUD page for your entities in seconds, complete with UI forms, validation, DTOs, application services, and even unit tests. The generated code follows ABP’s best practices (layered architecture, proper authorization checks, etc.), so you’re not creating a maintenance headache. You get a working feature out-of-the-box and can then tweak it to your needs. All these accelerators mean you can deliver features at a higher velocity than ever, turning a blank project into a real application with minimal grunt work.

Modular Architecture: Building Like Digital Lego

Perhaps the greatest strength of ABP is its modular architecture. Think of modules as building blocks – “digital Lego” pieces – that you can snap together to compose your application. ABP itself is built on modules (for example, Identity, Audit Logging, Language Management, etc.), and you can develop your own modules as well. This design encourages separation of concerns and reusability. Need a certain functionality? Chances are, ABP has a module for it – just plug it in, and it works seamlessly with the others.

With plain ASP.NET Core, setting up a modular system requires a lot of upfront design. ABP, however, “is born to be a modular application development structure”, where every feature is compatible with modular development by default. The framework ensures that each module can encapsulate its own domain, application services, database migrations, UI pages, etc., without tight coupling. For example, the ABP Identity module provides all the user and role management functionality (built atop ASP.NET Core Identity), the SaaS module provides multi-tenant management, the Audit Logging module records user activities, and so on. You can include these modules in your project, gaining enterprise-grade functionality in literally one line of configuration. As the official documentation puts it, ABP provides “a lot of re-usable application modules like payment, chat, file management, audit log reporting… All of these modules are easily installed into your solution and directly work.” This is a huge time saver – you’re not reinventing the wheel for common requirements.

The Lego-like nature also means you can remove or swap pieces without breaking the whole. If a built-in module doesn’t meet your needs, you can extend it or replace it (we’ll talk about customization later). Modules can even be maintained as separate packages, enabling teams to develop features in isolation and share modules across projects. Ultimately, ABP’s modularity gives your architecture a level of flexibility and organization that plain ASP.NET Core doesn’t provide out-of-the-box. It’s a solid foundation for either monolithic applications or microservice systems, as you can start with a modular monolith and later split modules into services if needed. In short, ABP provides the architectural “bricks” – you design the house.

Out-of-the-Box Features that Save Weeks of Work

Beyond the big building blocks, ABP comes with a plethora of built-in features that operate behind the scenes to save you time. These are things that, in a non-ABP project, you would likely spend days or weeks implementing and fine-tuning – but ABP gives them to you on Day 1. Here are some of the key hidden gems ABP provides out-of-the-box:

• CSRF Protection: As mentioned earlier, ABP automatically enables anti-forgery tokens for you. You get robust CSRF/XSRF protection by default – the server issues a token cookie and expects a header on modify requests, all handled by ABP’s infrastructure without manual setup. This means your app is defended against cross-site request forgery with essentially zero effort on your part.
• Automated Data Filtering: ABP uses data filters to transparently apply common query conditions. For example, if an entity implements ISoftDelete, it will not be retrieved in queries unless you explicitly ask for deleted data. ABP automatically sets IsDeleted=true instead of truly deleting and filters it out on queries, so you don’t accidentally show or modify soft-deleted records. Similarly, if an entity implements IMultiTenant, ABP will “silently in the background” filter all queries to the current tenant and fill the TenantId on new records – no need to manually add tenant clauses to every repository query. These filters (and others) are on by default and can be toggled when needed, giving you multi-tenancy and soft delete behavior out-of-the-box.
• Concurrency Control: In enterprise apps, it’s important to handle concurrent edits to avoid clobbering data. ABP makes this easy with an optimistic concurrency system. If you implement IHasConcurrencyStamp on an entity, ABP will automatically set a GUID stamp on insert and check that stamp on updates to detect conflicts, throwing an exception if the record was changed by someone else. In ASP.NET Core EF you’d set up a RowVersion or concurrency token manually – ABP’s built-in approach is a ready-to-use solution to ensure data consistency.
• Data Seeding: Most applications need initial seed data (like an admin user, initial roles, etc.). ABP provides a modular data seeding system that runs on application startup or during migration. You can implement an IDataSeedContributor and ABP will automatically discover and execute it as part of the seeding process. Different modules add their own seed contributors (for example, the Identity module seeds the admin user/role). This system is database-independent and even works in production deployments (the templates include a DbMigrator tool to apply migrations and seed data). It’s more flexible than EF Core’s native seeding and saves you writing custom seeding scripts.
• Audit Logging: ABP has an integrated auditing mechanism that logs details of each web request. By default, an audit log is created for each API call or MVC page hit, recording who did what and when. It captures the URL and HTTP method, execution duration, the user making the call, the parameters passed to application services, any exceptions thrown, and even entity changes saved to the database during the request. All of this is saved automatically (for example, into the AbpAuditLogs table if using EF Core). The startup templates enable auditing by default, so you have an audit trail with no extra coding. In a vanilla ASP.NET Core app, you’d have to implement your own logging to achieve this level of detail.
• Unit of Work & Transaction Management: ABP implements the Unit of Work pattern globally. When you call a repository or an application service method, ABP will automatically start a UOW (database transaction) for you if one isn’t already running. It will commit on success or roll back on error. By convention, all app service methods, controller actions, and repository methods are wrapped in a UOW – so you don’t explicitly call SaveChanges() or begin transactions in most cases. For example, if you create or update multiple entities in an app service method, they either all succeed or all fail as a unit. This behavior is there “for free”, whereas in raw ASP.NET Core you’d be writing try/catch and transaction code around such operations. (ABP even avoids opening transactions on read-only GET requests by default for performance.)
• Global Exception Handling: No need to write a global exception filter – ABP provides one. If an unhandled exception occurs in an API endpoint, ABP’s exception handling system catches it and returns a standardized error response in JSON. It also maps known exception types to appropriate HTTP status codes and can localize error messages. This means your client applications always get a clean, consistent error format (with an error code, message, validation details, etc.) instead of ugly stack traces or HTML error pages. Internally, ABP logs the error details and hides the sensitive info from the client by default. Essentially, you get production-ready error handling without writing it yourself.
• Localization & Multi-Language Support: ABP’s localization system is built on the .NET localization extension but adds convenient enhancements. It automatically determines the user’s language/culture for each request (by checking the browser or tenant settings) and you can define localization resources in JSON files easily. ABP supports database-backed translations via the Language Management module as well. From day one, your app is ready to be translated – even exception messages and validation errors are localization-friendly. The default project template sets up a default resource and uses it for all framework-provided texts, meaning things like error messages or menu items are already localized (and you can add new languages through the UI if you include the module). In short, ABP bakes in multi-lingual capabilities so you don’t have to internationalize your app from scratch.
• Background Jobs: Need to run tasks in the background (e.g. send emails, generate reports) without blocking the user? ABP has a built-in background job infrastructure. You can simply implement a job class and enqueue it via IBackgroundJobManager. By default, jobs are persisted and executed, and ABP has providers to integrate with popular systems like Hangfire, RabbitMQ and Quartz if you need scalability. For example, sending an email after a user registers can be offloaded to a background job with one method call. ABP will handle retries on failure and storing the job info. This saves you the effort of configuring a separate job runner or scheduler – it’s part of the framework.
• Security & Defaults: ABP comes with sensible security defaults. It’s integrated with ASP.NET Core Identity, so password policies, lockout on multiple failed logins, and other best practices are in place by default. The framework also adds standard security headers to HTTP responses (against XSS, clickjacking, etc.) through its startup configuration. Additionally, ABP’s permission system is pre-configured: every module brings its own permission definitions, and you can easily check permissions with an attribute or method call. There’s even a built-in Permission Management UI (if you include the module) where you can grant or revoke permissions per role or user at runtime. All these defaults mean a lot of the “boring” but critical security work is done for you.
• Paging & Query Limiting: ABP encourages efficient data access patterns. For list endpoints, the framework DTOs usually include paging parameters (MaxResultCount, SkipCount), and if you don't specify them, ABP will assume default values (often 10). ABP also enforces an upper limit on how many records can be requested in a single call, preventing potential performance issues from overly large queries. This protects your application from accidentally pulling thousands of records in one go. Of course, you can configure or override these limits, but the safe defaults are there to protect your application.

That’s a long list – and it’s not even exhaustive – but the pattern is clear. ABP spares you from writing a lot of infrastructure and “glue” code. And if you do need multi-tenancy (or any of these advanced features), the time savings grow even more. These out-of-the-box capabilities let you focus on your business logic, since the baseline features are already in place. Next, let’s zoom in on a couple of these areas (like multi-tenancy and security) that typically cause headaches in pure ASP.NET Core but are a breeze with ABP.

Seamless Multi-Tenancy: Scaling Without the Headaches

Multi-tenant architecture – supporting multiple isolated customers (tenants) in one application – is notoriously tricky to implement from scratch. You have to partition data per tenant, ensure no cross-tenant data leaks, manage connection strings if using separate databases, and adapt authentication/authorization to be tenant-aware. ABP Framework makes multi-tenancy almost trivial in comparison.

Out of the box, ABP supports both approaches to multi-tenancy: single database with tenant segregation and separate databases per tenant, or even a hybrid of the two. If you go the single database route, as many SaaS apps do for simplicity, ABP will ensure every entity that implements the tenant interface (IMultiTenant) gets a TenantId value and is automatically filtered. As we touched on earlier, you don’t have to manually add .Where(t => t.TenantId == currentTenant.Id) on every query – ABP’s data filter does that behind the scenes based on the logged-in user’s tenant. If a user from Tenant A tries to access Tenant B’s data by ID, they simply won’t find it, because the filter is in effect on all repositories. Similarly, when saving data, ABP sets the TenantId for you. This isolation is enforced at the ORM level by ABP’s infrastructure.

For multiple databases, ABP’s SaaS (Software-as-a-Service) module handles tenant management. At runtime, the framework can switch the database connection string based on the tenant context. In the ABP startup template, there’s a “tenant management” UI that lets an admin add new tenants and specify their connection strings. If a connection string is provided, ABP will use that database for that tenant’s data. If not, it falls back to the default shared database. Remarkably, from a developer’s perspective, the code you write is the same in both cases – ABP abstracts the difference. In practice, you just write repository queries as usual; ABP will route those to the appropriate place and filter as needed.

Another pain point that ABP solves is making other subsystems tenant-aware. For example, ASP.NET Core Identity (for user accounts) isn’t multi-tenant by default, and neither is Keycloak, IdentityServer or OpenIddict (for authentication). ABP takes care of configuring these to work in a tenant context. When a user logs in, they do so with a tenant domain or tenant selection, and the identity system knows about the tenant. Permissions in ABP are also tenant-scoped by default – a tenant admin can only manage roles/permissions within their tenant, for instance. ABP’s modules are built to respect tenant boundaries out-of-the-box.

What does all this mean for you? It means you can offer a multi-tenant SaaS solution without writing the bulk of the isolation logic. Instead of spending weeks on multi-tenancy infrastructure, you essentially flip a switch in ABP (enable multi-tenancy, use the SaaS module) and focus on higher-level concerns.

Security That Works Without the Pain

Security is one area you do not want to get wrong. With plain ASP.NET Core, you have great tools (Identity, etc.) at your disposal, but a lot of configuration and integration work to tie them together in a full application. ABP takes the sting out of implementing security by providing a comprehensive, pre-integrated security model.

To start, ABP’s application templates include the Identity Module, which is a ready-made integration of ASP.NET Core Identity (the membership system) with ABP’s framework. You get user and role entities extended to fit in ABP’s domain model, and a UI for user and role management. All the heavy lifting of setting up identity tables, password hashing, email confirmation, two-factor auth, etc. is done. The moment you run an ABP application, you can log in with the seeded admin account and manage users and roles through a built-in administration page. This would take significant effort to wire up yourself in a new ASP.NET Core app; ABP gives it to you out-of-the-box.

Permission management is another boon. In an ABP solution, you don’t have to hard-code what each role can do – instead, ABP provides a declarative way to define permissions and a UI to assign those permissions to roles or users. The Permission Management module’s UI allows dynamic granting/revoking of permissions. Under the hood, ABP’s authorization system will automatically check those permissions when you annotate your application services or controllers with [Authorize] and a policy name (the policy maps to a permission). For example, you might declare a permission Inventory.DeleteProducts. In your ProductAppService’s DeleteAsync method, you add [Authorize("Inventory.DeleteProducts")]. ABP will ensure the current user has that permission (through their roles or direct assignment) before allowing the method to execute. If not, it throws a standardized authorization exception. This is standard ASP.NET Core policy-based auth, but ABP streamlines defining and managing the policies by its permission system. The result: secure by default – it’s straightforward to enforce role-based access control throughout your application, and even non-developers (with access to the admin UI) can adjust permissions as requirements evolve.

We already discussed CSRF protection, but it’s worth reiterating in the security context: ABP saves you from common web vulnerabilities by enabling defenses by default. Anti-forgery tokens are automatic, and output encoding (to prevent XSS) is naturally handled by using Razor Pages or Angular with proper binding (framework features that ABP leverages). ABP also sets up ASP.NET Core’s Data Protection API for things like cookie encryption and CSRF token generation behind the scenes in its startup, so you get a proper cryptographic key management for free.

Another underappreciated aspect is exception shielding. In development, you want to see detailed errors, but in production you should not reveal internal details (stack traces, etc.) to the client. ABP’s exception filter will output a generic error message to the client while logging the detailed exception on the server. This prevents information leakage that attackers could exploit, without you having to configure custom middleware or filters.

On the topic of authentication: ABP supports modern authentication scenarios too. If you want to build a microservice or single-page app (SPA) architecture, ABP provides modules for OpenID Connect and OAuth2 protocol implementations. The ABP Commercial version even provides an OpenIddict setup out-of-the-box for issuing JWTs to SPAs or mobile apps. This means you can stand up a secure token service and resource servers with minimal configuration. With ABP, much of the configuration (clients, scopes, grants) is abstracted by the framework.

In short, ABP’s approach to security is holistic and follows the mantra of secure by default. New ABP developers are often pleasantly surprised that they didn’t have to spend days on user auth or protecting API endpoints – it’s largely handled. Of course, you still design your authorization logic (defining who can do what), but ABP provides the scaffolding to enforce it consistently. The painful parts of security – getting the plumbing right – are taken care of, so you can focus on the policies and rules that matter for your domain. This dramatically lowers the risk of security holes compared to rolling it all yourself.

Customization Without Chaos

With all this magic happening automatically, you might wonder: “What if I need to do it differently? Can I customize or override ABP’s behavior?” The answer is a resounding yes. ABP is designed with extension points and configurability in mind, so you can change the defaults without hacking the framework. This is important for keeping your project maintainable – you get ABP’s benefits, but you’re not boxed in when requirements demand a change.

One way ABP enables customization is through its powerful dependency injection system and the modular structure. Because each feature is delivered via services (interfaces and classes) in DI, you can replace almost any ABP service with your own implementation if needed. For example, if you want to change how the IdentityUserAppService (the service behind user management) works, you can create your own class inheriting or implementing the same interface, and register it with Dependency(ReplaceServices = true). ABP will start using your class in place of the original. This is an elegant way to override behavior without modifying ABP’s source – keeping you on the upgrade path for new versions. ABP’s team intentionally makes most methods virtual to support overriding in derived classes. This means you can subclass an ABP application service or domain service and override just the specific method you need to change, rather than writing a whole service from scratch.

Beyond swapping out services, ABP offers configuration options for its features. Virtually every subsystem has an options class you can configure in your module startup. Not liking the 10-item default page size? You can change the default MaxResultCount. Want to disable a filter globally? You can toggle, say, soft-delete filtering off by default using AbpDataFilterOptions. Need to turn off auditing for certain operations? Configure AbpAuditingOptions to ignore them. These options give you a lot of control to tweak ABP’s behavior. And because they’re central configurations, you aren’t scattering magic numbers or settings throughout your code – it’s a structured approach to customization.

Another area is UI and theming. ABP’s UI (if you use the integrated UI) is also modular and replaceable. You can override Razor components or pages from a module by simply re-declaring them in your web project. For instance, if you want to modify the login page from the Account module, you can add a Razor page with the same path in your web layer – ABP will use yours instead of the default. The documentation has guidance on how to override views, JavaScript, CSS, etc., in a safe manner for Angular, Blazor, and MVC. The LeptonX theme that ABP uses can be customized via SCSS variables or entirely new theme derivations. The key point is, you’re never stuck with the “out-of-the-box” look or logic if it doesn’t fit your needs. ABP gives you the foundation, and you’re free to build on top of it or change it.

The best part? These customizations stay clean and organized. ABP's extension patterns prevent your project from becoming a mess of patches. When ABP releases updates, your overrides remain intact – no more copy-pasting framework code or dealing with merge conflicts. You get ABP's smart defaults plus the freedom to customize when needed.

Ecosystem Power: ABP’s Tools, Templates, and Integrations

ABP is more than just a runtime framework; it’s surrounded by an ecosystem of tools and libraries that amplify productivity. We’ve touched on a few (like the ABP Suite code generator), but let’s look at the broader ecosystem that comes with ABP.

• Project Templates: ABP provides multiple startup templates (via the ABP CLI or Studio) for different architectures – from a simple monolithic web app to a layered modular monolith, or even a microservice-oriented solution with multiple projects pre-configured. These templates are not empty skeletons; they include working examples of authentication, a UI theme, navigation, and so on for your own modules. The microservice template, for instance, sets up separate identity, administration, and SaaS services with communication patterns already wired. Using these templates can save you a huge amount of setup time and ensure you follow best practices from the get-go.
• ABP CLI: The command-line tool abp is a developer’s handy companion. With it, you can generate new solutions or modules, add package references, update your ABP version, and even client proxy generations with simple commands.
• ABP Studio: It is a cross-platform desktop environment designed to make working with ABP solutions smoother and more insightful. It provides a unified UI to create, run, monitor, and manage your ABP projects – whether you're building a monolith or a microservice system. With features like a real-time Application Monitor, Solution Runner, and Kubernetes integration, it brings operational visibility and ease-of-use to development workflows. Studio also includes tools for managing modules, packages, and even launching integrated tools like ABP Suite – all from a single place. Think of it as a control center for your ABP solutions.
• ABP Suite: It is a powerful visual tool (included in PRO licenses) that helps you generate full-stack CRUD pages in minutes. Define your entities, their relationships, and hit generate – ABP Suite scaffolds everything from the database model to the HTTP APIs, application services, and UI components. It supports one-to-many and many-to-many relationships, master-detail patterns, and even lets you generate from existing database tables. Developers can customize the generated code using predefined hook points that persist across regenerations.
• 3rd-Party Integrations: Modern applications often need to integrate with messaging systems, distributed caching, search engines, etc. ABP recognizes this and provides integration packages for many common technologies. Want to use RabbitMQ for event bus or background jobs? ABP has you covered. The same goes for others: ABP has modules or packages for Redis caching, Kafka distributed event bus, SignalR real-time hubs, Twilio SMS, Stripe payments, and more. Each integration is done in a way that it feels like a natural extension of the ABP environment (for example, using the same configuration system and dependency injection). This saves you from writing repetitive integration code or dealing with each library’s nuances in every project.
• UI Themes and Multi-UI Support: ABP comes with a modern default theme (LeptonX) for web applications, and it supports Angular, MVC/Razor Pages and Blazor out-of-the-box. If you prefer Angular for frontend, ABP offers an Angular UI package that works with the same backend. There’s also support for mobile via React Native or MAUI templates. The ability to switch UI front-ends (or even support multiple simultaneously, e.g. an Angular SPA and a Blazor server app using the same API) is facilitated by ABP’s API and authentication infrastructure. This dramatically reduces the friction when setting up a new client application – you don’t have to hand-roll API clients or auth flows.
• Community and Samples: While not a tool per se, the ABP community is part of the ecosystem and adds a lot of value. There are official sample projects (like eShopOnAbp, a full microservice reference application) and many community-contributed modules on GitHub. The consistency of ABP’s structure means community modules or examples are easier to understand and plug in. Being in a community where “everyone follows similar coding styles and principles” means code and knowledge are highly transferable. Developers share open source ABP modules (for example, there are community modules for things like blob storage management, setting UI, React frontend support, etc., beyond the official ones). This network effect is an often overlooked part of the ecosystem: as ABP’s adoption grows, so do the resources you can draw on, from Q&A to reusable code.

In summary, ABP’s ecosystem provides a full-platform experience. It’s not just the core framework, but also the tooling to work with that framework efficiently and the integrations to connect it with the wider tech world. By using ABP, you’re not piecing together disparate tools – you have a coherent set of solutions designed to work in concert. This is the kind of ecosystem that traditionally only large enterprises or opinionated tech stacks provided, but ABP makes it accessible in the .NET open-source space. It supercharges development in a way that goes beyond just writing code faster; it’s about having a robust infrastructure around your code, so you can deliver more value with less guesswork.

Developer Happiness: The Hidden Productivity Boost

All these features and time-savers aren’t just about checking off technical boxes – they have a profound effect on developer happiness and productivity. When a framework handles the heavy lifting and enforces good practices, developers can spend more time on interesting problems (and less on boilerplate or bug-hunting). ABP’s “hidden” features – the things that work without you even noticing – contribute to a less stressful development experience.

Think about the common sources of frustration in back-end development: security holes that come back to bite you, race conditions or transaction bugs, deployment issues because some configuration was missed, writing the same logging or exception handling code in every project… ABP’s approach preempts many of these. There’s confidence in knowing that the framework has built-in solutions for common pitfalls. For instance, you’re less likely to have a data inconsistency bug because ABP’s unit of work ensured all your DB operations were atomic. This confidence means developers can focus on delivering features rather than constantly firefighting or re-architecting core pieces.

Another aspect of developer happiness is consistency. ABP provides a uniform structure – every module has the same layering (Domain, Application, etc.), every web endpoint returns a standard response, and so on. Once you learn the patterns, you can navigate and contribute to any part of an ABP application with ease. New team members or even outside contributors ramp up faster because the project structure is familiar (it’s the ABP structure). This reduces the bus factor and onboarding time on teams – a source of relief for developers and managers alike.

Moreover, by taking away a lot of the “yak shaving” (the endless setup tasks), ABP lets you as a developer spend your energy on creative problem-solving and delivering value. It’s simply more fun to develop when you can swiftly implement a feature without being bogged down in plumbing code. The positive feedback loop of having working features quickly (thanks to things like ABP Suite, or just the rapid scaffolding of ABP) can be very motivating. It feels like you have an expert co-pilot who has already wired the security system, laid out the architecture, and packed the toolkit with everything you need – so you can drive the project forward confidently.

Finally, the community support adds to this happiness. There’s a thriving Discord server and forum where ABP developers help each other. Since ABP standardizes a lot, advice from one person’s experience often applies directly to your scenario. That sense of not being alone when you hit a snag – because others likely encountered and solved it – reduces anxiety and speeds up problem resolution. It’s the kind of developer experience where things “just work,” and when they occasionally don’t, you have a clear path to figure it out (good docs, support, community). In the daily life of a software developer, this can make a huge difference.

In conclusion, ABP’s multitude of behind-the-scenes features are not about making the framework look impressive on paper – they’re about making you, the developer, more productive and happier in your job. By handling the boring, complex, or repetitive stuff, ABP lets you focus on building great software. It’s like having a teammate who has already done half the work before you even start coding. When you combine that with ABP’s extensibility and strong foundation, you get a framework that not only accelerates development but also encourages you to do things the right way. For experienced engineers and newcomers alike, that can indeed feel a bit like magic. But now that we’ve uncovered the “magic tricks” ABP is doing under the hood, you can fully appreciate how it all comes together – and decide if this framework’s approach aligns with your goals of building applications faster, smarter, and with fewer headaches. Chances are, once you experience the productivity boost of ABP, you won’t want to go back. Happy coding!

In modern web applications, there are scenarios where you need to determine which database to connect to at runtime rather than at compile time. This could be for multi-tenant applications, environment-specific configurations, or modular architectures where different parts of your application connect to different databases.

In this article, I'll walk you through creating a practical solution for dynamic connection string resolution by building a real ASP.NET Core application. We'll start with a standard template and gradually implement our own IConnectionStringResolver pattern.

Note: The code examples are simplified for demonstration purposes. Production applications require additional error handling, logging, and caching.

The Scenario: Building a Multi-Tenant Web Application

Let's imagine we're building a SaaS application where different tenants can have their own databases. Some tenants share a common database, while premium tenants get their own dedicated database for better performance and data isolation.

Our requirements:

• Default behavior: Use the standard connection string
• Multi-tenant support: Route tenants to their specific databases
• Fallback mechanism: If a tenant-specific database isn't available, use the default
• Simple tenant identification: Use query parameters for this example

Note: We're building this from scratch to understand the concepts, but ABP Framework already handles all of this automatically - and does it much better! It supports separate databases for each tenant, different connection strings for different modules, and automatic fallback when connections aren't found. See how comprehensive ABP's approach is in the Connection Strings documentation.

Step 1: Creating the Project

First, create a new ASP.NET Core Web App with Razor Pages and Individual Authentication:

dotnet new webapp --auth Individual -n DynamicConnectionDemo
cd DynamicConnectionDemo

When you open the project, you'll see the default connection in appsettings.json:

{
  "ConnectionStrings": {
    "DefaultConnection": "DataSource=app.db;Cache=Shared"
  }
}

And in Program.cs, you'll find the standard Entity Framework configuration:

var connectionString = builder.Configuration.GetConnectionString("DefaultConnection") ??  
                       throw new InvalidOperationException("Connection string 'DefaultConnection' not found.");  

builder.Services.AddDbContext<ApplicationDbContext>(options =>  
    options.UseSqlite(connectionString));  

builder.Services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)  
    .AddEntityFrameworkStores<ApplicationDbContext>();

Step 2: Testing the Base Application

Run the application and test the registration/login functionality to ensure everything works:

dotnet run

Navigate to the registration page, create an account, and verify that the basic authentication flow works correctly.

Building Our Connection String Resolver

Now let's implement our dynamic connection string resolver. We'll start by defining the interface and implementation.

Step 3: Creating the Interface

Create a new interface IConnectionStringResolver in Data folder:

public interface IConnectionStringResolver
{
    string Resolve(string connectionName = null);
}

Step 4: Implementing the Resolver

Create the ConnectionStringResolver class in Data folder:

public class ConnectionStringResolver : IConnectionStringResolver
{
    private readonly IConfiguration _configuration;
    private readonly IHttpContextAccessor _httpContextAccessor;

    public ConnectionStringResolver(
        IConfiguration configuration,
        IHttpContextAccessor httpContextAccessor)
    {
        _configuration = configuration;
        _httpContextAccessor = httpContextAccessor;
    }

    public string Resolve(string connectionName = null)
    {
        // Add caching logic here if needed
        return GetConnectionString(connectionName);
    }

    private string GetConnectionString(string connectionName)
    {
        // Try to get given named connection string
        if (!string.IsNullOrEmpty(connectionName))
        {
            var connectionString = _configuration.GetConnectionString(connectionName);
            if (!string.IsNullOrEmpty(connectionString))
            {
                return connectionString;
            }
        }

        // Try to get tenant-specific connection string (for multi-tenant apps)
        var tenantId = GetCurrentTenantIdOrNull();
        if (!string.IsNullOrEmpty(tenantId))
        {
            var tenantConnectionString = _configuration.GetConnectionString($"Tenant_{tenantId}");
            if (!string.IsNullOrEmpty(tenantConnectionString))
            {
                return tenantConnectionString;
            }
        }

        // Fallback to default connection string
        return _configuration.GetConnectionString("DefaultConnection");
    }

    private string? GetCurrentTenantIdOrNull()
    {
        var context = _httpContextAccessor.HttpContext;
        if (context == null)
        {
            return null;
        }

        // Adds support for subdomain-based, route-based, or header-based tenant identification
        
        // Example: Query string-based tenant identification
        if (context.Request.Query.ContainsKey("tenant"))
        {
            return context.Request.Query["tenant"].ToString();
        }

        return null;
    }
}

Step 5: Registering the Service

Add the service registration to your Program.cs:

builder.Services.AddScoped<IConnectionStringResolver, ConnectionStringResolver>();

Step 6: Updating the DbContext Configuration

Now we need to modify our Program.cs to use the resolver instead of the static connection string.

Replace this code:

var connectionString = builder.Configuration.GetConnectionString("DefaultConnection") ??  
                       throw new InvalidOperationException("Connection string 'DefaultConnection' not found.");  
builder.Services.AddDbContext<ApplicationDbContext>(options =>  
    options.UseSqlite(connectionString));

With this simpler version:

builder.Services.AddDbContext<ApplicationDbContext>();

Step 7: Modifying ApplicationDbContext

Update your ApplicationDbContext in Data folder to use the resolver:

public class ApplicationDbContext : IdentityDbContext
{
    private readonly IConnectionStringResolver _connectionStringResolver;

    public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options, IConnectionStringResolver connectionStringResolver)
        : base(options)
    {
        _connectionStringResolver = connectionStringResolver;
    }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        if (!optionsBuilder.IsConfigured)
        {
            var connectionString = _connectionStringResolver.Resolve();
            optionsBuilder.UseSqlite(connectionString);
        }
    }
}

Step 8: Testing the Implementation

Let's add a simple way to see our resolver in action. Update your Pages/Index.cshtml:

@page
@model IndexModel
@inject IConnectionStringResolver ConnectionStringResolver

@{
    ViewData["Title"] = "Home page";
}

<div class="text-center">
    <h1 class="display-4">Welcome</h1>
    <p>Connection String: @ConnectionStringResolver.Resolve()</p>
</div>

Step 9: Adding Multi-Tenant Configuration

To test the multi-tenant functionality, add some tenant-specific connection strings to your appsettings.json:

{
  "ConnectionStrings": {
    "DefaultConnection": "DataSource=app.db;Cache=Shared",
    "Tenant_acme": "DataSource=acme.db;Cache=Shared",
    "Tenant_globex": "DataSource=globex.db;Cache=Shared"
  }
}

Step 10: Testing Multi-Tenant Functionality

Now run your application and test the multi-tenant functionality:

1. Default behavior: Visit https://localhost:5001/ - you should see the default connection string
2. Tenant-specific: Visit https://localhost:5001/?tenant=acme - you should see the ACME tenant's connection string
3. Another tenant: Visit https://localhost:5001/?tenant=globex - you should see the Globex tenant's connection string
4. Non-existent tenant: Visit https://localhost:5001/?tenant=unknown - you should see the default connection string (fallback behavior)

Note: The port number may be different on your system. Check the console output when you run dotnet run to see the actual URL.

Important: This demo shows that our connection string resolver is working correctly, but it only displays which connection string would be used. In a real application, thanks to our ApplicationDbContext modifications, the actual database operations would use the resolved connection string automatically. I kept this demo simple for clarity, but if you create actual tenant databases and test with real data operations, you'll see it works as expected.

Understanding the Implementation

Let's break down what we've accomplished:

Our resolver follows this priority order:

1. Named Connection: If a specific connection name is provided, use that
2. Tenant-Specific: Check for tenant-specific connection strings
3. Default Fallback: Use the default connection string

Production Note: This example uses query string parameters for simplicity. In production, you might use subdomains (acme.myapp.com), custom headers (X-Tenant-ID), route parameters, or JWT claims for tenant identification. Also consider adding caching, proper error handling and so on.

How ABP Framework Handles This

The approach we've implemented above is very similar to how ABP Framework handles dynamic connection strings. ABP provides a built-in IConnectionStringResolver that works almost identically to our custom implementation, but with additional enterprise features:

ABP's IConnectionStringResolver

ABP Framework includes a sophisticated connection string resolver that:

• Automatically handles multi-tenancy scenarios
• Supports module-specific connection strings out of the box
• Integrates seamlessly with ABP's configuration system
• Provides advanced caching and performance optimizations

// In ABP applications, you can simply inject IConnectionStringResolver
public class ProductService : ITransientDependency
{
    private readonly IConnectionStringResolver _connectionStringResolver;

    public ProductService(IConnectionStringResolver connectionStringResolver)
    {
        _connectionStringResolver = connectionStringResolver;
    }

    public async Task<string> GetConnectionStringAsync()
    {
        // ABP automatically handles tenant context, module resolution, and fallbacks
        return await _connectionStringResolver.ResolveAsync("ProductModule");
    }
}

ABP's version provides automatic tenant detection, module integration, and enterprise features out of the box.

Conclusion

The IConnectionStringResolver pattern provides a clean way to handle dynamic connection strings in ASP.NET applications. By centralizing connection string logic, you can easily support multi-tenant scenarios, environment-specific configurations, and modular architectures.

This pattern is particularly valuable for applications that need to scale and adapt to different deployment scenarios. Whether you implement your own resolver or use ABP Framework's built-in solution, this approach will make your application more flexible.

Further Reading

• Entity Framework Core Documentation
• Multi-tenant Applications with EF Core
• Connection Strings and Configuration in .NET
• ABP Framework Multi-Tenancy

In this article, I will show you how to integrate and use the OpenAI API with the ABP Framework. We will explore step-by-step how these technologies can work together to enhance your application with powerful AI capabilities, such as natural language processing, image generation, and more.

Creating an ABP Project

To begin integrating OpenAI API with ABP Framework, you first need to create an ABP project. Follow these steps to create and set up your ABP project:

Step 1: Install ABP CLI

The ABP CLI is a command-line interface tool that helps you create and manage ABP projects easily. To install the ABP CLI, run the following command in your terminal:

dotnet tool install -g Volo.Abp.Studio.Cli

Step 2: Create a New ABP Project

Once you have installed the ABP CLI, you can create a new ABP project using the following command:

abp new Acme.OpenAIIntegration -t app --ui-framework mvc --database-provider ef -dbms PostgreSQL --csf

This command will generate a complete ABP project with an MVC UI. The examples provided in this article make use of UI controllers for demonstration purposes. However, the same approach can easily be applied to other UI types supported by ABP, such as Blazor or Angular. You can find other options here.

OpenAI Integration Setup

To begin integrating OpenAI API with ABP Framework, follow these steps:

Step 1: Create an API Key

To use the OpenAI services, you first need an API key. To obtain one, first create a new OpenAI account or log in. Next, navigate to the API key page and select "Create new secret key", optionally naming the key. Make sure to save your API key somewhere safe and do not share it with anyone.

This key will be used to authenticate your application when making requests to the OpenAI endpoints.

Step 2: Adding Microsoft.Extensions.AI Package

To integrate OpenAI API with ABP, we use Microsoft.Extensions.AI. This package offers a unified API for integrating AI services, making it easy for developers to work with different AI providers. You can find more details in this blog post.

To begin integrating OpenAI API with ABP Framework, follow these steps:

1. Add the Microsoft.Extensions.AI and Microsoft.Extensions.AI.OpenAI (used to interact specifically with OpenAI services. Additionally, this package has alternatives like Azure OpenAI, Azure AI Inference, and Ollama, offering flexibility for developers to choose the AI provider that best fits their needs) packages:

dotnet add package Microsoft.Extensions.AI --prerelease
dotnet add package Microsoft.Extensions.AI.OpenAI --prerelease

2. Add the required configuration to the appsettings.json file located inside the Acme.OpenAIIntegration.Web project and dependencies to your ConfigureServices method:

"AI": {
    "OpenAI": {
        "Key": "YOUR-API-KEY",
        "Chat": {
            "ModelId": "gpt-4o-mini"
        }
    }
}

Replace the value of the Key with your OpenAI API key.

Important Security Note: Storing sensitive information like API keys in appsettings.json is not recommended due to security concerns. Please refer to the official Microsoft documentation for secure secret management best practices.

Next, add the following code to the ConfigureServices method in OpenAIIntegrationBlazorModule:

context.Services.AddSingleton(new OpenAIClient(configuration["AI:OpenAI:Key"]));
  
context.Services.AddChatClient(services =>  
    services.GetRequiredService<OpenAIClient>().AsChatClient(configuration["AI:OpenAI:Chat:ModelId"] ?? "gpt-4o-mini"));

Creating a Sample Page

To demonstrate the use of OpenAI API, let's create a page named Sample in the Acme.OpenAIIntegration.Web project:

Create a Sample folder under the Pages folder of the Acme.OpenAIIntegration.Web project. Add a new Razor Page by right-clicking the Sample folder then selecting Add > Razor Page. Name it Index.

Open the Index.cshtml and change the whole content as shown below:

Note: This example demonstrates a simple implementation of a sample page that interacts with the OpenAI API, covering chat, retrieval-augmented generation (RAG), and image generation features. Each example is explained in detail in the next section, so feel free to continue for a better understanding of the steps and logic involved.

@page
@model Acme.OpenAIIntegration.Web.Pages.Sample
@{
    ViewData["Title"] = "OpenAI API Demonstration";
}

<h1>@ViewData["Title"]</h1>

<br/><br/>

<div class="row">
    <div class="col-md-4">
        <h2>Chat Example</h2>
        <form method="post" asp-page-handler="Chat">
            <div class="form-group">
                <label asp-for="ChatInput">Enter your message:</label>
                <textarea asp-for="ChatInput" class="form-control" rows="4"></textarea>
            </div>
            <button type="submit" class="btn btn-primary mt-2">Send</button>
        </form>
        @if (!string.IsNullOrEmpty(Model.ChatResponse))
        {
            <h3 class="mt-3">Response:</h3>
            <p>@Model.ChatResponse</p>
        }
    </div>

    <div class="col-md-4">
        <h2>RAG Example</h2>
        <form method="post" asp-page-handler="RAG">
            <div class="form-group mt-2">
                <label asp-for="RAGQuery">Query:</label>
                <input asp-for="RAGQuery" class="form-control" />
            </div>
            <button type="submit" class="btn btn-primary mt-2">Ask</button>
        </form>
        @if (!string.IsNullOrEmpty(Model.RAGResponse))
        {
            <h3 class="mt-3">Result:</h3>
            <p>@Model.RAGResponse</p>
        }
    </div>

    <div class="col-md-4">
        <h2>Image Generation Example</h2>
        <form method="post" asp-page-handler="ImageGeneration">
            <div class="form-group">
                <label asp-for="ImagePrompt">Image Description:</label>
                <input asp-for="ImagePrompt" class="form-control" />
            </div>
            <button type="submit" class="btn btn-primary mt-2">Generate Image</button>
        </form>
        @if (Model.GeneratedImageBytes != null)
        {
            <h3 class="mt-3">Generated Image:</h3>
            <img src="https://raw.githubusercontent.com/abpframework/abp/dev/docs/en/Community-Articles/2024-12-01-OpenAI-Integration/data%3Aimage/png%3Bbase64%2C%40Convert.ToBase64String%28Model.GeneratedImageBytes%29" alt="Generated image" class="img-fluid mt-2" />
        }
    </div>
</div>

Index.cshtml.cs content should be like that:

using System;
using System.ClientModel;
using System.IO;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.RazorPages;
using Microsoft.Extensions.AI;
using OpenAI;
using OpenAI.Assistants;
using OpenAI.Files;
using OpenAI.Images;

namespace Acme.OpenAIIntegration.Web.Pages;

public class Sample : PageModel
{
    [BindProperty]
    public string ChatInput { get; set; }
    public string ChatResponse { get; set; }

    [BindProperty]
    public string RAGQuery { get; set; }
    public string RAGResponse { get; set; }

    [BindProperty]
    public string ImagePrompt { get; set; }
    public byte[] GeneratedImageBytes { get; set; }
    
    private readonly IChatClient _chatClient;
    private readonly OpenAIClient _openAiClient;

    public Sample(
        IChatClient chatClient,
        OpenAIClient openAiClient)
    {
        _chatClient = chatClient;
        _openAiClient = openAiClient;
    }

    public async Task<IActionResult> OnPostChatAsync()
    {
        ChatResponse = $"Chat response: {(await _chatClient.CompleteAsync(ChatInput)).Message}";
        return Page();
    }

    public async Task<IActionResult> OnPostRAGAsync()
    {
#pragma warning disable OPENAI001
        var fileClient = _openAiClient.GetOpenAIFileClient();
        var assistantClient = _openAiClient.GetAssistantClient();

        using var document = BinaryData.FromBytes(GetExceptionHandlingDocumentContent().ToArray()).ToStream();
        var exceptionHandlingDoc = await fileClient.UploadFileAsync(
            document,
            "ExceptionHandling.md",
            FileUploadPurpose.Assistants);

        AssistantCreationOptions assistantOptions = new()
        {
            Name = "Exception Handling Assistant",
            Instructions =
                """
                This assistant helps you with exception handling in ABP Framework. You can ask questions about exception handling and get answers.

                - Do not make any assumptions when asked for information that is not in the document
                - Give the most accurate information possible
                - Give short(max 1-2 sentence) and concise answers
                - Do not provide file citations
                """,

            Tools =
            {
                new FileSearchToolDefinition(),
            },
            ToolResources = new()
            {
                FileSearch = new()
                {
                    NewVectorStores =
                    {
                        new VectorStoreCreationHelper([exceptionHandlingDoc.Value.Id]),
                    }
                }
            },
        };

        var assistant = await assistantClient.CreateAssistantAsync("gpt-4o", assistantOptions);

        ThreadCreationOptions threadOptions = new()
        {
            InitialMessages = { RAGQuery }
        };

        ThreadRun threadRun = assistantClient.CreateThreadAndRun(assistant.Value.Id, threadOptions);

        do
        {
            Thread.Sleep(TimeSpan.FromSeconds(1));
            threadRun = assistantClient.GetRun(threadRun.ThreadId, threadRun.Id);
        } while (!threadRun.Status.IsTerminal);

        CollectionResult<ThreadMessage> messages
            = assistantClient.GetMessages(threadRun.ThreadId,
                new MessageCollectionOptions() { Order = MessageCollectionOrder.Ascending });

        var response = new StringBuilder();

        foreach (var message in messages)
        {
            response.AppendLine($"[{message.Role.ToString().ToUpper()}]: ");
            foreach (var contentItem in message.Content)
            {
                if (!string.IsNullOrEmpty(contentItem.Text))
                {
                    response.AppendLine(contentItem.Text);

                    if (contentItem.TextAnnotations.Count > 0)
                    {
                        response.AppendLine("");
                    }
                }
            }

            response.AppendLine("");
#pragma warning restore OPENAI001
        }
        
        RAGResponse = response.ToString();
        
        return Page();
    }

    public async Task<IActionResult> OnPostImageGenerationAsync()
    {
        var client = _openAiClient.GetImageClient("dall-e-3");

        var image = await client.GenerateImageAsync(ImagePrompt, new ImageGenerationOptions
        {
            ResponseFormat = GeneratedImageFormat.Bytes
        });
        
        var imageBytes = image.Value.ImageBytes;
        
        using var memoryStream = new MemoryStream();
        await imageBytes.ToStream().CopyToAsync(memoryStream);
        GeneratedImageBytes = memoryStream.ToArray();
        
        return Page();
    }

    public ReadOnlySpan<byte> GetExceptionHandlingDocumentContent()
    {
        return """
               # Exception Handling

               ABP provides a built-in infrastructure and offers a standard model for handling exceptions.

               * Automatically **handles all exceptions** and sends a standard **formatted error message** to the client for an API/AJAX request.
               * Automatically hides **internal infrastructure errors** and returns a standard error message.
               * Provides an easy and configurable way to **localize** exception messages.
               * Automatically maps standard exceptions to **HTTP status codes** and provides a configurable option to map custom exceptions.

               ## Automatic Exception Handling

               `AbpExceptionFilter` handles an exception if **any of the following conditions** are met:

               * Exception is thrown by a **controller action** which returns an **object result** (not a view result).
               * The request is an AJAX request (`X-Requested-With` HTTP header value is `XMLHttpRequest`).
               * Client explicitly accepts the `application/json` content type (via `accept` HTTP header).

               If the exception is handled it's automatically **logged** and a formatted **JSON message** is returned to the client.
               
               ## Business Exceptions
               
               Most of your own exceptions will be business exceptions. The `IBusinessException` interface is used to mark an exception as a business exception.
               
               `BusinessException` implements the `IBusinessException` interface in addition to the `IHasErrorCode`, `IHasErrorDetails` and `IHasLogLevel` interfaces. The default log level is `Warning`.
               
               Usually you have an error code related to a particular business exception. For example:
               
               ````C#
               throw new BusinessException(QaErrorCodes.CanNotVoteYourOwnAnswer);
               ````

               ### User Friendly Exception
               
               If an exception implements the `IUserFriendlyException` interface, then ABP does not change it's `Message` and `Details` properties and directly send it to the client.
               
               `UserFriendlyException` class is the built-in implementation of the `IUserFriendlyException` interface. Example usage:
               
               ````C#
               throw new UserFriendlyException(
                   "Username should be unique!"
               );
               ````
               * The `IUserFriendlyException` interface is derived from the `IBusinessException` and the `UserFriendlyException` class is derived from the `BusinessException` class.
    
               """u8;
    }
}

Running the Application

After completing the setup, you can run the application using the following command:

 dotnet run --project ./src/Acme.OpenAIIntegration.Web

Once the application is running, open your browser and navigate to /Sample. You should see the Sample page we created, which contains sections for Chat, RAG (Retrieval-Augmented Generation), and Image Generation. You can find the screenshot of the page below:

Examples Overview

To showcase the integration of the OpenAI API with the ABP Framework, we implemented three different examples:

1. Chat Example: This example demonstrates how to use OpenAI's chat capabilities by allowing users to enter a message and receive an AI-generated response. The implementation involves setting up a simple form on the Sample page where users can input their message. The form submission triggers the OnPostChatAsync method, which uses the IChatClient to generate a response.

2. Retrieval-Augmented Generation (RAG) Example: In this example, we use OpenAI to answer user queries by referencing custom documents uploaded to the OpenAI API. The implementation involves uploading a document using the OpenAIFileClient and creating an assistant with specific instructions to handle the uploaded content. In this case, the document is a section from ABP's Exception Handling documentation, which includes examples on how ABP handles exceptions, user-friendly error messages, and business exceptions. Users can input their query on the Sample page, and the OnPostRAGAsync method processes the query to generate precise answers based on the document content. If users ask questions that are not covered in the document, the assistant clearly indicates that the information is not available, as per the instructions provided. For example, when asked about Object Extensions, the response begins with: "The uploaded document does not contain information about Object Extensions...". This demonstrates how the assistant adheres to the provided instructions. You can also find this example illustrated in the GIF below.

3. Image Generation Example: This example leverages the DALL-E model to generate images based on user-provided prompts. On the Sample page, users can provide a description of the image they want to generate, and the OnPostImageGenerationAsync method uses the OpenAIClient to generate the image.

Conclusion

In this article, we covered how to integrate the OpenAI API with the ABP Framework by creating a sample project, setting up the OpenAI services, and implementing examples for conversational AI, knowledge-based assistance, and image generation. By following these steps, you can add powerful AI-driven capabilities to your application, making it more interactive, intelligent, and capable of meeting user needs effectively.

In this article, we will explore the new features introduced in EF Core 9, specifically focusing on Read-only Primitive Collections. EF Core 8 introduced support for mapping arrays and mutable lists of primitive types, and you can read more about it here. This has been expanded in EF Core 9 to include read-only collections/lists. Specifically, EF Core 9 supports collections typed as IReadOnlyList, IReadOnlyCollection, or ReadOnlyCollection.

Introduction to EF Core 9 Read-only Primitive Collections

Entity Framework Core 9 introduces several enhancements, one of which is the support for Read-only Primitive Collections. This feature aims to provide better support for scenarios where collections of primitive types, such as int, string, or bool, need to be used in a read-only manner in your entity classes. Previously, developers had to use complex workarounds to ensure collections couldn't be modified, but EF Core 9 now provides a simpler, built-in solution to handle this more effectively.

Why Read-only Primitive Collections Matter

Read-only Primitive Collections are particularly useful when you need to guarantee the integrity of certain data within your entities. For example, imagine you have a Car entity that has a collection of Colors, represented as a set of enums. You might not want these colors to be modified after they're initially set, ensuring that any business logic reliant on these values remains consistent.

EF Core 9 introduces a convenient way to define these collections as read-only, helping developers maintain stricter control over their data.

How It Works

Defining a read-only primitive collection is quite straightforward in EF Core 9. You can use the IReadOnlyList<T>, IReadOnlyCollection<T>, or ReadOnlyCollection<T> types to declare your properties, ensuring a consistent read-only behavior. This helps maintain data integrity by preventing modifications after the collection is set. Below is an example that includes a Car class and a Color enum. The Car class has a Colors property that holds a read-only list of available colors, ensuring that these values cannot be modified after being initially set:

public enum Color
{
    Black,
    White,
    Red,
    Blue
}

public class Car
{
    public int Id { get; set; }
    public string Brand { get; set; }
    public string Model { get; set; }
    public IReadOnlyList<Color> Colors { get; private set; } = new List<Color> { Color.Black, Color.White }.AsReadOnly();
  
    protected Car()
    {
    	/* This constructor is for deserialization / ORM purpose */
    }

    public Car(string brand, string model, IEnumerable<Color> colors)
    {
        Brand = brand;
        Model = model;
        Colors = colors.ToList().AsReadOnly();
    }
}

In the example above, Colors is defined as a read-only list, preventing any accidental modifications once it is set. This ensures that data integrity is maintained without the need for manual validation.

To query cars with specific colors, you can use the following example:

var colors = new List<Color> { Color.Black, Color.White };
var cars = await context.Cars
    .Where(c => c.Colors.Intersect(colors).Any())
    .ToListAsync();

The query selects all cars that have any of the specified colors in their Colors collection.

The SQL result looks like this; as you can see, it sends colors as parameters instead of adding them inline. It also uses the json_each function to deserialize on the database side:

SELECT "c"."id",
       "c"."brand",
       "c"."colors",
       "c"."model"
FROM   "cars" AS "c"
WHERE  EXISTS (SELECT 1
               FROM   (SELECT "c0"."value"
                       FROM   Json_each("c"."colors") AS "c0"
                       INTERSECT
                       SELECT "c1"."value"
                       FROM   Json_each(@__colors_0) AS "c1") AS "i") 

Conclusion

Read-only primitive collections make it easier to enforce data integrity by preventing changes to your collection data. This feature helps simplify your code while ensuring that critical parts of your data remain consistent.

References

• https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-9.0/whatsnew#read-only-primitive-collections
• https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-8.0/whatsnew#primitive-collections
• https://abp.io/community/articles/ef-core-8-primitive-collections-ttn5b6xp

Aspire is an opinionated, cloud-ready stack designed for building observable, production-ready, and distributed applications. On the other hand, the ABP framework offers a complete, modular and layered software architecture based on Domain Driven Design principles and patterns. This guide explores how to combine Aspire with ABP, enabling developers to create observable, and feature-rich applications.

When to Use Aspire?

Using Aspire with the ABP framework can be beneficial in various scenarios where you need to combine the strengths of both technologies. Here are some situations when using Aspire with ABP can be advantageous:

• Enterprise Web Applications: ABP is well-suited for building enterprise web applications with its opinionated architecture and best practices. When combined with Aspire, you can leverage ABP's features for rapid development of user interfaces, backend services, and business logic while benefiting from Aspire's cloud-native capabilities and observability features.
• Observability and Monitoring: Aspire's emphasis on observability, including logging, monitoring, and tracing, can enhance ABP applications by providing deeper insights into system behavior, performance metrics, and diagnostics, which is key for maintaining and optimizing enterprise-grade applications.

Creating a new ABP Solution

To demonstrate the usage of Aspire with the ABP framework, I've created an ABP solution. If you want to create the same solution from scratch, follow the steps below:

Install the ABP CLI if you haven't installed it before:

dotnet tool install -g Volo.Abp.Cli

Create a new solution with the ABP framework's Application Startup Template with Tiered MVC UI and EF Core database:

abp new AspirationalAbp -u mvc --database-provider ef -dbms PostgreSQL --csf --tiered

The startup template selection matters for this article. I chose these options so that the demo solution can cover complex scenarios.

Disclaimer-I: This article is based on version 8.0.1 of Aspire and version 8.2.0 of ABP Framework.

Disclaimer-II: ABP and Aspire may not be fully compatible in some respects. This article aims to explain how these two technologies can be used together in the simplest way possible, even if they are not fully compatible.

Add Aspire

After creating the solution, run the following commands in the src folder of your solution to add Aspire:

// Adding AppHost
dotnet new aspire-apphost -n AspirationalAbp.AppHost
dotnet sln ../AspirationalAbp.sln add ./AspirationalAbp.AppHost/AspirationalAbp.AppHost.csproj

// Adding ServiceDefaults
dotnet new aspire-servicedefaults -n AspirationalAbp.ServiceDefaults
dotnet sln ../AspirationalAbp.sln add ./AspirationalAbp.ServiceDefaults/AspirationalAbp.ServiceDefaults.csproj

These commands add two new projects to the solution:

• AspirationalAbp.AppHost: An orchestrator project designed to connect and configure the different projects and services of your app.
• AspirationalAbp.ServiceDefaults: An Aspire shared project to manage configurations that are reused across the projects in your solution related to resilience, service discovery, and telemetry.

We have added Aspire to our ABP based solution, but we have not registered our projects in the Aspire orchestration. Now, let's enroll our projects, which implement the db migrator, web user interface, API, and auth, in Aspire orchestration.

Registering projects to Aspire orchestration

First of all, we need to add the reference of related projects to the AspirationalAbp.AppHost project. For this, add the following ItemGroups to the AspirationalAbp.AppHost/AspirationalAbp.AppHost.csproj file:

<ItemGroup>  
  <ProjectReference Include="..\AspirationalAbp.AuthServer\AspirationalAbp.AuthServer.csproj" />  
  <ProjectReference Include="..\AspirationalAbp.HttpApi.Host\AspirationalAbp.HttpApi.Host.csproj" />  
  <ProjectReference Include="..\AspirationalAbp.Web\AspirationalAbp.Web.csproj"/>  
  <ProjectReference Include="..\AspirationalAbp.DbMigrator\AspirationalAbp.DbMigrator.csproj" />  
</ItemGroup>  
  
<ItemGroup>  
  <PackageReference Include="Aspire.Hosting.PostgreSQL" Version="8.0.1" />  
  <PackageReference Include="Aspire.Hosting.Redis" Version="8.0.1" />  
</ItemGroup>

With the first ItemGroup, we added the references of AuthServer, HttpApi.Host, Web, and DbMigrator projects to the app host project. So, we can orchestrate them within the app model.

With the second ItemGroup, to model the PostgreSQL server resource and Redis resource in the app host, installed the Aspire.Hosting.PostgreSQL and Aspire.Hosting.Redis

Now let's update the Program class of the AspirationalAbp.AppHost project as follows:

using Microsoft.Extensions.Hosting;  
  
var builder = DistributedApplication.CreateBuilder(args);  
  
var postgres = builder  
    .AddPostgres("postgres")  
    .AddDatabase("AspirationalAbp");  
  
var redis = builder.AddRedis("redis");  
  
// DbMigrator  
if (builder.Environment.IsDevelopment())  
{  
    builder  
        .AddProject<Projects.AspirationalAbp_DbMigrator>("dbMigrator")  
        .WithReference(postgres, "Default")  
        .WithReference(redis, "Redis")   
        .WithReplicas(1);
}  
  
// AuthServer  
var authServerLaunchProfile = "AspirationalAbp.AuthServer";  
builder  
    .AddProject<Projects.AspirationalAbp_AuthServer>("authserver", launchProfileName: authServerLaunchProfile)  
    .WithExternalHttpEndpoints()  
    .WithReference(postgres, "Default")  
    .WithReference(redis);  
  
// HttpApi.Host  
var httpApiHostLaunchProfile = "AspirationalAbp.HttpApi.Host";  
builder  
    .AddProject<Projects.AspirationalAbp_HttpApi_Host>("httpapihost", launchProfileName: httpApiHostLaunchProfile)  
    .WithExternalHttpEndpoints()
    .WithReference(postgres, "Default")  
    .WithReference(redis);  
  
// Web  
builder  
    .AddProject<Projects.AspirationalAbp_Web>("web", "AspirationalAbp.Web")  
    .WithReference(redis);  
  
builder.Build().Run();

With the code above, the following operations were performed below:

1. Creates an IDistributedApplicationBuilder instance by calling DistributedApplication.CreateBuilder(args).
2. Adds PostgreSQL and the AspirationalAbp database.
3. Adds Redis.
4. Adds the DbMigrator project with references to PostgreSQL and Redis, ensuring one replica in development.
5. Adds the AuthServer project with external HTTP endpoints, referencing PostgreSQL and Redis.
6. Adds the HttpApi.Host project with external HTTP endpoints, referencing PostgreSQL and Redis.
7. Adds the Web project, referencing Redis.
8. Builds and runs the application.

Now let's make the projects we added to the app host compatible with Aspire.

Configuring Projects for Aspire

To make the AspirationalAbp.DbMigrator, AspirationalAbp.AuthServer, AspirationalAbp.HttpApi.Host, and AspirationalAbp.Web projects compatible with Aspire, we need to add and configure several packages. For that, we need to add the Aspire.StackExchange.Redis package to all these projects and the Aspire.Npgsql.EntityFrameworkCore.PostgreSQL package to the AspirationalAbp.EntityFrameworkCore project. Additionally, we will add the AspirationalAbp.ServiceDefaults reference to host projects except AspirationalAbp.DbMigrator. Also, we need to convert Serilog events into OpenTelemetry LogRecords, for that we will add a Serilog.Sinks.OpenTelemetry reference to host projects. Let's begin with configuring AspirationalAbp.DbMigrator.

AspirationalAbp.DbMigrator

First, let's add the Aspire.StackExchange.Redis, and Serilog.Sinks.OpenTelemetry packages to the AspirationalAbp.DbMigrator project. For this, let's run the following .NET CLI command inside the AspirationalAbp.DbMigrator project:

dotnet add package Aspire.StackExchange.Redis --version 8.0.1
dotnet add package Serilog.Sinks.OpenTelemetry --version 4.0.0-dev-00313

Then let's override the PreConfigureServices method in AspirationalAbpDbMigratorModule as below:

public override void PreConfigureServices(ServiceConfigurationContext context)  
{  
    var configuration = context.Services.GetConfiguration();  
    configuration["Redis:Configuration"] = configuration["ConnectionStrings:Redis"];  
}

To use the OpenTelemetry sink we have installed the Serilog.Sinks.OpenTelemetry package and now let's enable the sink. For this, let's write the following code block just before calling the CreateLogger method in the logger configuration in Program.cs:

/// .WriteTo.Async(c => c.Console())  
.WriteTo.Async(c => c.OpenTelemetry())  
/// .CreateLogger();

Now let's continue with AspirationalAbp.EntityFrameworkCore.

AspirationalAbp.EntityFrameworkCore

Now let's add the Aspire.Npgsql.EntityFrameworkCore.PostgreSQL package to the AspirationalAbp.EntityFrameworkCore project. For this, you can run the following command in the AspirationalAbp.EntityFrameworkCore project:

dotnet add package Aspire.Npgsql.EntityFrameworkCore.PostgreSQL --version 8.0.1

Now let's continue with AspirationalAbp.AuthServer.

AspirationalAbp.AuthServer

First, let's add the Serilog.Sinks.OpenTelemetry, Aspire.StackExchange.Redis and AspirationalAbp.ServiceDefaults packages to the AspirationalAbp.AuthServer project. For this, let's run the following .NET CLI command inside the AspirationalAbp.AuthServer project:

dotnet add package Aspire.StackExchange.Redis --version 8.0.1
dotnet add reference ../AspirationalAbp.ServiceDefaults/AspirationalAbp.ServiceDefaults.csproj
dotnet add package Serilog.Sinks.OpenTelemetry --version 4.0.0-dev-00313

Then add the following code block after defining the builder variable in Program.cs:

builder.AddServiceDefaults();  
builder.AddRedisClient("redis");  
builder.AddNpgsqlDbContext<AspirationalAbpDbContext>("Default",  
    options =>  
    {  
        options.DisableRetry = true;  
    });

Then add the following code to the PreConfigureServices method in the AspirationalAbpAuthServerModule class:

configuration["Redis:Configuration"] = configuration["ConnectionStrings:Redis"];

To use the OpenTelemetry sink we have installed the Serilog.Sinks.OpenTelemetry package and now let's enable the sink. For this, let's write the following code block just before calling the CreateLogger method in logger configuration in Program.cs:

/// .WriteTo.Async(c => c.Console())  
.WriteTo.Async(c => c.OpenTelemetry())  
/// .CreateLogger();

So far we have made AspirationalAbp.DbMigrator, AspirationalAbp.EntityFrameworkCore, and AspirationalAbp.AuthServer compatible with Aspire. Now let's continue with AspirationalAbp.HttpApi.Host.

AspirationalAbp.HttpApi.Host

First, let's add the Serilog.Sinks.OpenTelemetry, Aspire.StackExchange.Redis and AspirationalAbp.ServiceDefaults packages to the AspirationalAbp.HttpApi.Host project. For this, let's run the following .NET CLI command inside the AspirationalAbp.HttpApi.Host project:

dotnet add package Aspire.StackExchange.Redis --version 8.0.1
dotnet add reference ../AspirationalAbp.ServiceDefaults/AspirationalAbp.ServiceDefaults.csproj
dotnet add package Serilog.Sinks.OpenTelemetry --version 4.0.0-dev-00313

Then add the following code block after defining the builder variable in Program.cs:

builder.AddServiceDefaults();  
builder.AddRedisClient("redis");  
builder.AddNpgsqlDbContext<AspirationalAbpDbContext>("Default",  
    options =>  
    {  
        options.DisableRetry = true;  
    });

Then let's override the PreConfigureServices method in AspirationalAbpHttpApiHostModule as below:

public override void PreConfigureServices(ServiceConfigurationContext context)  
{  
    var configuration = context.Services.GetConfiguration();  
    configuration["Redis:Configuration"] = configuration["ConnectionStrings:Redis"];  
}

To use the OpenTelemetry sink we have installed the Serilog.Sinks.OpenTelemetry package and now let's enable the sink. For this, let's write the following code block just before calling the CreateLogger method in the logger configuration in Program.cs:

/// .WriteTo.Async(c => c.Console())  
.WriteTo.Async(c => c.OpenTelemetry())  
/// .CreateLogger();

Finally, let's make AspirationalAbp.Web compatible with Aspire.

AspirationalAbp.Web

First, let's add the Serilog.Sinks.OpenTelemetry, Aspire.StackExchange.Redis and AspirationalAbp.ServiceDefaults packages to the AspirationalAbp.Web project. For this, let's run the following .NET CLI command inside the AspirationalAbp.Web project:

dotnet add package Aspire.StackExchange.Redis --version 8.0.1
dotnet add reference ../AspirationalAbp.ServiceDefaults/AspirationalAbp.ServiceDefaults.csproj
dotnet add package Serilog.Sinks.OpenTelemetry --version 4.0.0-dev-00313

Then add the following code block after defining the builder variable in Program.cs:

builder.AddServiceDefaults();  
builder.AddRedisClient("redis");

Then add the following code to the PreConfigureServices method in the AspirationalAbpWebModule class:

var configuration = context.Services.GetConfiguration();  
configuration["Redis:Configuration"] = configuration["ConnectionStrings:Redis"];

To use the OpenTelemetry sink we have installed the Serilog.Sinks.OpenTelemetry package and now let's enable the sink. For this, let's write the following code block just before calling the CreateLogger method in logger configuration in Program.cs:

/// .WriteTo.Async(c => c.Console())  
.WriteTo.Async(c => c.OpenTelemetry())  
/// .CreateLogger();

After making all our changes, we can run the AspirationalAbp.AppHost project.

Conclusion

Combining Aspire with the ABP framework creates a powerful setup for building robust, observable, and feature-rich applications. By integrating Aspire's observability and cloud capabilities with ABP's approach of focusing on your business without repeating yourself, you can develop feature-rich, scalable applications with enhanced monitoring and seamless cloud integration. This guide provides a clear path to set up and configure these technologies, ensuring your applications are well-structured, maintainable, and ready for modern cloud environments.

See Also

• Aspire vs ABP Studio: Side by Side

In ASP.NET 8, the concept of authentication and authorization is undergoing a transformation. Specifically, ASP.NET Core Identity is transitioning from a focus on traditional web pages to a more API-driven approach. We will see what the Identity API endpoints are, why we need them, and how to use them in detail. So, let's dive in.

What is ASP.NET Core Identity?

ASP.NET Core Identity is like an extra toolkit that comes with ASP.NET Core. It offers a bunch of services to help you deal with user accounts in your ASP.NET Core application. These services include both basic concepts and ready-made solutions for each task.

With ASP.NET Core Identity, you can save user accounts in your app, handle user information, add extra security with two-factor authentication, and even connect other log in options, like social media logins, to user accounts. In simple terms, it's all about keeping user accounts in your app and making it easy for users to log in.

Prior to ASP.NET 8, there were limitations on using ASP.NET Identity in Single Page Applications (SPAs). Because the ASP.NET Core Identity framework is primarily tailored for traditional server-rendered web applications, like ASP.NET Core MVC or Razor Pages apps. However, the Identity API endpoints that come with ASP.NET 8 aim to solve token-based authentication and authorization in SPA without external dependencies.

Why do we need Identity APIs?

The introduction of Identity endpoints in ASP.NET 8 aims to streamline the process of integrating ASP.NET Core Identity into both API server applications and front-end SPAs like those built with JavaScript or Blazor. To understand the importance of these endpoints, let's first examine the disadvantages of using ASP.NET Core Identity before ASP.NET 8.

Let's delve into a common scenario:

Imagine you have a straightforward application composed of an ASP.NET Core backend that exposes APIs. On the client side, you have a SPA application that communicates with these APIs. Now, you want to incorporate user accounts, complete with authentication and authorization, into your application.

Before the advent of the identity endpoints, you could add ASP.NET Core Identity and the default Razor Pages UI to your app by adding a few packages, updating your database schema, and registering some services. However, this approach had some disadvantages. From a user experience perspective, the full-page refreshes of Razor Pages can be a major drawback especially compared to the fluidity of SPAs. On the other hand, from a developer's perspective, if you want the default pages to be compatible with the rest of your application, you may need to update more than 30 pages. Moreover, the default Razor Pages UI uses traditional cookie-based authentication, not bearer tokens.

In ASP.NET 8, identity endpoints were introduced to simplify the process of adding user accounts to ASP.NET Core API apps used with SPAs or mobile. These endpoints streamline the user management process by providing an alternative to the traditional Razor Page Identity UI pages. Additionally, a new endpoint is included for retrieving bearer tokens, which can be used for authentication. These changes directly address the concerns mentioned earlier, making it easier to create a user-friendly and integrated experience within your app, with no full-page refreshes or styling conflicts.

How to add Identity APIs?

In this part, I'll create a demo application, add all of the required packages, and lastly map the Identity APIs.

Create a new ASP.NET Core app with the following command and change the directory to the created application folder:

dotnet new webapi --name NewIdentityEndpoints -o IdentityDemo
cd IdentityDemo

After that, open the application in your favorite IDE and add the required packages:

<PackageReference Include="Microsoft.AspNetCore.Identity.EntityFrameworkCore" Version="8.0.0-rc.2.23480.2" />  
<PackageReference Include="Microsoft.EntityFrameworkCore.InMemory" Version="8.0.0-rc.2.23480.1" />

Note: I used the .NET 8.0.100-rc.2-** SDK for everything in this post.

Then replace Program.cs as below:

using System.Security.Claims;  
using Microsoft.AspNetCore.Identity;  
using Microsoft.AspNetCore.Identity.EntityFrameworkCore;  
using Microsoft.EntityFrameworkCore;  
  
var builder = WebApplication.CreateBuilder(args);  
  
builder.Services.AddAuthentication().AddBearerToken(IdentityConstants.BearerScheme);  
builder.Services.AddAuthorizationBuilder();  
  
builder.Services.AddDbContext<ApplicationDbContext>(options => options.UseInMemoryDatabase("AppDb"));  
  
builder.Services.AddIdentityCore<MyCustomUser>()  
.AddEntityFrameworkStores<ApplicationDbContext>()  
.AddApiEndpoints();  
  
builder.Services.AddEndpointsApiExplorer();  
builder.Services.AddSwaggerGen();  
  
var app = builder.Build();  
  
app.MapGroup("/my-identity-api").MapIdentityApi<IdentityUser>();  
  
app.MapGet("/", (ClaimsPrincipal user) => $"Hello {user.Identity!.Name}").RequireAuthorization();  
  
if (app.Environment.IsDevelopment())  
{  
  app.UseSwagger();  
  app.UseSwaggerUI();  
}  
  
app.Run();  
  
class MyCustomUser : IdentityUser { }  
  
class ApplicationDbContext : IdentityDbContext<MyCustomUser>  
{  
  public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) : base(options) { }  
}

When you run the application, you will see a result as the following:

Custom Authorization Policies

Prior to ASP.NET 8, adding a parameterized authorization policy to an endpoint required writing a lot of code.

• Implementing an AuthorizeAttribute for each policy
• Implementing an AuthorizationPolicyProvider to process a custom policy from a string-based contract
• Implementing an AuthorizationRequirement for the policy
• Implementing an AuthorizationHandler for each requirement

However, implementing the IAuthorizationRequirementData interface that comes with ASP.NET 8, your application code should look like this:

class MinimumAgeAuthorizeAttribute : AuthorizeAttribute, IAuthorizationRequirement, IAuthorizationRequirementData
{
  public MinimumAgeAuthorizeAttribute(int age) => Age =age;
  public int Age { get; }

  public IEnumerable<IAuthorizationRequirement> GetRequirements()
  {
    yield return this;
  }
}

class MinimumAgeAuthorizationHandler : AuthorizationHandler<MinimumAgeAuthorizeAttribute>
{
  protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, MinimumAgeAuthorizeAttribute requirement) 
  {
    ...
  }
}

See here for the complete code.

Conclusion

In this article, I've shown you the Identity APIs introduced with ASP.NET 8, why we need them, and how we can add them to our application, and finally I explained how to define a custom authorization policy with fewer lines of code.

References

• https://learn.microsoft.com/en-us/aspnet/core/release-notes/aspnetcore-8.0?view=aspnetcore-8.0#authentication-and-authorization
• https://auth0.com/blog/whats-new-dotnet8-authentication-authorization/
• https://andrewlock.net/exploring-the-dotnet-8-preview-introducing-the-identity-api-endpoints/
• https://andrewlock.net/should-you-use-the-dotnet-8-identity-api-endpoints/

Rate limiting is a way of controlling the traffic that a web application or API receives. In other words, rate limiting helps you control the amount of traffic each user has access to at any given time. This is extremely useful when you want to manage the load on your server or services, avoid going over your monthly data transfer limit and allow the system to continue to function and meet service level agreements, even when an increase in demand places an extreme load on resources.

In this article, we will look at what rate limiting is, why we need to use it, how the different rate limiting algorithms provided with .NET 7.0 work, and best practices for using rate limiting in your application.

What is rate limiting?

Whether accidental or intentional, users may exhaust resources in a way that impacts others. When a number of requests are received on to resources for a long time, the server can run out of those resources. These resources can include memory, threads, connections, or anything else that is limited. To avoid this situation, set rate limiters. Rate limiters control the consumption of resources used by an instance of an application, a user, an individual tenant, or an entire service.

Why do you need to use rate limiting?

A rate limiting system is crucial in any application where you have to control or throttle user requests or traffic. This is especially true in applications running on a cloud hosting platform because the user’s traffic can affect the whole server where the application is hosted.

Why do you need to implement rate limiting? Here are a few reasons:

• To ensure that a system continues to meet service level agreements (SLA).
• To prevent a single user, tenant, service, or so on from monopolizing the resources provided by an application.
• To help cost-optimize a system by limiting the maximum resource levels needed to keep it functioning.

Rate limiter algorithms

The RateLimiterOptionsExtensions class provides the following extension methods for rate limiting:

• Fixed window: Fixed-window limits—such as 3,000 requests per hour or 10 requests per day—are easy to state, but they are subject to spikes at the edges of the window, as available quota resets. Consider, for example, a limit of 3,000 requests per hour, which still allows for a spike of all 3,000 requests to be made in the first minute of the hour, which might overwhelm the service.
• Sliding window: Sliding windows have the benefits of a fixed window, but the rolling window of time smoothes out bursts. Systems such as Redis facilitate this technique with expiring keys.
• Token bucket: A token bucket maintains a rolling and accumulating budget of usage as a balance of tokens. A token bucket adds tokens at some rate. When a service request is made, the service attempts to withdraw a token (decrementing the token count) to fulfill the request. If there are no tokens in the bucket, the service has reached its limit and responds with backpressure.
• Concurrency: A concurrency limiter is the simplest form of rate limiting. It doesn’t look at time, just at number of concurrent requests.

In order to be a more realistic example, instead of making an example with each rate limiter algorithm, we will implement the following three algorithms in an ABP-based application.

1. We will add a SlidingWindowLimiter with a partition for all anonymous users.
2. We will add a TokenBucketRateLimiter with a partition for each authenticated user.
3. We will add a ConcurrencyLimiter with a partition for each Tenant.

Note: The following sample isn't meant for production code but is an example of how to use the limiters in ABP-based applications.

Limiter with OnRejected, RetryAfter, and GlobalLimiter

Add rate limiter

Let's create the following method in the MyProjectNameWebModule.cs class in the MyProjectName.Web project.

Note: If the **.Web project is not in your application, you can do the same in the project where your application is hosted.

private void ConfigureRateLimiters(ServiceConfigurationContext context)
{
    context.Services.AddRateLimiter(limiterOptions =>
    {
        limiterOptions.OnRejected = (context, cancellationToken) =>
        {
            if (context.Lease.TryGetMetadata(MetadataName.RetryAfter, out var retryAfter))
            {
                context.HttpContext.Response.Headers.RetryAfter =
                    ((int) retryAfter.TotalSeconds).ToString(NumberFormatInfo.InvariantInfo);
            }

            context.HttpContext.Response.StatusCode = StatusCodes.Status429TooManyRequests;
            context.HttpContext.RequestServices.GetService<ILoggerFactory>()?
                .CreateLogger("Microsoft.AspNetCore.RateLimitingMiddleware")
                .LogWarning("OnRejected: {RequestPath}", context.HttpContext.Request.Path);

            return new ValueTask();
        };

        limiterOptions.AddPolicy("UserBasedRateLimiting", context =>
        {
            var currentUser = context.RequestServices.GetService<ICurrentUser>();
            
            if (currentUser is not null && currentUser.IsAuthenticated)
            {
                return RateLimitPartition.GetTokenBucketLimiter(currentUser.UserName, _ => new TokenBucketRateLimiterOptions
                {
                    TokenLimit = 10,
                    QueueProcessingOrder = QueueProcessingOrder.OldestFirst,
                    QueueLimit = 3,
                    ReplenishmentPeriod = TimeSpan.FromMinutes(1),
                    TokensPerPeriod = 4,
                    AutoReplenishment = true
                });
            }

            return RateLimitPartition.GetSlidingWindowLimiter("anonymous-user",
                _ => new SlidingWindowRateLimiterOptions
                {
                    PermitLimit = 2,
                    QueueProcessingOrder = QueueProcessingOrder.OldestFirst,
                    QueueLimit = 1,
                    Window = TimeSpan.FromMinutes(1),
                    SegmentsPerWindow = 2
                });
        });

        limiterOptions.GlobalLimiter = PartitionedRateLimiter.Create<HttpContext, string>(context =>
        {
            var currentTenant = context.RequestServices.GetService<ICurrentTenant>();
            
            if (currentTenant is not null && currentTenant.IsAvailable)
            {
                return RateLimitPartition.GetConcurrencyLimiter(currentTenant!.Name, _ => new ConcurrencyLimiterOptions
                {
                    PermitLimit = 5,
                    QueueProcessingOrder = QueueProcessingOrder.OldestFirst,
                    QueueLimit = 1
                });
            }

            return RateLimitPartition.GetNoLimiter("host");
        });
    });
}

In the above example, the TokenBucketLimiter is used for each authenticated user, while the SlidingWindowLimiter is used for all anonymous users. Additionally, as a global limiter, the ConcurrencyLimiter is used for each tenant, while rate limiting is disabled for the host(tenant is not available). Also, for requests that are rejected when the limit is reached, sets the response status code to 429 Too Many Requests and the response mentions when to retry (if available from the rate-limiting metadata).

Let's call the ConfigureRateLimiters method that we created in the ConfigureServices method.

The final version of the ConfigureServices method:

public override void ConfigureServices(ServiceConfigurationContext context)
{
    var hostingEnvironment = context.Services.GetHostingEnvironment();
    var configuration = context.Services.GetConfiguration();

    ConfigureBundles();
    ConfigureUrls(configuration);
    ConfigurePages(configuration);
    ConfigureAuthentication(context);
    ConfigureImpersonation(context, configuration);
    ConfigureAutoMapper();
    ConfigureVirtualFileSystem(hostingEnvironment);
    ConfigureNavigationServices();
    ConfigureAutoApiControllers();
    ConfigureSwaggerServices(context.Services);
    ConfigureExternalProviders(context);
    ConfigureHealthChecks(context);
    ConfigureCookieConsent(context);
    ConfigureTheme();

    Configure<PermissionManagementOptions>(options =>
    {
        options.IsDynamicPermissionStoreEnabled = true;
    });
    
    ConfigureRateLimiters(context); // added
}

Add RateLimiter middleware

Add the following line just before the app.UseConfiguredEndpoints(...) line to add the RateLimiter middleware to your ASP.NET Core request pipeline:

app.UseRateLimiter();

Use rate limiter for all controllers

Let's edit the ConfiguredEndpoints middleware as follows:

app.UseConfiguredEndpoints(endpoints =>
{
    endpoints.MapRazorPages()
        .DisableRateLimiting();

    endpoints.MapControllers()
        .RequireRateLimiting("UserBasedRateLimiting");
});

• DisableRateLimiting: It is used to disable the ConcurrencyLimiter for razor pages, which we set globally when the tenant is available.
• RequireRateLimiting: We have enabled the rate limiter, which we define according to whether the user is authenticated or not, for all controllers.

EnableRateLimiting and DisableRateLimiting attributes

It's kind of unrealistic to always use rate limiting for all controllers or pages. Sometimes, we may want to throttle a particular endpoint or page. In such cases, we can use the EnableRateLimiting and DisableRateLimiting attributes. The EnableRateLimiting and DisableRateLimiting attributes can be applied to a controller, action method, or razor rage. Check here for more.

Rate limit an HTTP handler

Rate limiting when sending an HTTP request can be a good practice, especially in service-to-service communication. Because, resources are consumed by apps that rely on them, and when an app makes too many requests for a single resource, it can lead to resource contention. Resource contention occurs when a resource is consumed by too many clients, and the resource is unable to serve all of the apps that are requesting it. This can result in a poor user experience, and in some cases, it can even lead to a denial of service (DoS) attack. Since there are similar codes, I will not mention an example in this article, but to avoid such situations, you can write your own HTTP handler as here.

How does it work?

System.Threading.RateLimiting provides the primitives for writing rate limiters as well as providing a few commonly used algorithms built-in. The main type is the abstract base class RateLimiter.

public abstract class RateLimiter : IAsyncDisposable, IDisposable
{
    public abstract int GetAvailablePermits();
    public abstract TimeSpan? IdleDuration { get; }

    public RateLimitLease Acquire(int permitCount = 1);
    public ValueTask<RateLimitLease> WaitAsync(int permitCount = 1, CancellationToken cancellationToken = default);

    public void Dispose();
    public ValueTask DisposeAsync();
}

RateLimiter contains Acquire and WaitAsync as the core methods for trying to gain permits for a resource that is being protected. Depending on the application, the protected resource may need to acquire more than 1 permits, so Acquire and WaitAsync both accept an optional permitCount parameter. Acquire is a synchronous method that will check if enough permits are available or not and return a RateLimitLease which contains information about whether you successfully acquired the permits or not. WaitAsync is similar to Acquire except that it can support queuing permit requests which can be de-queued at some point in the future when the permits become available, which is why it’s asynchronous and accepts an optional CancellationToken to allow canceling the queued request.

RateLimitLease has an IsAcquired property which is used to see if the permits were acquired. Additionally, the RateLimitLease may contain metadata such as a suggested retry-after period if the lease failed. Finally, the RateLimitLease is disposable and should be disposed when the code is done using the protected resource. The disposal will let the RateLimiter know to update its limits based on how many permits were acquired.

Limitations

In most cases, the rate-limiting middleware provided with ASP.NET 7.0 will meet your requirements. However, if you would want to return statistics about your limits (e.g. the way GitHub does), you’ll find out that the ASP.NET rate limiting middleware does not support this. You won’t have access to the “number of requests remaining” or other metadata. Not in OnRejected, and definitely not if you want to return this data as headers on every request.

Best practices for rate limiting

In order to use rate limiting properly, you need to have a solid understanding of the types of limiting available, as well as the data rate and data volume of your service. You also need to have a clear idea of how many users you expect to use your service as well as how they will interact with it. The best practices for rate limiting are as follows:

• Find the right rate limiter algorithm for your endpoint. I mean, the cost of an endpoint should be considered when selecting a limiter. The cost of an endpoint includes the resources used, for example, time, data access, CPU, and I/O.
• Set realistic limits. Once you’ve figured out all the above, you need to set realistic limits for each service. Then, before deploying an app using rate limiting to production, stress test the app to validate the rate limiters and options used. For example, create a JMeter script with a tool like BlazeMeter or Apache JMeter HTTP(S) Test Script Recorder and load the script to Azure Load Testing.
• In response to rate-limiting, intermittent, or non-specific errors, a client should generally retry the request after a delay. It is a best practice for this delay to increase exponentially after each failed request, which is referred to as exponential backoff. When many clients might be making schedule-based requests (such as fetching results every hour), additional random time (jitter) should be applied to the request timing, the backoff period, or both of them to ensure that these multiple client instances don't become periodic thundering herd, and cause a form of DDoS themselves.

Conclusion

In this article, we’ve covered what rate limiting is, why you need to use it and the best practices for doing so. We’ve also looked at how to use three rate-limiting algorithms that are provided with .NET 7.0 on ABP-based applications and how rate-limiting works. Now that you’re familiar with the concept of rate limiting, it’s time to start implementing rate limiting in your application. This will allow you to control the traffic and ensure that your application is running smoothly without any issues.

References

• https://learn.microsoft.com/en-us/aspnet/core/performance/rate-limit?preserve-view=true&view=aspnetcore-7.0
• https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/
• https://blog.maartenballiauw.be/post/2022/09/26/aspnet-core-rate-limiting-middleware.html
• https://learn.microsoft.com/en-us/dotnet/core/extensions/http-ratelimiter
• https://learn.microsoft.com/en-us/azure/architecture/patterns/rate-limiting-pattern
• https://learn.microsoft.com/en-us/azure/architecture/patterns/throttling
• https://devblogs.microsoft.com/dotnet/announcing-rate-limiting-for-dotnet
• https://cloud.google.com/architecture/rate-limiting-strategies-techniques

Note: If your application is less than version 4.4.x, please follow this article.

Introduction

In this step-by-step article, I will explain how you can customize the user entity class, which is available in every web application you create using the ABP framework, according to your needs. When you read this article, you will learn how to override the services of built-in modules, extend the entities, extend data transfer objects and customize the user interface in the applications you develop using the ABP framework.

Note: This article is not about customizing the Login page. If you have such a need, please follow this article.

You can see the screenshots below which we will reach at the end of the article.

Preparing the Project

Startup template and the initial run

Abp Framework offers startup templates to get into the work faster. We can create a new startup template using Abp CLI:

abp new CustomizeUserDemo

In this article, I will go through the MVC application, but it will work also in the Angular, Blazor Server, and Blazor WebAssembly application.

After the download is finished, we can run CustomizeUserDemo.DbMigrator project to create the database migrations and seed the initial data (admin user, role, etc). Then we can run CustomizeUserDemo.Web to see that our application is working.

Default admin username is admin and password is 1q2w3E*

In this article, we will go through a scenario together and find the solutions to our questions through this scenario. However, since the scenario is not a real-life scenario, it may be strange, please don't get too about this issue :)

Step-1

Create the Users folder in the CustomizeUserDemo.Domain.Shared project, create the class UserConsts inside the folder and update the class you created as below:

public static class UserConsts
{
    public const string TitlePropertyName = "Title";

    public const string ReputationPropertyName = "Reputation";

    public const int MaxTitleLength = 64;

    public const double MaxReputationValue = 1_000;

    public const double MinReputationValue = 1;
}

Step-2

Update the CustomizeUserDemoEfCoreEntityExtensionMappings class in the CustomizeUserDemo.EntityFramework project in the EntityFrameworkCore folder as below:

public static class CustomizeUserDemoEfCoreEntityExtensionMappings
{
    private static readonly OneTimeRunner OneTimeRunner = new OneTimeRunner();

    public static void Configure()
    {
        CustomizeUserDemoGlobalFeatureConfigurator.Configure();
        CustomizeUserDemoModuleExtensionConfigurator.Configure();

        OneTimeRunner.Run(() =>
        {
            ObjectExtensionManager.Instance
                .MapEfCoreProperty<IdentityUser, string>(
                    UserConsts.TitlePropertyName,
                    (_, propertyBuilder) =>
                    {
                        propertyBuilder.HasDefaultValue("");
                        propertyBuilder.HasMaxLength(UserConsts.MaxTitleLength);
                    }
                ).MapEfCoreProperty<IdentityUser, int>(
                    UserConsts.ReputationPropertyName,
                    (_, propertyBuilder) =>
                    {
                        propertyBuilder.HasDefaultValue(UserConsts.MinReputationValue);
                    }
                );
        });
    }
}

This class can be used to map these extra properties to table fields in the database. Please read this article to improve your understanding of what we are doing.

So far, we have added our extra features to the User entity and matched these features with the ef core.

Now we need to add migration to see what has changed in our database. This for, open the Package Manager Console (PMC) under the menu Tools > NuGet Package Manager.

Select the CustomizeUserDemo.EntityFramework as the default project and execute the following command:

Add-Migration "Updated-User-Entity"

This will create a new migration class inside the Migrations folder of the CustomizeUserDemo.EntityFrameworkCore project.

If you are using another IDE than the Visual Studio, you can use dotnet-ef tool as documented here.

Finally, run the CustomizeUserDemo.DbMigrator project to update the database.

When we updated the database, you can see that the Title and Reputation columns are added to the Users table.

Step-3

Open the CustomizeUserDemoModuleExtensionConfigurator in the CustomizeUserDemo.Domain.Shared project, and change the contents of the ConfigureExtraProperties method as shown below:

private static void ConfigureExtraProperties()
{
    ObjectExtensionManager.Instance.Modules().ConfigureIdentity(identity =>
    {
        identity.ConfigureUser(user =>
        {
            user.AddOrUpdateProperty<string>(
                UserConsts.TitlePropertyName,
                options =>
                {
                    options.Attributes.Add(new RequiredAttribute());
                    options.Attributes.Add(
                        new StringLengthAttribute(UserConsts.MaxTitleLength)
                    );
                }
            );
            user.AddOrUpdateProperty<int>(
                UserConsts.ReputationPropertyName,
                options =>
                {
                    options.DefaultValue = UserConsts.MinReputationValue;
                    options.Attributes.Add(
                        new RangeAttribute(UserConsts.MinReputationValue, UserConsts.MaxReputationValue)
                    );
                }
            );
        });
    });
}

That's it. Now let's run the application and look at the Identity user page. You can also try to edit and recreate a record if you want, it will work even though we haven't done anything extra. Here is the magic code behind ABP framework.

If there is a situation you want to add, you can click the contribute button or make a comment. Also, if you like the article, don't forget to share it :)

Happy coding :)

Introduction

If you want to open up to the global market these days, end-to-end localization is a must. ABP provides an already established infrastructure for static texts. However, this may not be sufficient for many applications. You may need to fully customize your app for a particular language and region.

Let's take a look at a few quotes from Christian Arno's article "How Foreign-Language Internet Strategies Boost Sales" to better understand the impact of this:

• 82% of European consumers are less likely to buy online if the site is not in their native tongue (Eurobarometer survey).

• 72.4% of global consumers are more likely to buy a product if the information is available in their own language (Common Sense Advisory).

• The English language currently only accounts for 31% of all online use, and more than half of all searches are in languages other than English.

• Today, 42% of all Internet users are in Asia, while almost one-quarter are in Europe and just over 10% are in Latin America.

• Foreign languages have experienced exponential growth in online usage in the past decade -- with Chinese now officially the second-most-prominent-language on the Web. Arabic has increased by a whopping 2500%, while English has only risen by 204%

If you are looking for ways to expand your market share by fully customizing your application for a particular language and region, in this article I will explain how you can do it with ABP framework.

Source Code

You can find the source code of the application at abpframework/abp-samples.

Demo of the Final Application

At the end of this article, we will have created an application same as in the gif below.

Development

In order to keep the article short and get rid of unrelated information in the article (like defining entities etc.), we'll be using the BookStore example, which is used in the "Web Application Development Tutorial" documentation of ABP Framework and we will make the Book entity as multi-lingual. If you do not want to finish this tutorial, you can find the application here.

Determining the data model

We need a robust, maintainable, and efficient data model to store content in multiple languages.

I read many articles to determine the data model correctly, and as a result, I decided to use one of the many approaches that suit us. However, as in everything, there is a trade-off here. If you are wondering about the advantages and disadvantages of the model we will implement compared to other models, I recommend you to read this article.

As a result of the tutorial, we already have the Book and Author entities, as an extra, we will just add the BookTranslation.

In the article, we will make the Name property of the Book entity multi-lingual, but the article is independent of the Book entity, you can make the entity you want multi-lingual with similar codes according to your requirements.

Acme.BookStore.Domain.Shared

Create a folder named MultiLingualObjects and create the following interfaces in its contents.

We will use the IObjectTranslation interface to mark the translation of a multi-lingual entity:

public interface IObjectTranslation
{
    string Language { get; set; }
}

We will use the IMultiLingualObject<TTranslation> interface to mark multi-lingual entities:

public interface IMultiLingualObject<TTranslation>
    where TTranslation : class, IObjectTranslation
{
    ICollection<TTranslation> Translations { get; set; }
}

Acme.BookStore.Domain

In the Books folder, create the BookTranslation class as follows:

public class BookTranslation : Entity, IObjectTranslation
{
    public Guid BookId { get; set; }

    public string Name { get; set; }

    public string Language { get; set; }

    public override object[] GetKeys()
    {
        return new object[] {BookId, Language};
    }
}

BookTranslation contains the Language property, which contains a language code for translation and a reference to the multi-lingual entity. We also have the BookId foreign key to help us know which book is translated.

Implement IMultiLingualObject in the Book class as follows:

public class Book : AuditedAggregateRoot<Guid>, IMultiLingualObject<BookTranslation>
{
    public Guid AuthorId { get; set; }

    public string Name { get; set; }

    public BookType Type { get; set; }

    public DateTime PublishDate { get; set; }

    public float Price { get; set; }
    
    public ICollection<BookTranslation> Translations { get; set; }
}

Create a folder named MultiLingualObjects and add the following class inside of this folder:

public class MultiLingualObjectManager : ITransientDependency
{
    protected const int MaxCultureFallbackDepth = 5;

    public async Task<TTranslation> FindTranslationAsync<TMultiLingual, TTranslation>(
        TMultiLingual multiLingual,
        string culture = null,
        bool fallbackToParentCultures = true)
        where TMultiLingual : IMultiLingualObject<TTranslation>
        where TTranslation : class, IObjectTranslation
    {
        culture ??= CultureInfo.CurrentUICulture.Name;

        if (multiLingual.Translations.IsNullOrEmpty())
        {
            return null;
        }

        var translation = multiLingual.Translations.FirstOrDefault(pt => pt.Language == culture);
        if (translation != null)
        {
            return translation;
        }

        if (fallbackToParentCultures)
        {
            translation = GetTranslationBasedOnCulturalRecursive(
                CultureInfo.CurrentUICulture.Parent,
                multiLingual.Translations,
                0
            );

            if (translation != null)
            {
                return translation;
            }
        }
        
        return null;
    }

    protected TTranslation GetTranslationBasedOnCulturalRecursive<TTranslation>(
        CultureInfo culture, ICollection<TTranslation> translations, int currentDepth)
        where TTranslation : class, IObjectTranslation
    {
        if (culture == null ||
            culture.Name.IsNullOrWhiteSpace() ||
            translations.IsNullOrEmpty() ||
            currentDepth > MaxCultureFallbackDepth)
        {
            return null;
        }

        var translation = translations.FirstOrDefault(pt => pt.Language.Equals(culture.Name, StringComparison.OrdinalIgnoreCase));
        return translation ?? GetTranslationBasedOnCulturalRecursive(culture.Parent, translations, currentDepth + 1);
    }
}

With MultiLingualObjectManager's FindTranslationAsync method, we get the translated version of the book according to CurrentUICulture. If no translation of culture is found, we return null.

Every thread in .NET has CurrentCulture and CurrentUICulture objects.

Acme.BookStore.EntityFrameworkCore

In the OnModelCreating method of the BookStoreDbContext class, configure the BookTranslation as follows:

builder.Entity<BookTranslation>(b =>
{
    b.ToTable(BookStoreConsts.DbTablePrefix + "BookTranslations",
        BookStoreConsts.DbSchema);

    b.ConfigureByConvention();

    b.HasKey(x => new {x.BookId, x.Language});
});

I haven't explicitly set up a one-to-many relationship between Book and BookTranslation here, but the entity framework will do it for us.

After that, you can just run the following command in a command-line terminal to add a new database migration (in the directory of the EntityFrameworkCore project):

dotnet ef migrations add Added_BookTranslation

This will add a new migration class to your project. You can then run the following command (or run the .DbMigrator application) to apply changes to the database:

dotnet ef database update

Add the following code to the ConfigureServices method of the BookStoreEntityFrameworkCoreModule:

 Configure<AbpEntityOptions>(options =>
 {
     options.Entity<Book>(bookOptions =>
     {
         bookOptions.DefaultWithDetailsFunc = query => query.Include(o => o.Translations);
     });
});

Now we can use WithDetailsAsync without any parameters on BookAppService knowing that Translations will be included.

Acme.BookStore.Application.Contracts

Implement IObjectTranslation in the BookDto class as follows:

public class BookDto : AuditedEntityDto<Guid>, IObjectTranslation
{
    public Guid AuthorId { get; set; }

    public string AuthorName { get; set; }

    public string Name { get; set; }

    public BookType Type { get; set; }

    public DateTime PublishDate { get; set; }

    public float Price { get; set; }
    
    public string Language { get; set; }
}

Language property is required to understand which language the translated book name belongs to in the UI.

Create the AddBookTranslationDto class in the Books folder as follows:

public class AddBookTranslationDto : IObjectTranslation
{
    [Required]
    public string Language { get; set; }
    
    [Required]
    public string Name { get; set; }
}

Add the AddTranslationsAsync method to the IBookAppService as follows:

public interface IBookAppService :
    ICrudAppService<
        BookDto,
        Guid,
        PagedAndSortedResultRequestDto,
        CreateUpdateBookDto>
{
    Task<ListResultDto<AuthorLookupDto>> GetAuthorLookupAsync();
    
    Task AddTranslationsAsync(Guid id, AddBookTranslationDto input); // added this line
}

Acme.BookStore.Application

Now, we need to implement the AddTranslationsAsync method in BookAppService and include Translations in the Book entity, for this you can change the BookAppService as follows:

[Authorize(BookStorePermissions.Books.Default)]
public class BookAppService :
    CrudAppService<
        Book, //The Book entity
        BookDto, //Used to show books
        Guid, //Primary key of the book entity
        PagedAndSortedResultRequestDto, //Used for paging/sorting
        CreateUpdateBookDto>, //Used to create/update a book
    IBookAppService //implement the IBookAppService
{
    private readonly IAuthorRepository _authorRepository;

    public BookAppService(
        IRepository<Book, Guid> repository,
        IAuthorRepository authorRepository)
        : base(repository)
    {
        _authorRepository = authorRepository;
        GetPolicyName = BookStorePermissions.Books.Default;
        GetListPolicyName = BookStorePermissions.Books.Default;
        CreatePolicyName = BookStorePermissions.Books.Create;
        UpdatePolicyName = BookStorePermissions.Books.Edit;
        DeletePolicyName = BookStorePermissions.Books.Create;
    }

    public override async Task<BookDto> GetAsync(Guid id)
    {
        //Get the IQueryable<Book> from the repository
        var queryable = await Repository.WithDetailsAsync(); // this line changed

        //Prepare a query to join books and authors
        var query = from book in queryable
            join author in await _authorRepository.GetQueryableAsync() on book.AuthorId equals author.Id
            where book.Id == id
            select new { book, author };

        //Execute the query and get the book with author
        var queryResult = await AsyncExecuter.FirstOrDefaultAsync(query);
        if (queryResult == null)
        {
            throw new EntityNotFoundException(typeof(Book), id);
        }

        var bookDto = ObjectMapper.Map<Book, BookDto>(queryResult.book);
        bookDto.AuthorName = queryResult.author.Name;
        return bookDto;
    }

    public override async Task<PagedResultDto<BookDto>> GetListAsync(PagedAndSortedResultRequestDto input)
    {
        //Get the IQueryable<Book> from the repository
        var queryable = await Repository.WithDetailsAsync(); // this line changed

        //Prepare a query to join books and authors
        var query = from book in queryable
            join author in await _authorRepository.GetQueryableAsync() on book.AuthorId equals author.Id
            select new {book, author};

        //Paging
        query = query
            .OrderBy(NormalizeSorting(input.Sorting))
            .Skip(input.SkipCount)
            .Take(input.MaxResultCount);

        //Execute the query and get a list
        var queryResult = await AsyncExecuter.ToListAsync(query);

        //Convert the query result to a list of BookDto objects
        var bookDtos = queryResult.Select(x =>
        {
            var bookDto = ObjectMapper.Map<Book, BookDto>(x.book);
            bookDto.AuthorName = x.author.Name;
            return bookDto;
        }).ToList();

        //Get the total count with another query
        var totalCount = await Repository.GetCountAsync();

        return new PagedResultDto<BookDto>(
            totalCount,
            bookDtos
        );
    }

    public async Task<ListResultDto<AuthorLookupDto>> GetAuthorLookupAsync()
    {
        var authors = await _authorRepository.GetListAsync();

        return new ListResultDto<AuthorLookupDto>(
            ObjectMapper.Map<List<Author>, List<AuthorLookupDto>>(authors)
        );
    }

    public async Task AddTranslationsAsync(Guid id, AddBookTranslationDto input)
    {
        var queryable = await Repository.WithDetailsAsync();
        
        var book = await AsyncExecuter.FirstOrDefaultAsync(queryable, x => x.Id == id);

        if (book.Translations.Any(x => x.Language == input.Language))
        {
            throw new UserFriendlyException($"Translation already available for {input.Language}");
        }

        book.Translations.Add(new BookTranslation
        {
            BookId = book.Id,
            Name = input.Name,
            Language = input.Language
        });
        
        await Repository.UpdateAsync(book);
    }

    private static string NormalizeSorting(string sorting)
    {
        if (sorting.IsNullOrEmpty())
        {
            return $"book.{nameof(Book.Name)}";
        }

        if (sorting.Contains("authorName", StringComparison.OrdinalIgnoreCase))
        {
            return sorting.Replace(
                "authorName",
                "author.Name",
                StringComparison.OrdinalIgnoreCase
            );
        }

        return $"book.{sorting}";
    }
}

Create the MultiLingualBookObjectMapper class as follows:

public class MultiLingualBookObjectMapper : IObjectMapper<Book, BookDto>, ITransientDependency
{
    private readonly MultiLingualObjectManager _multiLingualObjectManager;

    private readonly ISettingProvider _settingProvider;

    public MultiLingualBookObjectMapper(
        MultiLingualObjectManager multiLingualObjectManager,
        ISettingProvider settingProvider)
    {
        _multiLingualObjectManager = multiLingualObjectManager;
        _settingProvider = settingProvider;
    }

    public BookDto Map(Book source)
    {
        var translation = AsyncHelper.RunSync(() =>
            _multiLingualObjectManager.FindTranslationAsync<Book, BookTranslation>(source));

        return new BookDto
        {
            Id = source.Id,
            AuthorId = source.AuthorId,
            Type = source.Type,
            Name = translation?.Name ?? source.Name,
            PublishDate = source.PublishDate,
            Price = source.Price,
            Language = translation?.Language ?? AsyncHelper.RunSync(() => _settingProvider.GetOrNullAsync(LocalizationSettingNames.DefaultLanguage)),
            CreationTime = source.CreationTime,
            CreatorId = source.CreatorId,
            LastModificationTime = source.LastModificationTime,
            LastModifierId = source.LastModifierId
        };
    }

    public BookDto Map(Book source, BookDto destination)
    {
        return default;
    }
}

To map the multi-lingual Book entity to BookDto, we implement custom mapping using the IObjectMapper<TSource, TDestination> interface. If no translation is found, default values are returned.

So far we have created the entire infrastructure. We don't need to change anything in the UI, if there is a translation according to the language chosen by the user, the list view will change. However, I want to create a simple modal where we can add new translations to an existing book in order to see what we have done.

Acme.BookStore.Web

Create a new razor page named AddTranslationModal in the Books folder as below.

View

@page
@using Microsoft.AspNetCore.Mvc.TagHelpers
@using Volo.Abp.AspNetCore.Mvc.UI.Bootstrap.TagHelpers.Modal
@model Acme.BookStore.Web.Pages.Books.AddTranslationModal

@{
    Layout = null;
}

<form asp-page="/Books/AddTranslationModal">
    <abp-modal>
        <abp-modal-header>Translations</abp-modal-header>
        <abp-modal-body>
            <abp-input asp-for="Id"></abp-input>
            <abp-select asp-for="@Model.TranslationViewModel.Language" asp-items="Model.Languages" class="form-select">
                <option selected value="">Pick a language</option>
            </abp-select>
            <abp-input asp-for="TranslationViewModel.Name"></abp-input>
        </abp-modal-body>
        <abp-modal-footer buttons="@(AbpModalButtons.Cancel | AbpModalButtons.Save)"></abp-modal-footer>
    </abp-modal>
</form>

Model

public class AddTranslationModal : BookStorePageModel
{
    [HiddenInput]
    [BindProperty(SupportsGet = true)]
    public Guid Id { get; set; }
    
    public List<SelectListItem> Languages { get; set; }

    [BindProperty]
    public BookTranslationViewModel TranslationViewModel { get; set; }
    
    private readonly IBookAppService _bookAppService;
    private readonly ILanguageProvider _languageProvider;

    public AddTranslationModal(
        IBookAppService bookAppService,
        ILanguageProvider languageProvider)
    {
        _bookAppService = bookAppService;
        _languageProvider = languageProvider;
    }

    public async Task OnGetAsync()
    {
        Languages = await GetLanguagesSelectItem();

        TranslationViewModel = new BookTranslationViewModel();
    }
    
    public async Task<IActionResult> OnPostAsync()
    {
        await _bookAppService.AddTranslationsAsync(Id, ObjectMapper.Map<BookTranslationViewModel, AddBookTranslationDto>(TranslationViewModel));
        
        return NoContent();
    }
    
    private async Task<List<SelectListItem>> GetLanguagesSelectItem()
    {
        var result = await _languageProvider.GetLanguagesAsync();
            
        return result.Select(
            languageInfo => new SelectListItem
            {
                Value = languageInfo.CultureName,
                Text = languageInfo.DisplayName + " (" + languageInfo.CultureName + ")"
            }
        ).ToList();
    }

    public class BookTranslationViewModel
    {
        [Required]
        [SelectItems(nameof(Languages))]
        public string Language { get; set; }
        
        [Required]
        public string Name { get; set; }

    }
}

Then, we can open the BookStoreWebAutoMapperProfile class and define the required mapping as follows:

CreateMap<AddTranslationModal.BookTranslationViewModel, AddBookTranslationDto>();

Finally, change the content of index.js in the Books folder as follows:

$(function () {
    var l = abp.localization.getResource('BookStore');
    var createModal = new abp.ModalManager(abp.appPath + 'Books/CreateModal');
    var editModal = new abp.ModalManager(abp.appPath + 'Books/EditModal');
    var addTranslationModal = new abp.ModalManager(abp.appPath + 'Books/AddTranslationModal'); // added this line
    
    var dataTable = $('#BooksTable').DataTable(
        abp.libs.datatables.normalizeConfiguration({
            serverSide: true,
            paging: true,
            order: [[1, "asc"]],
            searching: false,
            scrollX: true,
            ajax: abp.libs.datatables.createAjax(acme.bookStore.books.book.getList),
            columnDefs: [
                {
                    title: l('Actions'),
                    rowAction: {
                        items:
                            [
                                {
                                    text: l('Edit'),
                                    visible: abp.auth.isGranted('BookStore.Books.Edit'),
                                    action: function (data) {
                                        editModal.open({ id: data.record.id });
                                    }
                                },
                                {
                                    text: l('Add Translation'), // added this action
                                    visible: abp.auth.isGranted('BookStore.Books.Edit'),
                                    action: function (data) {
                                        addTranslationModal.open({ id: data.record.id });
                                    }
                                },
                                {
                                    text: l('Delete'),
                                    visible: abp.auth.isGranted('BookStore.Books.Delete'),
                                    confirmMessage: function (data) {
                                        return l(
                                            'BookDeletionConfirmationMessage',
                                            data.record.name
                                        );
                                    },
                                    action: function (data) {
                                        acme.bookStore.books.book
                                            .delete(data.record.id)
                                            .then(function() {
                                                abp.notify.info(
                                                    l('SuccessfullyDeleted')
                                                );
                                                dataTable.ajax.reload();
                                            });
                                    }
                                }
                            ]
                    }
                },
                {
                    title: l('Name'),
                    data: "name"
                },
                {
                    title: l('Author'),
                    data: "authorName"
                },
                {
                    title: l('Type'),
                    data: "type",
                    render: function (data) {
                        return l('Enum:BookType:' + data);
                    }
                },
                {
                    title: l('PublishDate'),
                    data: "publishDate",
                    render: function (data) {
                        return luxon
                            .DateTime
                            .fromISO(data, {
                                locale: abp.localization.currentCulture.name
                            }).toLocaleString();
                    }
                },
                {
                    title: l('Price'),
                    data: "price"
                },
                {
                    title: l('CreationTime'),
                    data: "creationTime",
                    render: function (data) {
                        return luxon
                            .DateTime
                            .fromISO(data, {
                                locale: abp.localization.currentCulture.name
                            }).toLocaleString(luxon.DateTime.DATETIME_SHORT);
                    }
                }
            ]
        })
    );

    createModal.onResult(function () {
        dataTable.ajax.reload();
    });

    editModal.onResult(function () {
        dataTable.ajax.reload();
    });

    $('#NewBookButton').click(function (e) {
        e.preventDefault();
        createModal.open();
    });
});

Conclusion

With a multi-lingual application, you can expand your market share, but if not designed well, may your application will be unusable. So, I've tried to explain how to design a sustainable multi-lingual entity in this article.

Source Code

You can find source code of the example solution used in this article here.

Hi, in this step by step article, I will show you how to integrate DevExpress blazor UI components into ABP Framework-based applications.

(A screenshot from the example application developed in this article)

Create the Project

ABP Framework offers startup templates to get into business faster.

In this article, I will create a new startup template with EF Core as a database provider and Blazor for UI framework. But if you already have a project with Blazor UI, you don't need to create a new startup template, you can directly implement the following steps to your existing project.

If you already have a project with the Blazor UI, you can skip this section.

• Before starting to development, we will create a solution named DevExpressSample (or whatever you want). We will create a new startup template with EF Core as a database provider and Blazor for UI framework by using ABP CLI:

abp new DevExpressSample -u blazor

• Our project boilerplate will be ready after the download is finished. Then, we can open the solution in the Visual Studio (or any other IDE) and run the DevExpressSample.DbMigrator to create the database and seed initial data (which creates the admin user, admin role, permissions etc.)

• After database and initial data created,

• Run the DevExpressSample.HttpApi.Host to see our server side working and

• Run the DevExpressSample.Blazor to see our UI working properly.

Default login credentials for admin: username is admin and password is 1q2w3E*

Install DevExpress

You can follow this documentation to install DevExpress packages into your computer.

Don't forget to add "DevExpress NuGet Feed" to your Nuget Package Sources.

Adding DevExpress NuGet Packages

Add the DevExpress.Blazor NuGet package to the DevExpressSample.Blazor project.

Install-Package DevExpress.Blazor

Register DevExpress Resources

1. Add the following line to the HEAD section of the wwwroot/index.html file within the DevExpressSample.Blazor project:

   <head>
       <!--...-->
       <link href="_content/DevExpress.Blazor/dx-blazor.css" rel="stylesheet" />
   </head>
   

2. In the DevExpressSampleBlazorModule class, call the AddDevExpressBlazor() method from your project's ConfigureServices() method:

   public override void ConfigureServices(ServiceConfigurationContext context)
   {
       var environment = context.Services.GetSingletonInstance<IWebAssemblyHostEnvironment>();
       var builder = context.Services.GetSingletonInstance<WebAssemblyHostBuilder>();
      // ...
       builder.Services.AddDevExpressBlazor();
   }
   

3. Register the DevExpressSample.Blazor namespace in the _Imports.razor file:

   @using DevExpress.Blazor
   

Result

The installation step was done. You can use any DevExpress Blazor UI component in your application:

Example: A Scheduler:

This example has been created by following this documentation.

The Sample Application

We have created a sample application with Data Grid example.

The Source Code

You can download the source code from here.

The related files for this example are marked in the following screenshots.

Additional Notes

Data Storage

I've used an in-memory list to store data for this example, instead of a real database. Because it is not related to DevExpress usage. There is a SampleDataService.cs file in Data folder at DevExpressSample.Application.Contracts project. All the data is stored here.

Conclusion

In this article, I've explained how to use DevExpress components in your application. ABP Framework is designed so that it can work with any UI library/framework.

Note: If your application is greater than version 4.3.3, please follow this article.

Introduction

In this step-by-step article, I will explain how you can customize the user entity class, which is available in every web application you create using the ABP framework, according to your needs. When you read this article, you will learn how to override the services of built-in modules, extend the entities, extend data transfer objects and customize the user interface in the applications you develop using the ABP framework.

Note: This article is not about customizing the Login page. If you have such a need, please follow this article.

You can see the screenshots below which we will reach at the end of the article.

Preparing the Project

Startup template and the initial run

Abp Framework offers startup templates to get into the work faster. We can create a new startup template using Abp CLI:

abp new CustomizeUserDemo

In this article, I will go through the MVC application, but it will work also in the Angular, Blazor Server, and Blazor WebAssembly application.

After the download is finished, we can run CustomizeUserDemo.DbMigrator project to create the database migrations and seed the initial data (admin user, role, etc). Then we can run CustomizeUserDemo.Web to see that our application is working.

Default admin username is admin and password is 1q2w3E*

In this article, we will go through a scenario together and find the solutions to our questions through this scenario. However, since the scenario is not a real-life scenario, it may be strange, please don't get too about this issue :)

Step-1

Add two new properties to the AppUser in the Users folder of the CustomizeUserDemo.Domain project as follows:

public string Title { get; protected set; }

public int Reputation { get; protected set; }

Step-2

Create the Users folder in the CustomizeUserDemo.Domain.Shared project, create the class UserConsts inside the folder and update the class you created as below:

public static class UserConsts
{
    public const string TitlePropertyName = "Title";

    public const string ReputationPropertyName = "Reputation";

    public const int MaxTitleLength = 64;

    public const double MaxReputationValue = 1_000;

    public const double MinReputationValue = 1;
}

Step-3

Update the CustomizeUserDemoEfCoreEntityExtensionMappings class in the CustomizeUserDemo.EntityFramework project in the EntityFrameworkCore folder as below:

public static class CustomizeUserDemoEfCoreEntityExtensionMappings
{
    private static readonly OneTimeRunner OneTimeRunner = new OneTimeRunner();

    public static void Configure()
    {
        CustomizeUserDemoGlobalFeatureConfigurator.Configure();
        CustomizeUserDemoModuleExtensionConfigurator.Configure();

        OneTimeRunner.Run(() =>
        {
            ObjectExtensionManager.Instance
                .MapEfCoreProperty<IdentityUser, string>(
                    nameof(AppUser.Title),
                    (entityBuilder, propertyBuilder) =>
                    {
                        propertyBuilder.HasDefaultValue("");
                        propertyBuilder.HasMaxLength(UserConsts.MaxTitleLength);
                    }
                ).MapEfCoreProperty<IdentityUser, int>(
                    nameof(AppUser.Reputation),
                    (entityBuilder, propertyBuilder) =>
                    {
                        propertyBuilder.HasDefaultValue(UserConsts.MinReputationValue);
                    }
                );
        });
    }
}

This class can be used to map these extra properties to table fields in the database. Please read this article to improve your understanding of what we are doing.

So far, we have added our extra features to the User entity and matched these features with the ef core.

Now we need to add migration to see what has changed in our database. This for, open the Package Manager Console (PMC) under the menu Tools > NuGet Package Manager.

Select the CustomizeUserDemo.EntityFramework as the default project and execute the following command:

Add-Migration "Updated-User-Entity"

This will create a new migration class inside the Migrations folder of the CustomizeUserDemo.EntityFrameworkCore project.

If you are using another IDE than the Visual Studio, you can use dotnet-ef tool as documented here.

Finally, run the CustomizeUserDemo.DbMigrator project to update the database.

When we updated the database, you can see that the Title and Reputation columns are added to the Users table.

Step-4

Open the CustomizeUserDemoModuleExtensionConfigurator in the CustomizeUserDemo.Domain.Shared project, and change the contents of the ConfigureExtraProperties method as shown below:

private static void ConfigureExtraProperties()
{
    ObjectExtensionManager.Instance.Modules().ConfigureIdentity(identity =>
    {
        identity.ConfigureUser(user =>
        {
            user.AddOrUpdateProperty<string>(
                UserConsts.TitlePropertyName,
                options =>
                {
                    options.Attributes.Add(new RequiredAttribute());
                    options.Attributes.Add(
                        new StringLengthAttribute(UserConsts.MaxTitleLength)
                    );
                }
            );
            user.AddOrUpdateProperty<int>(
                UserConsts.ReputationPropertyName,
                options =>
                {
                    options.DefaultValue = UserConsts.MinReputationValue;
                    options.Attributes.Add(
                        new RangeAttribute(UserConsts.MinReputationValue, UserConsts.MaxReputationValue)
                    );
                }
            );
        });
    });
}

That's it. Now let's run the application and look at the Identity user page. You can also try to edit and recreate a record if you want, it will work even though we haven't done anything extra. Here is the magic code behind ABP framework.

If there is a situation you want to add, you can click the contribute button or make a comment. Also, if you like the article, don't forget to share it :)

Happy coding :)