DEV Community: ABP.IO

Deep Dive on ABP AI Agent #5: MCP (Model Context Protocol)

ABP.IO — Mon, 15 Jun 2026 06:06:24 +0000

Deep Dive on ABP AI Agent #5: MCP (Model Context Protocol)

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.

When I add a server, ABP Studio asks how it should connect.

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.

In the example below, I am adding an HTTP MCP server named SEO Analyzer. It exposes a small set of SEO-related tools through a remote MCP endpoint.

ABP Studio does not require every server to be created manually from scratch. If I already use MCP elsewhere, I can import existing configuration from tools like Cursor, Claude, VS Code, Windsurf, or a plain MCP server JSON file. It can also export configuration in the standard mcpServers JSON shape.

That matters because MCP is an open ecosystem. The same server definition can often move between tools. ABP Studio becomes another place where I can use that server, but now in the context of an ABP-aware agent.

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:

Run the external SEO audit.
Read the score and category breakdown.
Identify the weakest areas.
Suggest concrete technical or content improvements.
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:

MCP brings in the external context.
ABP-aware reasoning maps it to the solution.
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:

Understand the requirement from outside the repository.
Find where that behavior lives in the ABP solution.
Make the smallest correct change.
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.

Deep Dive on ABP AI Agent #4: Integrated ABP Studio Tools

ABP.IO — Fri, 12 Jun 2026 05:36:58 +0000

Deep Dive on ABP AI Agent #4: Integrated ABP Studio Tools

When I use an AI coding agent, there is a point where plain code awareness is not enough.

The agent may understand the project structure. It may read the failing method. It may even guess the most likely cause of an error. But in a real development session, I usually need more than a guess. I need the latest exception, the request that caused it, the logs around it, the application that is running, the containers it depends on, the tasks I can execute, and the build result after a fix.

That is where ABP AI Coding Agent becomes different from a generic coding assistant. It is not only connected to files. It is connected to ABP Studio.

ABP Studio already knows the solution, run profiles, runnable applications, containers, tasks, monitoring data, and build actions. ABP AI Coding Agent can use that context through integrated tools when those tools are enabled. So instead of copying exception details, terminal output, container names, or build logs into the chat manually, I can let the agent work with the same ABP Studio environment I am using.

Note: ABP AI Coding Agent is available directly to ABP license holders. License holders have predefined credits so they can try it without setting up a separate AI workflow first. When those credits run out, they can buy more and continue using the same integrated experience.

Why Integrated Tools Matter

Most coding agents start from the same place: source code.

That is useful, but ABP development is not only source code. A running ABP solution has applications, modules, services, containers, database connections, migrations, logs, exceptions, requests, tasks, and build steps. When these pieces are outside the agent's reach, the developer becomes the bridge:

Copy this exception.
Paste that log.
Run this build.
Check that container.
Explain which application is currently running.
Tell the agent what failed after the last change.

Integrated ABP Studio tools reduce that manual work. They let the agent ask ABP Studio for runtime and solution information directly, within the permission boundary I choose.

The important detail is that this access is still explicit. Tools can be enabled or disabled. If I do not want the agent to use a tool, I can keep it disabled. If I want the agent to troubleshoot with runtime information, I can enable the relevant tools and ask for a more complete investigation.

That gives me a practical balance: the productivity of automation, with a visible boundary around what the agent can use.

Tool Access: What The Agent Is Allowed To Use

The tools view is the control point.

This is where ABP Studio shows the integrated tools that can be used by ABP AI Coding Agent. Some tools are for reading runtime information. Some are for interacting with applications. Some are for containers, tasks, or build actions.

The names are intentionally direct. A monitoring tool that gets exceptions is about exceptions. A build tool is about build validation. A task tool is about ABP Studio tasks. That makes the tool list easy to understand even before using it in a real prompt.

For me, the key idea is not the individual button names. It is the permission model:

If a tool is disabled, the agent should not act as if it has that information.
If a tool is enabled, the agent can use it as part of the current session.
If a task needs runtime evidence, I can enable only the tools needed for that task.

This makes ABP AI Coding Agent feel more intentional than a black box. I can decide when it should stay in code reasoning and when it should use ABP Studio's runtime view of the solution.

Monitoring Tools

Monitoring tools are the first group I reach for when something fails at runtime.

These tools help the agent inspect what happened while the application was running. In practice, this means information like exceptions , logs , events , and request details.

This is a big difference from a generic coding agent. Without monitoring tools, the agent can read the code and make a reasonable guess. With monitoring tools, it can work from the actual failure.

For example, if a page throws an exception, I can ask:

Get the latest exception from ABP Studio Monitoring and explain what failed.

If the exception tool is enabled, the agent can use that runtime signal. It can look at the exception message, stack trace, request context, and related code. Then it can connect the runtime failure to the implementation.

That changes the debugging loop:

Trigger the problem.
Ask the agent to inspect the runtime evidence.
Let it find the related code.
Apply the fix.
Validate again.

The developer no longer needs to manually copy the exception from one place and paste it into another. ABP Studio becomes part of the agent's working context and give it _ harness _!

Application Tools

Application tools connect the agent to the applications defined in the active ABP Studio run profile.

This matters because ABP solutions often contain more than one runnable application. A layered solution may have a web application, an API host, a DbMigrator, and other executable projects. A microservice solution may have several services with different roles.

ABP Studio already understands these applications through the solution and run profile. When application tools are available, the agent does not need to rediscover everything from file names or ask me which project is running. It can use ABP Studio's view of the solution.

That is useful for prompts like:

Check which application is running and use the relevant runtime information to investigate the problem.

The benefit is not only convenience. It also reduces mistakes. The agent can reason from the same run profile that I use in ABP Studio, instead of guessing from the repository structure alone.

Container Tools

Many ABP applications depend on infrastructure services while running locally.

A solution may need SQL Server, PostgreSQL, Redis, RabbitMQ, OpenIddict-related services, or other containers depending on the template and modules. When something fails, the cause is not always in application code. Sometimes a required container is not running. Sometimes the application cannot reach a dependency. Sometimes the runtime error is only a symptom of an infrastructure problem.

Container tools give the agent a way to include that part of the environment in the investigation.

Instead of asking the agent to guess why a database connection fails, I can let it check the container context that ABP Studio already has. The agent can then distinguish between:

a code problem,
a configuration problem,
a missing or stopped container,
or a dependency that is running but unhealthy.

This is one of the places where ABP Studio integration is especially valuable. General coding agents can help with Docker files or connection strings, but they usually do not know the current ABP Studio container state unless I copy it into the prompt. ABP AI Coding Agent can work closer to the actual local development environment.

Task Tools

ABP Studio tasks are another part of the development workflow that should not live outside the agent.

Tasks can represent common solution actions. They may run commands, scripts, or workflow steps that are already configured for the solution. If the team uses ABP Studio tasks to standardize local development, the agent should be able to understand and use that same layer.

That means I can ask for a workflow instead of a raw command:

Use the available ABP Studio tasks to validate this change.

The agent can work with the task names and outputs rather than asking me to remember the exact command. This is helpful in larger solutions where the correct validation step is not obvious from a single project file.

It also keeps the agent aligned with the team's development path. If ABP Studio has the task, the agent can follow that path instead of inventing a one-off command.

Build Tools

Build tools close the loop after an implementation or fix.

The agent should not only change files. It should also help verify that the change still builds.

In a generic coding agent flow, validation often depends on shell access and manually chosen commands. That can work, but it leaves more room for guessing. Which project should be built? Which solution file should be used? Is there an ABP Studio-specific build action already configured?

With ABP Studio build tools, the agent can use the build context exposed by the platform. That makes prompts like this more natural:

Apply the fix and run the available build validation.

For small changes, this may simply confirm that the project compiles. For larger changes, it can become part of a broader loop with tasks, application checks, and monitoring tools.

The important part is that the agent can move from implementation to validation without requiring me to manually transfer output between tools.

A Practical Tool Access Walkthrough

Let me make this more concrete with a small debugging scenario.

In the sample application, I deliberately added a runtime exception to the UpdateAsync method of BookAppService.cs:

throw new Exception("Sample exception for demonstrating integrated tools!");

Then I started the application from ABP Studio and triggered the related request from the browser. The only purpose of this setup is to create a real runtime failure that ABP Studio Monitoring can capture.

The interesting part is not the exception itself. The interesting part is how the agent behaves when the monitoring tool is disabled, and how that changes when the tool is enabled.

First, Without The Exception Tool

For the first run, I kept the monitoring tool that retrieves exceptions disabled.

Then I asked:

Can you get the latest exception from ABP Studio Monitoring and explain what failed?

At this point, the agent did not have direct access to the exception tool. So it tried to reason around the problem in other ways. It looked for available information, tried to inspect logs from files, and checked the codebase to understand what might be happening.

That is still useful in some cases, but it is not the best debugging flow. The agent is spending time and context trying to reconstruct a runtime failure indirectly. It may eventually find the suspicious code, but it is working from weaker evidence.

This is exactly why tool access matters. Without the monitoring tool, the agent can reason from files. With the monitoring tool, it can inspect the actual runtime failure.

Then, With The Exception Tool Enabled

For the second run, I enabled the monitoring tool that can retrieve exceptions, such as get_exceptions.

Then I asked:

Now the get_exceptions tool is enabled. Please get the latest exception from ABP Studio Monitoring, identify the failing code path, and suggest the smallest fix.

This time, the behavior was very different. The agent directly used the integrated exception tool, retrieved the exception details from ABP Studio Monitoring, and connected the runtime error to the failing code path.

It also used the enabled logging tool to verify the surrounding context instead of guessing from the source code alone.

That is the workflow I want from an integrated coding agent. It does not only say "this code looks suspicious." It checks the exception, follows the evidence, finds the source of the problem, and proposes the smallest fix.

It is also faster and more efficient. The agent does not need to spend as many tokens searching for indirect clues because ABP Studio can provide the runtime signal directly.

Adding Logs And Requests

After that, I asked the agent to use the available monitoring tools together:

Use the available monitoring tools to check the related logs and recent requests for this failure. Tell me whether they confirm the same root cause.

At this point, the agent used the enabled tools for exceptions, requests, and logs.

This is where the ABP Studio integration becomes even more valuable. A runtime problem is rarely just one line of code. There is usually a request, a log entry, an exception, and a running application context around it.

When these tools are available together, the agent can correlate them. It can say, "this request caused this exception, the logs confirm it, and this code path is responsible."

That is much better than asking the developer to copy each piece manually into the chat.

Validating The Fix

Finally, I asked the agent to validate the result:

Run the available build or application validation tools and confirm that the problem is fixed.

The agent used ABP Studio tools to stop the application, build it, and run it again.

This completes the loop. The agent did not only identify the problem. It used the integrated tools to move through the full flow:

Read the runtime exception.
Correlate it with logs and requests.
Find the failing code path.
Apply or suggest the focused fix.
Validate the application again.

That is the difference I want to highlight in this article. ABP AI Coding Agent is not only a model that can edit files. When ABP Studio tools are enabled, it can participate in the same development workflow I use: observing the running application, understanding the failure, fixing the code, and validating the result.

Why This Is Different From Generic Coding Agents

Tools like Cursor, Claude Code, and Codex are powerful. They can read code, edit files, run commands, and help with many software projects.

ABP AI Coding Agent has a different advantage: it is built for the ABP development experience.

It is aware of ABP concepts, ABP solution structure, ABP Studio run profiles, application metadata, containers, monitoring, tasks, and build actions. It is also backed by the ABP Platform: ABP Framework, ABP Commercial, ABP Suite, ABP Studio, and the workflows that connect them.

That platform context matters. When I am building an ABP solution, I do not only want a model that can write C# or TypeScript. I want an assistant that understands the way ABP applications are structured and the way ABP Studio runs them.

That makes the starting point simple: open the ABP solution, use ABP Studio, choose the right mode, enable the tools needed for the task, and work with the agent inside the platform.

Conclusion

Integrated tools make ABP AI Coding Agent more than a chat window next to the code. They give it a controlled way to work with the same ABP Studio context I already use: applications , containers , monitoring , tasks , and build actions.

-> That helps the agent move from "I think this might be the problem" to "I checked the runtime evidence, found the related code, applied the fix, and validated it."

That is the real value of this part of ABP Studio AI. It brings the coding agent closer to the full development experience, from understanding the solution to running it, observing it, fixing it, and checking the result.

As ABP Studio evolves, more tools can be added to this workflow. That means the agent can become more useful over time without changing the basic idea: ABP AI Coding Agent works best when it is not isolated from the platform, but integrated into it.

Deep Dive on ABP AI Agent #3: Rules, Skills and Lessons

ABP.IO — Thu, 11 Jun 2026 06:09:39 +0000

Deep Dive on ABP AI Agent #3: Rules, Skills and Lessons

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.

Deep Dive on ABP AI Agent #2: Supported AI Models in ABP Studio + Usage Recommendations

ABP.IO — Wed, 10 Jun 2026 05:51:56 +0000

Deep Dive on ABP AI Agent #2: Supported AI Models in ABP Studio + Usage Recommendations

There is one question I ask almost as often as "Which mode should I use?":

Which model should do this work?

At first, it is tempting to answer that question by always choosing the strongest model in the list. That feels safe. If a model is more capable, why not use it for everything?

In real work, I do not think about it that way.

When I use ABP Studio AI , the model choice is part of the workflow. Some tasks need careful reasoning. Some need speed. Some need a large context window. Some need image support because the browser or a screenshot is involved. Some are small text-processing tasks where using the most capable model would only make the work slower and more expensive.

So I treat model selection as a practical decision, not a trophy selection.

What ABP Studio Supports Today

ABP Studio gives me a curated model setup by default. It keeps the first experience simple, while still letting me choose from a broader model catalog when I want to tune the setup for a specific kind of work.

The important word here is focused.

ABP Studio does not treat every model as an equally good choice for agent work. A coding agent needs things like a useful context window, tool support, text output, and reliable behavior in repeated agent loops. Studio keeps the model experience closer to that reality.

The built-in model set currently includes:

| Model | How I think about it | | --- | --- | | Claude Sonnet 4.6 | The default main model for day-to-day Ask, Plan, and Agent work. | | Claude Haiku 4.5 | A fast supporting model for research, browser work, and lightweight text processing. | | Claude Opus 4.7 | A stronger option when the task needs deeper reasoning or more careful review. | | GPT-5.5 | Another strong option for main conversations or review-style work. | | GLM-5.1 | A text/code option for tasks that do not need image input. |

I do not read this list as a ranking. I read it as the default toolbox.

And it is not a closed box. If I need a different model for a specific task, I can open the Models settings, search the catalog, filter by category, and add more models to my selection.

That is an important distinction. The built-in models are there so I can start with sensible defaults. They are not there to force every team, every solution, or every workflow into the same model choices.

The Main Model

The main model is the one I feel most directly in the conversation.

It is used when I ask questions, create plans, or let ABP Agent work through an implementation. This is the model behind the normal flow of the chat.

For most work, I keep a balanced model as the main model. A Sonnet-style model is a good default because it is capable enough for real development tasks without making every small question feel heavy.

This is the model I use for:

Understanding a module or package
Planning a feature before editing code
Applying a reviewed plan
Fixing ordinary build or test failures
Making changes where the expected result is easy to review

When the task gets broader, I become more intentional.

If I am asking ABP Agent to reason across several modules, plan a risky refactor, review architecture, or inspect a subtle regression, I am more willing to switch to a stronger model. The extra capability is useful when the cost of a shallow answer is high.

For a quick localization change or a small DTO update, that same choice can be wasteful. The strongest model is not always the best model for the moment.

Role-Based Models

One detail I like in ABP Studio AI is that model selection is not only one global dropdown.

Studio separates the main conversation model from supporting model roles. That means I can keep the main model strong enough for the conversation while using lighter models for background work.

The roles are easier to understand if I describe them by how they feel in daily use.

Main Model is the model I am actively talking to. It carries the normal Ask, Plan, and Agent experience.

Research Model is for research and ABP documentation searcher work. I usually keep this lightweight because research often involves gathering, narrowing, and summarizing context before the main model decides what to do with it.

Browser Model is used by the browser subagent in Agent mode. This role should stay fast and practical. When browser screenshots are involved, I choose a model that supports image input. A text-only model may be fine for code, but it is not the right fit when the work depends on seeing the UI.

Text Processor Model is for smaller language tasks such as summarizing errors, generating commit messages, or consolidating learned lessons. This is exactly where I do not want to spend the most capable model every time.

The Git Review model is separate too.

For AI Review, I like the "Ask me every time" behavior. Some reviews are routine. Some reviews deserve a stronger model because the change is large, security-sensitive, or touches architecture. Asking each time keeps that decision close to the actual change.

If a team wants consistent review behavior, a fixed review model also makes sense. The key is that Git Review does not have to silently follow the same model I use for ordinary chat.

How I Choose In Practice

For quick questions, I use the default main model.

If I am asking "Where is this permission defined?" or "Why does this module reference that package?", I do not need to overthink the model. I want a clear answer and maybe a few source references.

For planning larger work, I use a stronger main model when the decision matters.

Plan mode is where the model can save me from an expensive wrong turn. If the change crosses layers, modules, permissions, UI, or database behavior, I prefer a model that can hold more context and reason carefully. I still narrow the scope where possible, because a focused prompt usually beats a huge unfocused one.

For implementation, I care about reliability more than raw size.

Agent mode is not only about generating code. It is about reading the solution, editing files, running checks, seeing failures, and trying again. A good main model should follow instructions consistently and use tools well. For supporting roles, I usually keep the lighter defaults.

For UI and browser tasks, I check image support.

If the task involves screenshots, browser interaction, visual verification, or UI state, the browser model needs to be able to understand images. This is one reason I do not treat every text/code model as interchangeable.

For reviews, I choose based on risk.

A small formatting or localization change does not need the same review setup as a large change in authorization, multi-tenancy, persistence, or distributed behavior. For deeper reviews, I am willing to use a stronger model because the goal is not speed. The goal is to catch what I missed.

For cost and latency, I avoid using the strongest model everywhere.

This is not only about credits. It is also about pace. If every background task uses a heavy model, the development loop feels slower. Keeping lightweight models for lightweight jobs makes ABP Studio AI feel more responsive.

A Simple Rule

The model name matters less than the job.

When I choose a model in ABP Studio AI, I usually ask:

| Situation | Model choice I prefer | | --- | --- | | Normal Ask, Plan, or Agent work | Balanced main model | | Broad planning or risky implementation | Stronger main model | | Research and documentation lookup | Lightweight supporting model | | Browser tasks with screenshots | Vision-capable browser model | | Error summaries and commit messages | Lightweight text processor model | | Important AI Review | Stronger model or ask each time |

That keeps the experience practical.

Modes decide how much action I want: Ask, Plan, or Agent.

Models decide which brain should handle the work.

When those two choices are made intentionally, ABP Studio AI feels less like one generic AI button and more like a set of tools I can tune for the task in front of me.

Deep Dive on ABP AI Agent #1: Agent, Plan and Ask Modes

ABP.IO — Tue, 09 Jun 2026 07:52:20 +0000

Deep Dive on ABP AI Agent #1: Agent, Plan and Ask Modes

There is a small question I like to answer before I type anything into ABP Agent :

Do I want an answer, a plan, or action?

That question looks simple, but it changes the whole experience. Sometimes I am only trying to understand why a module is structured a certain way. Sometimes I already know the direction, but I want the implementation path checked before touching files. And sometimes the task is clear enough that I want ABP Agent to do the work, run the checks, and iterate with me.

That is where the three modes in ABP Studio AI become more than labels. They help me choose the right level of trust, risk, and action for the moment.

Ask Mode: When I Want To Understand

Ask is the mode I reach for when I want to stay in learning mode.

It is useful when I am reading a solution and want to ask questions like:

What is this module responsible for?
Why is this permission checked here?
How does this application service relate to the domain layer?
What would happen if I changed this setting, dependency, or flow?
Which ABP concept should I use for this requirement?

The important part is that Ask mode is read-only. I can explore the codebase, ABP concepts, architecture, or possible approaches without worrying that files will be changed as a side effect of the conversation.

That makes it a comfortable starting point. I do not need to prepare a perfect prompt. I can ask a rough question, follow up with more context, and slowly turn uncertainty into something clearer.

For me, Ask mode is especially helpful when I join a solution after some time away. Instead of jumping between files and trying to rebuild the story manually, I can ask ABP Agent to explain the shape of the solution in the language of ABP: modules, layers, permissions, application services, entities, settings, events, and runtime pieces.

Plan Mode: When I Want To Think Before Changing Code

Plan is the mode I use when the next step is probably implementation, but I do not want to start editing yet.

This is the middle ground between a conversation and a code change. ABP Agent can inspect the solution in a read-only way, ask clarifying questions when the requirement is not clear enough, and produce a structured plan before any file is modified.

That changes the feeling of working with AI. Instead of saying "go build this" and reviewing only the result, I can review the approach first:

Which files will likely be affected?
Which ABP layers are involved?
Does the implementation path match the existing solution style?
Are there missing decisions before the work starts?
Is this a small change, or is it actually a larger workflow?

This is useful for changes that cross boundaries: adding a new entity, adjusting an application service, introducing a permission, changing a UI flow, or touching more than one module. Those are exactly the moments where I want a second pass before code starts moving.

When a plan is active, ABP Studio gives me clear actions around it. I can view the plan, detach it if it is no longer the right direction, or apply it with Agent mode when I am ready to move from planning to implementation.

The small detail I like here is that the plan does not disappear into the chat history. It becomes something I can review and intentionally carry into the next step.

Agent Mode: When I Am Ready For Action

Agent is the mode I choose when I am ready to let ABP Agent work on the solution.

This is the action mode. ABP Agent can edit files, run commands, build projects, use ABP Studio tasks, and iterate when something fails. It is the right choice when the task is clear enough and I am comfortable letting the agent make changes that I will review afterward.

For small trusted tasks, I may go directly to Agent mode:

Add a missing localization entry
Fix a straightforward build error
Update a simple DTO mapping
Add a validation rule that matches an existing pattern
Apply a plan that I have already reviewed

For larger work, I prefer not to start here. Agent mode is powerful, and power is better when it is intentional. If I am not sure about the shape of the change, I usually start with Ask or Plan first.

A Practical Workflow

The modes are most useful when I treat them as a workflow, not as three disconnected buttons.

For larger changes, my usual flow is:

Ask to understand the area and the existing conventions.
Plan to turn the requirement into a reviewable implementation path.
Agent to apply the plan, build, and iterate.

For learning, I often stay entirely in Ask mode. If I am trying to understand ABP multi-tenancy behavior, module dependencies, permission definitions, or why a solution is organized a certain way, there is no need to involve file changes.

For small tasks, I may go directly to Agent mode. The key is that I already know what I want, the risk is low, and the expected result is easy to review.

Here is the simple rule I keep in mind:

| Situation | Mode I Choose | Why | | --- | --- | --- | | I need an explanation | Ask | It keeps the conversation read-only. | | I need a direction before implementation | Plan | It gives me a reviewable path before changes. | | I am ready for ABP Agent to work | Agent | It can edit, build, run tasks, and iterate. |

Why This Matters

AI-assisted development can feel too fast when the tool moves from idea to code before I have decided what kind of help I actually need.

The three modes slow that moment down in a good way. They let me say:

"Just explain this."
"Think through the change first."
"Now implement it."

That separation makes the work feel more intentional. It also makes the output easier to review, because the mode already tells me what kind of result I should expect.

Ask gives me understanding. Plan gives me a path. Agent gives me action.

Used together, they make ABP Studio AI feel less like a single big button and more like a development partner that can adapt to the level of confidence I have at each step.

Implement Automatic Method-Level Caching in ABP Framework

ABP.IO — Mon, 08 Dec 2025 07:16:29 +0000

Implement Automatic Method-Level Caching in ABP Framework

Caching is one of the most effective ways to improve application performance, but implementing it manually for every method can be tedious and error-prone. What if you could cache method results automatically with just an attribute? In this article, we'll explore how to build an automatic method-level caching system in ABP Framework that handles cache invalidation, supports multiple scopes, and integrates seamlessly with your existing application.

By the end of this guide, you'll understand how to implement attribute-based caching that automatically invalidates when entities change, supports user-specific and global caching scopes, and provides built-in metrics for monitoring cache performance.

💡 Complete Implementation Available : This article is based on a working demo project. You can find the complete implementation in the AbpAutoCacheDemo repository, with the core AutoCache library implementation available in this commit.

What is Automatic Method-Level Caching?

Automatic method-level caching is a technique that intercepts method calls and caches their results without requiring manual cache management code. Instead of writing cache logic in every method, you simply decorate methods with attributes that define caching behavior.

The key benefits include:

Reduced Boilerplate: No repetitive cache management code in your business logic
Consistent Caching Strategy: Centralized cache configuration and behavior
Smart Invalidation: Automatic cache clearing when related entities change
Multiple Scopes: Support for global, user-specific, and entity-specific caching
Built-in Monitoring: Track cache hits, misses, and performance metrics

Architecture Overview

The automatic caching system consists of several key components working together:

Core Components:

CacheAttribute: The attribute you apply to methods to enable automatic caching
AutoCacheInterceptor: Intercepts method calls and handles cache operations
AutoCacheManager: Manages cache storage, retrieval, and key generation
IAutoCacheKeyManager: Handles cache key mapping and invalidation
AutoCacheInvalidationHandler: Listens to entity changes and clears related caches

This architecture leverages ABP's dynamic proxy system and event bus to provide seamless caching without modifying your business logic.

Prerequisites

Before implementing automatic caching, ensure you have:

ABP Framework 10.0 or later

Implementation

📦 Repository Structure : The complete implementation is available in the AbpAutoCacheDemo repository. The AutoCache library is located in the src/AutoCache folder, making it easy to extract and reuse in your own projects.

Step - 1: Create the AutoCache Module

First, let's create a separate module for our caching infrastructure. This makes it reusable across projects.

Step - 1: Create the AutoCache Module

First, let's create a separate module for our caching infrastructure. This makes it reusable across projects.

Create AutoCache.csproj:

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFramework>net10.0</TargetFramework>
        <Nullable>enable</Nullable>
    </PropertyGroup>

    <ItemGroup>
        <PackageReference Include="Volo.Abp.Caching.StackExchangeRedis" Version="10.0.0" />
        <PackageReference Include="Volo.Abp.Core" Version="10.0.0" />
        <PackageReference Include="Volo.Abp.Ddd.Domain" Version="10.0.0" />
    </ItemGroup>
</Project>

Create the module class AutoCacheModule.cs:

using Microsoft.Extensions.DependencyInjection;
using Volo.Abp.Caching.StackExchangeRedis;
using Volo.Abp.Domain;
using Volo.Abp.Modularity;

namespace AutoCache;

[DependsOn(typeof(AbpDddDomainModule), typeof(AbpCachingStackExchangeRedisModule))]
public class AutoCacheModule : AbpModule
{
    public override void PreConfigureServices(ServiceConfigurationContext context)
    {
        context.Services.OnRegistered(AutoCacheRegister.RegisterInterceptorIfNeeded); // 👈 Register interceptor
    }
}

This module automatically registers the cache interceptor for any class that uses the CacheAttribute.

Step - 2: Define the Cache Attribute

The CacheAttribute is the core of our automatic caching system. It specifies which entities affect the cache and what scope to use.

Create CacheAttribute.cs:

using System;
using Volo.Abp.Domain.Entities;

namespace AutoCache;

[AttributeUsage(AttributeTargets.Method)]
public class CacheAttribute : Attribute
{
    /// <summary>
    /// Entity types that affect this cache. When these entities change, the cache will be invalidated.
    /// </summary>
    public Type[] InvalidateOnEntities { get; set; }

    /// <summary>
    /// Scope of the cache (Global, CurrentUser, AuthenticatedUser, or Entity)
    /// </summary>
    public AutoCacheScope Scope { get; set; } = AutoCacheScope.Global;

    /// <summary>
    /// Absolute expiration time relative to now in milliseconds (0 = use default, -1 = disabled)
    /// </summary>
    public long AbsoluteExpirationRelativeToNow { get; set; }

    /// <summary>
    /// Sliding expiration time in milliseconds (0 = use default, -1 = disabled)
    /// </summary>
    public long SlidingExpiration { get; set; }

    public bool ConsiderUow { get; set; }

    public string AdditionalCacheKey { get; set; }

    public CacheAttribute(params Type[] invalidateOnEntities) // 👈 Specify entities that trigger cache invalidation
    {
        foreach (var entityType in invalidateOnEntities)
        {
            ArgumentNullException.ThrowIfNull(entityType);
            if (!typeof(IEntity).IsAssignableFrom(entityType))
            {
                throw new ArgumentException($"Type {entityType.FullName} must implement IEntity interface.");
            }
        }
        InvalidateOnEntities = invalidateOnEntities;
    }
}

Key Properties:

InvalidateOnEntities: Array of entity types that, when modified, will clear this cache
Scope: Determines cache visibility (Global, CurrentUser, AuthenticatedUser, Entity)
AbsoluteExpirationRelativeToNow / SlidingExpiration: Control cache lifetime

Step - 3: Define Cache Scopes

Cache scopes determine how cache entries are partitioned. Create AutoCacheScope.cs:

using System;

namespace AutoCache;

[Flags]
public enum AutoCacheScope
{
    /// <summary>
    /// Cache is shared globally across all users
    /// </summary>
    Global,

    /// <summary>
    /// Cache is scoped to the current user (based on user ID)
    /// </summary>
    CurrentUser,

    /// <summary>
    /// Cache is scoped to authenticated vs unauthenticated users
    /// </summary>
    AuthenticatedUser,

    /// <summary>
    /// Cache is scoped to the primary key of the entity involved
    /// </summary>
    Entity
}

When to Use Each Scope:

Global: For data that's the same for all users (e.g., configuration, public lists)
CurrentUser: For user-specific data (e.g., user profile, user's orders)
AuthenticatedUser: For data that differs between authenticated and anonymous users
Entity: For data tied to a specific entity instance (e.g., book details by ID)

Step - 4: Implement the Cache Interceptor

The interceptor is the heart of automatic caching. It intercepts method calls, checks the cache, and stores results. Create AutoCacheInterceptor.cs:

using System;
using System.Collections.Concurrent;
using System.Linq;
using System.Reflection;
using System.Threading.Tasks;
using Microsoft.Extensions.Caching.Distributed;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Options;
using Volo.Abp.DependencyInjection;
using Volo.Abp.DynamicProxy;

namespace AutoCache;

public class AutoCacheInterceptor : AbpInterceptor, ITransientDependency
{
    private readonly ILogger<AutoCacheInterceptor> _logger;
    private readonly AutoCacheOptions _options;
    private static readonly MethodInfo GetOrAddCacheAsyncMethod;
    private readonly AutoCacheManager _autoCacheManager;
    private static readonly ConcurrentDictionary<Type, MethodInfo> MethodCache = new();

    static AutoCacheInterceptor()
    {
        GetOrAddCacheAsyncMethod = typeof(AutoCacheInterceptor).GetMethod(
            nameof(GetOrAddCacheAsync),
            BindingFlags.NonPublic | BindingFlags.Instance
        )!;
    }

    public AutoCacheInterceptor(
        ILogger<AutoCacheInterceptor> logger,
        IOptions<AutoCacheOptions> options, 
        AutoCacheManager autoCacheManager)
    {
        _logger = logger;
        _autoCacheManager = autoCacheManager;
        _options = options.Value;
    }

    public override async Task InterceptAsync(IAbpMethodInvocation invocation)
    {
        // Check if caching is enabled and method has [Cache] attribute
        if(!_options.Enabled || 
           invocation.Method.GetCustomAttributes(typeof(CacheAttribute), true).FirstOrDefault() 
           is not CacheAttribute attribute)
        {
            await invocation.ProceedAsync(); // 👈 No caching, proceed normally
            return;
        }

        var proceeded = false;

        try
        {
            // Create generic method based on return type
            var genericMethod = MethodCache.GetOrAdd(invocation.Method.ReturnType, t =>
            {
                var isGenericTask = t.IsGenericType && t.GetGenericTypeDefinition() == typeof(Task<>);
                var resultType = isGenericTask ? t.GetGenericArguments()[0] : t;
                return GetOrAddCacheAsyncMethod.MakeGenericMethod(resultType);
            });

            // Execute cache logic
            (var result, proceeded) = await (Task<(object, bool)>)genericMethod.Invoke(this, [invocation, attribute])!;
            invocation.ReturnValue = result; // 👈 Set cached or fresh result
        }
        catch (Exception e)
        {
            _logger.LogError(e, "Error occurred while caching method {MethodName}", invocation.Method.Name);

            if(e is AutoCacheExceptionWrapper exceptionWrapper)
            {
                if (_options.ThrowOnError)
                {
                    throw exceptionWrapper.OriginalException;
                }

                _logger.LogWarning(
                    "Cache operation failed, falling back to method execution for {MethodName}",
                    invocation.Method.Name
                );
            }

            if (!proceeded && invocation.ReturnValue == null)
            {
                await invocation.ProceedAsync(); // 👈 Fallback to actual method execution
            }
        }
    }

    private async Task<(object?, bool)> GetOrAddCacheAsync<TResult>(
        IAbpMethodInvocation invocation, 
        CacheAttribute attribute)
    {
        var proceeded = false;
        var result = await _autoCacheManager.GetOrAddAsync(
            invocation.TargetObject, 
            Factory, 
            invocation.Arguments, 
            () => new DistributedCacheEntryOptions
            {
                AbsoluteExpirationRelativeToNow = GetExpiration(
                    attribute.AbsoluteExpirationRelativeToNow, 
                    _options.DefaultAbsoluteExpirationRelativeToNow),
                SlidingExpiration = GetExpiration(
                    attribute.SlidingExpiration, 
                    _options.DefaultSlidingExpiration)
            }, 
            attribute.InvalidateOnEntities, 
            attribute.Scope, 
            attribute.ConsiderUow, 
            attribute.AdditionalCacheKey, 
            invocation.Method.Name);

        return (result, proceeded);

        async Task<TResult> Factory()
        {
            await invocation.ProceedAsync(); // 👈 Execute actual method on cache miss
            proceeded = true;
            return (TResult)invocation.ReturnValue;
        }
    }

    private static TimeSpan? GetExpiration(long milliseconds, long defaultValue)
    {
        return milliseconds switch
        {
            0 => defaultValue > 0 ? TimeSpan.FromMilliseconds(defaultValue) : null,
            < 0 => null,
            _ => TimeSpan.FromMilliseconds(milliseconds)
        };
    }
}

The interceptor intelligently determines whether to serve cached data or execute the actual method.

Step - 5: Implement the Cache Manager

The AutoCacheManager handles the actual cache operations. Create a simplified version:

using System;
using System.Runtime.CompilerServices;
using System.Threading.Tasks;
using Microsoft.Extensions.Caching.Distributed;
using Microsoft.Extensions.Logging;
using Volo.Abp.DependencyInjection;
using Volo.Abp.DynamicProxy;
using Volo.Abp.Users;

namespace AutoCache;

public class AutoCacheManager : IScopedDependency
{
    private readonly IAutoCacheKeyManager _autoCacheKeyManager;
    private readonly ICurrentUser _currentUser;
    private readonly ILogger<AutoCacheManager> _logger;
    private readonly IAutoCacheMetrics _metrics;
    private readonly AutoCacheOptions _options;

    public AutoCacheManager(
        IAutoCacheKeyManager autoCacheKeyManager, 
        ICurrentUser currentUser,
        ILogger<AutoCacheManager> logger,
        IAutoCacheMetrics metrics,
        IOptions<AutoCacheOptions> options)
    {
        _autoCacheKeyManager = autoCacheKeyManager;
        _currentUser = currentUser;
        _logger = logger;
        _metrics = metrics;
        _options = options.Value;
    }

    public async Task<TResult> GetOrAddAsync<TResult>(
        object? caller,
        Func<Task<TResult>> func,
        object?[]? parameters = null,
        Func<DistributedCacheEntryOptions>? optionsFactory = null,
        Type[]? invalidateOnEntities = null,
        AutoCacheScope scope = AutoCacheScope.Global,
        bool considerUow = false,
        string? additionalCacheKey = null,
        [CallerMemberName] string methodName = "")
    {
        if (!_options.Enabled)
        {
            return await func(); // 👈 Caching disabled, execute directly
        }

        var callerType = caller != null ? ProxyHelper.GetUnProxiedType(caller) : GetType();
        parameters ??= [];

        // Generate unique cache key based on method, parameters, and scope
        var cacheKey = GenerateCacheKey<TResult>(
            callerType.Name, 
            additionalCacheKey, 
            methodName, 
            parameters, 
            scope);

        var (cachedResult, exception, wasHit) = await GetOrAddCacheAsync(
            cacheKey,
            func,
            optionsFactory,
            considerUow
        );

        // Record metrics
        if (wasHit)
        {
            _metrics.RecordHit(cacheKey);
        }
        else
        {
            _metrics.RecordMiss(cacheKey);
        }

        if (exception != null)
        {
            _metrics.RecordError(cacheKey, exception);

            if (_options.ThrowOnError)
            {
                throw exception;
            }
        }

        return cachedResult;
    }

    private string GenerateCacheKey<TResult>(
        string callerTypeName,
        string? additionalCacheKey,
        string methodName,
        object?[] parameters,
        AutoCacheScope scope)
    {
        var keyBuilder = new StringBuilder();
        keyBuilder.Append($"{callerTypeName}:{methodName}");

        // Add parameters to key
        foreach (var param in parameters)
        {
            keyBuilder.Append($":{param}");
        }

        // Add scope-specific segments
        if (scope.HasFlag(AutoCacheScope.CurrentUser) && _currentUser.Id.HasValue)
        {
            keyBuilder.Append($":user:{_currentUser.Id}"); // 👈 User-specific cache key
        }

        if (scope.HasFlag(AutoCacheScope.AuthenticatedUser))
        {
            keyBuilder.Append($":auth:{_currentUser.IsAuthenticated}");
        }

        if (!string.IsNullOrEmpty(additionalCacheKey))
        {
            keyBuilder.Append($":{additionalCacheKey}");
        }

        return keyBuilder.ToString();
    }

    // Additional methods for cache retrieval and storage...
}

The manager generates unique cache keys based on method signatures, parameters, and scope settings.

Step - 6: Implement Cache Invalidation

When entities change, related caches must be cleared. Create AutoCacheInvalidationHandler.cs:

using System;
using System.Threading.Tasks;
using Microsoft.Extensions.Logging;
using Volo.Abp.Domain.Entities;
using Volo.Abp.Domain.Entities.Events;
using Volo.Abp.EventBus;
using Volo.Abp.Uow;

namespace AutoCache;

public class AutoCacheInvalidationHandler<TEntity> : 
    ILocalEventHandler<EntityChangedEventData<TEntity>> 
    where TEntity : class, IEntity
{
    private readonly IAutoCacheKeyManager _autoCacheKeyManager;
    private readonly ILogger<AutoCacheInvalidationHandler<TEntity>> _logger;
    private readonly IUnitOfWorkManager _unitOfWorkManager;

    public AutoCacheInvalidationHandler(
        IAutoCacheKeyManager autoCacheKeyManager, 
        ILogger<AutoCacheInvalidationHandler<TEntity>> logger,
        IUnitOfWorkManager unitOfWorkManager)
    {
        _autoCacheKeyManager = autoCacheKeyManager;
        _logger = logger;
        _unitOfWorkManager = unitOfWorkManager;
    }

    public async Task HandleEventAsync(EntityChangedEventData<TEntity> eventData)
    {
        try
        {
            var entityType = typeof(TEntity);
            var context = new RemoveCacheKeyContext 
            { 
                Keys = eventData.Entity.GetKeys()! 
            };

            // Clear cache after unit of work completes
            if(_unitOfWorkManager.Current != null)
            {
                _unitOfWorkManager.Current.OnCompleted(async () =>
                {
                    await _autoCacheKeyManager.RemoveCacheAndCacheKeys(entityType, context); // 👈 Invalidate cache
                });
            }
            else
            {
                await _autoCacheKeyManager.RemoveCacheAndCacheKeys(entityType, context);
            }
        }
        catch (Exception e)
        {
            _logger.LogError(
                e, 
                "Error occurred while clearing cache for entity type {EntityType}", 
                typeof(TEntity).FullName
            );
        }
    }
}

This handler listens to entity change events and automatically clears related caches. The invalidation happens after the unit of work completes to ensure data consistency.

Step - 7: Configure AutoCache in Your Application

Add the AutoCacheModule to your application module dependencies:

[DependsOn(
    typeof(AutoCacheModule), // 👈 Add AutoCache module
    typeof(AbpCachingStackExchangeRedisModule),
    // ... other modules
)]
public class YourApplicationModule : AbpModule
{
    public override void ConfigureServices(ServiceConfigurationContext context)
    {
        Configure<AutoCacheOptions>(options =>
        {
            options.Enabled = true; // 👈 Enable caching
            options.DefaultAbsoluteExpirationRelativeToNow = 3600000; // 1 hour
            options.DefaultSlidingExpiration = 600000; // 10 minutes
            options.ThrowOnError = false; // Fallback to method execution on cache errors
        });

        // Configure Redis (if using distributed cache)
        Configure<AbpDistributedCacheOptions>(options =>
        {
            options.KeyPrefix = "YourApp:";
        });
    }
}

Step - 8: Use Automatic Caching in Application Services

Now comes the easy part - using automatic caching! Simply add the [Cache] attribute to your methods:

using AutoCache;

[Authorize(AutoCacheDemoPermissions.Books.Default)]
public class BookAppService : ApplicationService, IBookAppService
{
    private readonly IRepository<Book, Guid> _repository;
    private readonly AutoCacheManager _autoCacheManager;

    public BookAppService(IRepository<Book, Guid> repository, AutoCacheManager autoCacheManager)
    {
        _repository = repository;
        _autoCacheManager = autoCacheManager;
    }

    // Cache this method, invalidate when Book entity changes
    [Cache(typeof(Book), Scope = AutoCacheScope.Global)]
    public virtual async Task<BookDto> GetAsync(Guid id)
    {
        // You can also use AutoCacheManager directly for nested caching
        var book = await _autoCacheManager.GetOrAddAsync(
            this, 
            async () => await _repository.GetAsync(id), 
            [id], // 👈 Method parameters
            invalidateOnEntities: [typeof(Book)], 
            scope: AutoCacheScope.Entity);

        return ObjectMapper.Map<Book, BookDto>(book!);
    }

    // Cache book list, invalidate when any Book changes
    [Cache(typeof(Book))]
    public virtual async Task<PagedResultDto<BookDto>> GetListAsync(PagedAndSortedResultRequestDto input)
    {
        var queryable = await _repository.GetQueryableAsync();
        var query = queryable
            .OrderBy(input.Sorting.IsNullOrWhiteSpace() ? "Name" : input.Sorting)
            .Skip(input.SkipCount)
            .Take(input.MaxResultCount);

        var books = await AsyncExecuter.ToListAsync(query);
        var totalCount = await AsyncExecuter.CountAsync(queryable);

        return new PagedResultDto<BookDto>(
            totalCount,
            ObjectMapper.Map<List<Book>, List<BookDto>>(books)
        );
    }

    // No caching on write operations
    [Authorize(AutoCacheDemoPermissions.Books.Create)]
    public async Task<BookDto> CreateAsync(CreateUpdateBookDto input)
    {
        var book = ObjectMapper.Map<CreateUpdateBookDto, Book>(input);
        await _repository.InsertAsync(book); // 👈 This will trigger cache invalidation
        return ObjectMapper.Map<Book, BookDto>(book);
    }
}

What Happens Here:

When GetAsync is called, the interceptor checks the cache
On cache miss, the actual method executes and the result is cached
When CreateAsync inserts a Book, the invalidation handler clears all caches related to Book
Next call to GetAsync will fetch fresh data

Advanced Features

User-Specific Caching

For user-specific data, use AutoCacheScope.CurrentUser:

[Cache(typeof(Order), Scope = AutoCacheScope.CurrentUser)]
public virtual async Task<List<OrderDto>> GetMyOrdersAsync()
{
    var orders = await _orderRepository.GetListAsync(x => x.UserId == CurrentUser.Id);
    return ObjectMapper.Map<List<Order>, List<OrderDto>>(orders);
}

Each user gets their own cache entry, automatically invalidated when their orders change.

Custom Cache Keys

For fine-grained control, add custom cache key segments:

[Cache(
    typeof(Product), 
    Scope = AutoCacheScope.Global,
    AdditionalCacheKey = "featured"
)]
public virtual async Task<List<ProductDto>> GetFeaturedProductsAsync()
{
    // Only featured products are cached separately
    return await GetProductsByCategoryAsync("Featured");
}

Performance Metrics

Monitor cache performance using IAutoCacheMetrics:

public class CacheMonitoringService : ITransientDependency
{
    private readonly IAutoCacheMetrics _metrics;

    public CacheMonitoringService(IAutoCacheMetrics metrics)
    {
        _metrics = metrics;
    }

    public AutoCacheStatistics GetStatistics()
    {
        return _metrics.GetStatistics(); // 👈 Get hit rate, miss count, error count
    }
}

Testing the Application

1. Run the Application

abp new BookStore -u mvc -d ef
cd BookStore
dotnet run --project src/BookStore.Web

2. Test Cache Behavior

Create a simple test to verify caching:

[Fact]
public async Task Should_Cache_Book_Results()
{
    // First call - cache miss
    var book1 = await _bookAppService.GetAsync(testBookId);

    // Second call - cache hit (should be faster)
    var book2 = await _bookAppService.GetAsync(testBookId);

    book1.Name.ShouldBe(book2.Name);
}

[Fact]
public async Task Should_Invalidate_Cache_On_Update()
{
    // Cache the book
    var book1 = await _bookAppService.GetAsync(testBookId);

    // Update the book
    await _bookAppService.UpdateAsync(testBookId, new CreateUpdateBookDto 
    { 
        Name = "Updated Name" 
    });

    // Fetch again - should get updated data (cache was invalidated)
    var book2 = await _bookAppService.GetAsync(testBookId);

    book2.Name.ShouldBe("Updated Name");
}

3. Monitor Cache Performance

Check your application logs for cache metrics:

[INF] Cache Hit: BookAppService:GetAsync:book-id-123 (Response Time: 5ms)
[INF] Cache Miss: BookAppService:GetListAsync (Response Time: 156ms)
[INF] Cache Invalidation: Book entity changed, cleared 3 cache entries

Key Takeaways

✅ Automatic caching reduces boilerplate code - Just add [Cache] attribute to methods instead of manual cache management

✅ Smart invalidation keeps data fresh - Entity changes automatically clear related caches without manual intervention

✅ Multiple scoping options - Support for global, user-specific, authenticated, and entity-level caching strategies

✅ Built-in fallback handling - Gracefully falls back to method execution if caching fails

✅ Performance monitoring - Track cache hits, misses, and errors for optimization

Conclusion

Automatic method-level caching dramatically simplifies performance optimization in ABP Framework applications. By using attributes and interceptors, you can add sophisticated caching behavior without cluttering your business logic with cache management code.

The system we've built provides intelligent cache invalidation, multiple scoping strategies, and built-in monitoring - all while maintaining clean, readable code. Whether you're building a small application or an enterprise system, this approach scales elegantly and integrates seamlessly with ABP's architecture.

Ready to implement this in your project? The complete working implementation is available in the AbpAutoCacheDemo repository. You can clone the repository, explore the code, and even extract the src/AutoCache folder to use it as a standalone library in your own ABP applications. The main implementation commit shows all the components working together, including interceptor registration, cache key management, and automatic invalidation handlers.r you're building a small application or an enterprise system, this approach scales elegantly and integrates seamlessly with ABP's architecture.

Ready to implement this in your project? Check out the complete working example in the repository linked below, and start improving your application's performance today!

References

.NET Conf China 2025: Changing the World, Changing Ourselves - See You Again in Shanghai

ABP.IO — Wed, 03 Dec 2025 08:32:26 +0000

.NET Conf China 2025: Changing the World, Changing Ourselves - See You Again in Shanghai

.NET Conf China 2025 is an annual community event for developers, celebrating the release of .NET 10 (LTS) and the achievements of the past year in China. As an extension of .NET Conf 2025, this event brings together local tech communities, well-known companies, and open-source organizations. It has become the largest .NET online and offline conference in China, dedicated to spreading .NET technology in Chinese and fostering collaboration and exchange.

Event Highlights: Key Topics and Takeaways

This year’s conference focused on three main themes: performance improvements, AI integration, and cross-platform development. Topics covered how to achieve performance gains while maintaining engineering quality, balancing between multi-platform consistency and native capabilities, and taking generative AI from “demo-level” to “production-ready.” On the community and ecosystem side, the event showcased the .NET Foundation’s and domestic and international companies’ progress in supporting architectures like ARM, LoongArch, and RISC-V. It also highlighted best practices in DevOps, observability, and engineering toolchains, creating a complete path from ideas to implementation.

Opening Keynote

Scott Hanselman kicked off .NET Conf China 2025 with a video keynote, announcing that .NET 10 is now available on the official website. He framed the release around four pillars—AI, cloud-native, cross-platform, and performance—including integration with the Microsoft Agent Framework for building and orchestrating multi-agent systems in .NET/C#, industry-leading container and Kubernetes support with .NET Aspire simplifying local containerized development, a richer cross-platform desktop ecosystem (.NET MAUI, Avalonia, Uno Platform), and major performance gains such as Native AOT and single-file publishing for faster startup and easier distribution across platforms.

He underscored China’s importance as .NET’s second-largest market, with roughly 13% of users, and noted that generative AI usage in China has doubled in 2025. The local community is seeing strong momentum around ML.NET, .NET Aspire, and the C# Dev Kit in VS Code. Reflecting on his Baby Smash game written 20 years ago, which now runs cross-platform on .NET 10, he called on developers to modernize: move existing Web, WinForms, and WPF apps to the cloud, improve performance, ship as a single executable, and weave in AI capabilities.

On AI, he emphasized a human-centered stance: AI and agents should augment, not replace, developers. In the future, developers will orchestrate and govern agents, and human judgment will matter more than ever. He closed by thanking the open-source community for its many proposals and pull requests, stressing that .NET is an open-source platform built together by Microsoft and the community, and wishing everyone an inspiring conference and a joyful journey with .NET 10.

Roundtable Discussion

The roundtable discussion, titled “Empowering with AI, Breaking Through Cross-Platform Barriers, and Ecosystem Innovation,” focused on practical implementation. It explored typical paths for large models and intelligent agents in enterprises, key considerations for choosing cross-platform UI frameworks, and the evolution of these frameworks. Panelists discussed questions like: How can AI capabilities be integrated into existing business processes instead of creating an “experimental” pipeline? How should cross-platform solutions be evaluated in terms of performance, ecosystem, and team skillsets? What are the unique opportunities for domestic ecosystems in the global tech landscape? And how can community collaboration help developers quickly adopt best practices? A shared consensus emerged: in the short term, focus on running scenarios; in the long term, return to engineering fundamentals. Both toolchains and methodologies are equally important.

In-Depth Sessions

The afternoon featured four breakout sessions, covering a wide range of topics with deep dives into both foundational technologies and real-world project reviews:

Frontend and Cross-Platform: Focused on the progress of Avalonia, Blazor, and WebAssembly, as well as the integrated experience of .NET Aspire in multi-service applications. Speakers shared insights on reusing core logic between desktop and web, shortening cold start times with incremental compilation and resource trimming, and performance profiling and optimization in WASM scenarios.
AI Agents and Enterprise Adoption: Discussed multi-agent orchestration, the MCP plugin ecosystem, and enterprise data compliance. From common pitfalls of “demo-level” AI to the “five-step method” for moving from POC to production, the session covered use cases like knowledge retrieval, process automation, intelligent customer service, and developer assistants, emphasizing evaluation metrics, prompt engineering, and monitoring governance.
.NET Practices and Engineering: Focused on the latest capabilities and performance practices of EF Core, the boundaries of NativeAOT, automated testing strategies, and observability implementation. Discussions included database migration strategies, caching and concurrency control for hot paths, end-to-end tracing, and structured logging.
Solutions and Case Studies: From Clean Architecture/DDD to AI-powered business evolution, topics included application modernization, SaaS transformation, and edge-cloud collaboration in AIoT. Speakers broke down modular governance, team collaboration, and release strategies for complex systems, putting “delivering value continuously” at the center stage.

ABP Booth Highlights: Showcases, Conversations, and Fun

The story of ABP began with a promise to create a better starting point. From the frustration of “copy-pasting boilerplate code,” we crafted a modular, opinionated framework. We chose open source and community collaboration. We founded Volosoft to turn our vision into reality with professional tools. Today, tens of thousands of developers explore the ABP framework, and thousands of teams rely on the ABP platform to deliver production-grade .NET applications faster and more securely.

At .NET Conf China 2025, we brought our “developer platform built for developers” to every visitor. Our booth demonstrations started with “a production-ready skeleton from the start”: modular layered architecture, built-in authentication and authorization systems, multi-tenancy support, audit logging, and localization—all out of the box. On the frontend and backend, ABP offers diverse options like MVC, Blazor, and Angular, enabling teams to quickly implement solutions on familiar stacks while maintaining flexibility for future evolution. We also showcased how ABP integrates with containerization, CI/CD, and observability, emphasizing “engineering built into the framework, not reinvented by every team.”

Interaction and Prizes: Sharing technology should also be warm and engaging. We hosted a QR code raffle at the booth, with prizes including ABP stickers, the book Mastering ABP Framework, and Bluetooth headphones. Multiple rounds of raffles and group photos made the interactions more memorable. Many developers shared their ABP experiences and plans for improvement right at the booth, and a few impromptu “code walkthroughs” naturally happened. The love and joy for technology were captured in every handshake and discussion.

Looking Ahead: Building the Ecosystem Together

From an open-source journey to a complete development platform for the future, we’ve always believed that developers deserve a better starting point. Around performance, intelligence, and cross-platform capabilities, we will continue investing in engineering, ecosystem collaboration, and best practice sharing. We also welcome more partners to contribute through documentation and examples, share your experiences, and submit your ideas. Together, let’s make “useful infrastructure” more stable, efficient, and business-friendly.

We look forward to exchanging ideas, sharing practices, and building the ecosystem together at the next gathering. Technology meets creativity, and the possibilities are endless. We’re on the road and waiting for you at the next event.

See you next year at .NET Conf China 2026!

ABP Suite：EfCoreRepository Template change DbContext

ABP.IO — Fri, 28 Nov 2025 03:25:41 +0000

在 ABP Suite 專案中，若有多個 DbContext，預設的 Repository Template 可能會判斷錯誤，導致產生到錯誤的 DbContext。作者提供了一個簡單方法：修改 EfCoreRepository Template，強制指定使用正確的 DbContext，以確保穩定性與一致性。

Go to the Post

Auto Update OpenIddict Cret by Azure Key Vault

ABP.IO — Wed, 26 Nov 2025 03:42:01 +0000

A practical guide on implementing automated certificate rotation for OpenIddict using **Azure Key Vault**, **Managed Identity**, and **Auto-Renew policies**. It shows how to load all valid certificates at startup, always sign tokens with the newest version, and still validate tokens issued by older certificates. Includes sample code, Key Vault policy.json, and Azure CLI scripts. Ideal for ABP + OpenIddict projects running on Azure App Service.

Go to the Post

My First Look and Experience with Google AntiGravity

ABP.IO — Mon, 24 Nov 2025 13:18:12 +0000

My First Look and Experience with Google AntiGravity

Is Google AntiGravity Going to Replace Your Main Code Editor?

Today, I tried the new code-editor AntiGravity by Google. "It's beyond a code-editor" by Google 🙄 When I first launch it, I see the UI is almost same as Cursor. They're both based on Visual Studio Code. That's why it was not hard to find what I'm looking for.

First of all, the main difference as I see from the Cursor is; when I type a prompt in the agent section AntiGravity first creates a Task List (like a road-map) and whenever it finishes a task, it checks the corresponding task. Actually Cursor has a similar functionality but AntiGravity took it one step further.

Second thing which was good to me; AntiGravity uses Nano Banana 🍌. This is Google's AI image generation model... Why it's important because when you create an app, you don't need to search for graphics, deal with image licenses. AntiGravity generates images automatically and no license is required!

Third exciting feature for me; AntiGravity is integrated with Google Chrome and can communicate with the running website. When I first run my web project, it installed a browser extension which can see and interact with my website. It can see the results, click somewhere else on the page, scroll, fill up the forms, amazing 😵

Another feature I loved is that you can enter a new prompt even while AntiGravity is still generating a response 🧐. It instantly prioritizes the latest input and adjusts the ongoing process if needed. But in Cursor, if you add a prompt before the cursor finishes, it simply queues it and runs it later 😔.

And lastly, AntiGravity is working very good with Gemini 3.

Well, everything was not so perfect 😥 When I tried AntiGravity, couple of times it stucked AI generation and Agent stopped. I faced errors like this 👇

Debugging .NET Projects via AntiGravity

⚠ There's a crucial development issue with AntiGravity (and also for Cursor, Windsurf etc...) 🤕 you cannot debug your .NET application with AntiGravity 🥺. This is Microsoft's policy! Microsoft doesn't allow debugging for 3rd party IDEs and shows the below error... That's why I cannot say it's a downside of AntiGravity. You need to use Microsft's original VS Code, Visual Studio or Rider for debugging. But wait a while there's a workaround for this, I'll let you know in the next section.

What does this error mean?

AntiGravity, Cursor, Windsurf etc... are using Visual Studio Code and the C# extension for VS Code includes the Microsoft .NET Core Debugger "vsdbg". VS Code is open-source but "vsdbg" is not open-source! It's working only with Visual Studio Code, Visual Studio and Visual Studio for Mac. This is clearly stated at Microsoft's this link.

Ok! How to resolve debugging issue with AntiGravity? and Cursor and Windsurf...

There's a free C# debugger extension for Visual Studio Code based IDEs that supports AntiGravity, Cursor and Windsurf. The extension name is C#. You can download this free C# debugger extension at 👉 open-vsx.org/extension/muhammad-sammy/csharp/. For AntiGravity open Extension window (Ctrl + Shift + X) and search for C#, there you'll see this extension.

After installing, I restarted AntiGravity and now I can see the red circle which allows me to add breakpoint on C# code.

Another Extension For Debugging .NET Apps on VS Code

Recently I heard about DotRush extension from the folks. As they say DotRush works slightly faster and support Razor pages (.cshtml files). Here's the link for DotRush https://github.com/JaneySprings/DotRush

Finding Website Running Port

When you run the web project via C# debugger extension, normally it's not using the launch.json therefore the website port is not the one when you start from Visual Studio / Rider... So what's my website's port which I just run now? Normally for ASP.NET Core the default port is 5000. You can try navigating to http://localhost:5000/. Alternatively you can write the below code in Program.cs which prints the full address of your website in the logs. If you do the steps which I showed you, you can debug your C# application via AntiGravity and other VS Code derivatives.

How Much is AntiGravity? 💲

Currently there's only individual plan is available for personal accounts and that's free 👏! The contents of Team and Enterprise plans and prices are not announced yet. But Gemini 3 is not free! I used it with my company's Google Workspace account which we normally pay for Gemini.

More About AntiGravity

There have been many AI assisted IDEs like Windsurf, Cursor, Zed, Replit and Fleet. But this time it's different, this is backed by Google. As you see from the below image AntiGravity, uses a standard grid layout as others based on VS Code editor. It's very similar to Cursor, Visual Studio, Rider.

Supported LLMs 🧠

Antigravity offers the below models which supports reasoning: Gemini 3 Pro, Claude Sonnet 4.5, GPT-OSS

Antigravity uses other models for supportive tasks in the background:

Nano banana : This is used to generate images.
Gemini 2.5 Pro UI Checkpoint : It's for the browser subagent to trigger browser action such as clicking, scrolling, or filling in input.
Gemini 2.5 Flash : For checkpointing and context summarization, this is used.
Gemini 2.5 Flash Lite : And when it's need to make a semantic search in your code-base, this is used.

AntiGravity Can See Your Website

This makes a big difference from traditional IDEs. AntiGravity's browser agent is taking screenshots of your pages when it needs to check. This is achieved by a Chrome Extension as a tool to the agent, and you can also prompt the agent to take a screenshot of a page. It can iterate on website designs and implementations, it can perform UI Testing, it can monitor dashboards, it can automate routine tasks like rerunning CI. This is the link for the extension 👉 chromewebstore.google.com/detail/antigravity-browser-exten/eeijfnjmjelapkebgockoeaadonbchdd. AntiGravity will install this extension automatically on the first run.

MCP Integration

When Do We Need MCP in a Code Editor?

Simply if we want to connect to a 3rd party service to complete our task we need MCP. So AntiGravity can connect to your DB and write proper SQL queries or it can pull in recent build logs from Netlify or Heroku. Also you can ask AntiGravity to to connect GitHub for finding the best authentication pattern.

AntiGravity Supports These MCP Servers

Airweave, AlloyDB for PostgreSQL, Atlassian, BigQuery, Cloud SQL for PostgreSQL, Cloud SQL for MySQL, Cloud SQL for SQL Server, Dart, Dataplex, Figma Dev Mode MCP, Firebase, GitHub, Harness, Heroku, Linear, Locofy, Looker, MCP Toolbox for Databases, MongoDB, Neon, Netlify, Notion, PayPal, Perplexity Ask, Pinecone, Prisma, Redis, Sequential Thinking, SonarQube, Spanner, Stripe and Supabase.

Agent Settings ⚙️

The major settings of Agent are:

Agent Auto Fix Lints : I enabled this setting because I want the Agent automatically fixes its own mistakes for invalid syntax, bad formatting, unused variables, unreachable code or following coding standards... It makes extra tool calls that's why little bit expensive 🥴.
Auto Execution : Sometimes Agent tries to build application or writing test code and running it, in these cases it executes command. I choose "Turbo" 🤜 With this option, Agent always runs the terminal command and controls my browser.
Review Policy : How much control you are giving to agent 🙎. I choose "Always Proceed" 👌 because I mostly trust AI 😀. The Agent will never ask for review.

Differences Between Cursor and AntiGravity

While Cursor was the champion of AI code editors, Antigravity brings a different philosophy.

1. "Agent-First 🤖" vs "You-First 🤠"

Cursor: It acts like an assistant; it predicts your next move, auto-completes your thoughts, and helps you refactor while you type. You are still the driver; Cursor just drives the car at 200 km/h.
Antigravity: Antigravity is built to let you manage coding tasks. It is "Agent-First." You don't just type code; you assign tasks to autonomous agents (e.g., "Fix the bug in the login flow and verify it in the browser"). It behaves more like a junior developer that you supervise.

2. The Interface

Cursor: Looks and feels exactly like VS Code. If you know VS Code, you know Cursor.
Antigravity: Introduces 2 major layouts:

3. Verification & Trust

Cursor: You verify by reading the code diffs it suggests.
Antigravity: Introduces Artifacts... Since the agents work autonomously, they generate proof-of-work documents, screenshots of the app running, browser logs and execution plans. So you can verify what they did without necessarily reading every line of code immediately.

4. Capabilities

Cursor: Best-in-class Autocomplete ("Tab" feature) and Composer (multi-file editing). It excels at "Vibe Coding". It's getting into a flow state where the AI writes the boilerplate and you direct the logic.
Antigravity: Is good at Autonomous Execution. It has a built-in browser and terminal that the Agent controls. The Agent can write code, run the server, open the browser, see the error, and fix it 😎

5. AI Models (Brains 🧠)

Cursor: Model Agnostic. You can switch between Claude 3.5 Sonnet -mostly the community uses this-, GPT-4o, and others.
Antigravity: Built deeply around Gemini 3 Pro. It leverages Gemini's massive context window (1M+ tokens) to understand huge mono repos without needing as much "RAG" as Cursor.

Try It Yourself Now 🤝

If you are ready to experience the new AI code editor by Google, download and use 👇Launch Google AntiGravity

Building Production-Ready LLM Applications with .NET: A Practical Guide

ABP.IO — Mon, 24 Nov 2025 07:33:03 +0000

Building Production-Ready LLM Applications with .NET: A Practical Guide

Large Language Models (LLMs) have evolved rapidly, and integrating them into production .NET applications requires staying current with the latest approaches. In this article, I'll share practical tips and patterns I've learned while building LLM-powered systems, covering everything from API changes in GPT-5 to implementing efficient RAG (Retrieval Augmented Generation) architectures.

Whether you're building a chatbot, a knowledge base assistant, or integrating AI into your enterprise applications, these production-tested insights will help you avoid common pitfalls and build more reliable systems.

The Temperature Paradigm Shift: GPT-5 Changes Everything

If you've been working with GPT-4 or earlier models, you're familiar with the temperature and top_p parameters for controlling response randomness. Here's the critical update : GPT-5 no longer supports these parameters!

The Old Way (GPT-4)

var chatRequest = new ChatOptions
{
    Temperature = 0.7, // ✅ Worked with GPT-4
    TopP = 0.9 // ✅ Worked with GPT-4
};

The New Way (GPT-5)

var chatRequest = new ChatOptions
{
    RawRepresentationFactory = (client => new ChatCompletionOptions()
    {
#pragma warning disable OPENAI001
        ReasoningEffortLevel = "minimal",
#pragma warning restore OPENAI001
    })
};

Why the change? GPT-5 incorporates an internal reasoning and verification process. Instead of controlling randomness, you now specify how much computational effort the model should invest in reasoning through the problem.

Choosing the Right Reasoning Level

Low : Quick responses for simple queries (e.g., "What's the capital of France?")
Medium : Balanced approach for most use cases
High : Complex reasoning tasks (e.g., code generation, multi-step problem solving)

Pro Tip : Reasoning tokens are included in your API costs. Use "High" only when necessary to optimize your budget.

System Prompts: The "Lost in the Middle" Problem

Here's a critical insight that can save you hours of debugging: Important rules must be repeated at the END of your prompt!

❌ What Doesn't Work

You are a helpful assistant.
RULE: Never share passwords or sensitive information.

[User Input]

✅ What Actually Works

You are a helpful assistant.
RULE: Never share passwords or sensitive information.

[User Input]

⚠️ REMINDER: Apply the rules above strictly, ESPECIALLY regarding passwords.

Why? LLMs suffer from the "Lost in the Middle" phenomenon—they pay more attention to the beginning and end of the context window. Critical instructions buried in the middle are often ignored.

RAG Architecture: The Parent-Child Pattern

Retrieval Augmented Generation (RAG) is essential for grounding LLM responses in your own data. The most effective pattern I've found is the Parent-Child approach.

How It Works

Split documents into hierarchies :
Store both in vector database with references
Query flow :

The Overlap Strategy

Always use overlapping chunks to prevent information loss at boundaries!

Chunk 1: Token 0-500
Chunk 2: Token 400-900 ← 100 token overlap
Chunk 3: Token 800-1300 ← 100 token overlap

Standard recommendation : 10-20% overlap (for 500 tokens, use 50-100 token overlap)

Implementation with Semantic Kernel

using Microsoft.SemanticKernel.Text;

var chunks = TextChunker.SplitPlainTextParagraphs(
    documentText, 
    maxTokensPerParagraph: 500,
    overlapTokens: 50
);

foreach (var chunk in chunks)
{
    var embedding = await embeddingService.GenerateEmbeddingAsync(chunk);
    await vectorDb.StoreAsync(chunk, embedding);
}

PostgreSQL + pgvector: The Pragmatic Choice

For .NET developers, choosing a vector database can be overwhelming. After evaluating multiple options, PostgreSQL with pgvector is the most practical choice for most scenarios.

Why pgvector?

✅ Use existing SQL knowledge - No new query language to learn

✅ EF Core integration - Works with your existing data access layer

✅ JOIN with metadata - Combine vector search with traditional queries

✅ WHERE clause filtering - Filter by tenant, user, date, etc.

✅ ACID compliance - Transaction support for data consistency

✅ No separate infrastructure - One database for everything

Setting Up pgvector with EF Core

First, install the NuGet package:

dotnet add package Pgvector.EntityFrameworkCore

Define your entity:

using Pgvector;
using Pgvector.EntityFrameworkCore;

public class DocumentChunk
{
    public Guid Id { get; set; }
    public string Content { get; set; }
    public Vector Embedding { get; set; } // 👈 pgvector type
    public Guid ParentChunkId { get; set; }
    public DateTime CreatedAt { get; set; }
}

Configure in DbContext:

protected override void OnModelCreating(ModelBuilder builder)
{
    builder.HasPostgresExtension("vector");

    builder.Entity<DocumentChunk>()
        .Property(e => e.Embedding)
        .HasColumnType("vector(1536)"); // 👈 OpenAI embedding dimension

    builder.Entity<DocumentChunk>()
        .HasIndex(e => e.Embedding)
        .HasMethod("hnsw") // 👈 Fast approximate search
        .HasOperators("vector_cosine_ops");
}

Performing Vector Search

using Pgvector.EntityFrameworkCore;

public async Task<List<DocumentChunk>> SearchAsync(string query)
{
    // 1. Convert query to embedding
    var queryVector = await _embeddingService.GetEmbeddingAsync(query);

    // 2. Search
    return await _context.DocumentChunks
        .OrderBy(c => c.Embedding.L2Distance(queryVector)) // 👈 Lower is better
        .Take(5)
        .ToListAsync();
}

Source : Pgvector.NET on GitHub

Smart Tool Usage: Make RAG a Tool, Not a Tax

A common mistake is calling RAG on every single user message. This wastes tokens and money. Instead, make RAG a tool and let the LLM decide when to use it.

❌ Expensive Approach

// Always call RAG, even for "Hello"
var context = await PerformRAG(userMessage);
var response = await chatClient.CompleteAsync($"{context}\n\n{userMessage}");

✅ Smart Approach

[KernelFunction]
[Description("Search the company knowledge base for information")]
public async Task<string> SearchKnowledgeBase(
    [Description("The search query")] string query)
{
    var results = await _vectorDb.SearchAsync(query);
    return string.Join("\n---\n", results.Select(r => r.Content));
}

The LLM will call SearchKnowledgeBase only when needed:

"Hello" → No tool call
"What was our 2024 revenue?" → Calls tool
"Tell me a joke" → No tool call

Multilingual RAG: Query Translation Strategy

When your documents are in one language (e.g., English) but users query in another (e.g., Turkish), you need a translation strategy.

Solution Options

Option 1 : Use an LLM that automatically calls tools in English

Many modern LLMs can do this if properly instructed

Option 2 : Tool chain approach

[KernelFunction]
[Description("Translate text to English")]
public async Task<string> TranslateToEnglish(string text)
{
    // Translation logic
}

[KernelFunction]
[Description("Search knowledge base (English only)")]
public async Task<string> SearchKnowledgeBase(string englishQuery)
{
    // Search logic
}

The LLM will:

Call TranslateToEnglish("2024 geliri nedir?")
Get "What was 2024 revenue?"
Call SearchKnowledgeBase("What was 2024 revenue?")
Return results and respond in Turkish

Model Context Protocol (MCP): Beyond In-Process Tools

Microsoft and Anthropic recently released official C# SDKs for the Model Context Protocol (MCP). This is a game-changer for tool reusability.

MCP vs. Semantic Kernel Plugins

| Feature | SK Plugins | MCP Servers | |---------|-----------|-------------| | Process | In-process | Out-of-process (stdio/http) | | Reusability | Application-specific | Cross-application | | Examples | Used within your app | VS Code Copilot, Claude Desktop |

Creating an MCP Server

using Microsoft.Extensions.Hosting;
using ModelContextProtocol.Extensions.Hosting;

var builder = Host.CreateEmptyApplicationBuilder(settings: null);

builder.Services.AddMcpServer()
.WithStdioServerTransport()
.WithToolsFromAssembly();

await builder.Build().RunAsync();

Define your tools:

[McpServerToolType]
public static class FileSystemTools
{
    [McpServerTool, Description("Read a file from the file system")]
    public static async Task<string> ReadFile(string path)
    {
        // ⚠️ SECURITY: Always validate paths!
        if (!IsPathSafe(path)) 
            throw new SecurityException("Invalid path");

        return await File.ReadAllTextAsync(path);
    }

    private static bool IsPathSafe(string path)
    {
        // Implement path traversal prevention
        var fullPath = Path.GetFullPath(path);
        return fullPath.StartsWith(AllowedDirectory);
    }
}

Your MCP server can now be used by VS Code Copilot, Claude Desktop, or any other MCP client!

Chat History Management: Truncation + RAG Hybrid

For long conversations, storing all history in the context window becomes impractical. Here's the pattern that works:

❌ Lossy Approach

First 50 messages → Summarize with LLM → Single summary message

Problem : Detail loss (fidelity loss)

✅ Hybrid Approach

Recent messages (last 5-10): Keep in prompt for immediate context
Older messages : Store in vector database as a tool

[KernelFunction]
[Description("Search conversation history for past discussions")]
public async Task<string> SearchChatHistory(
    [Description("What to search for")] string query)
{
    var relevantMessages = await _vectorDb.SearchAsync(query);
    return string.Join("\n", relevantMessages.Select(m => 
        $"[{m.Timestamp}] {m.Role}: {m.Content}"));
}

The LLM retrieves only relevant past context when needed, avoiding summary-induced information loss.

RAG vs. Fine-Tuning: Choose Wisely

A common misconception is using fine-tuning for knowledge injection. Here's when to use each:

| Purpose | RAG | Fine-Tuning | |---------|-----|-------------| | Goal | Memory (provide facts) | Behavior (teach style) | | Updates | Dynamic (add docs anytime) | Static (requires retraining) | | Cost | Low dev, higher inference | High dev, lower inference | | Hallucination | Reduces | Doesn't reduce | | Use Case | Company docs, FAQs | Brand voice, specific format |

Common mistake : "Let's fine-tune on our company documents" ❌

Better approach : Use RAG! ✅

Fine-tuning is for teaching the model how to respond, not what to know.

Source : Oracle - RAG vs Fine-Tuning

Bonus: Why SVG is Superior for LLM-Generated Images

When using LLMs to generate diagrams and visualizations, always request SVG format instead of PNG or JPG.

Why SVG?

✅ Text-based → LLMs produce better results

✅ Lower cost → Fewer tokens than base64-encoded images

✅ Editable → Easy to modify after generation

✅ Scalable → Perfect quality at any size

✅ Version control friendly → Works great in Git

Example Prompt

Create an architecture diagram showing PostgreSQL with pgvector integration.
Format: SVG, 800x400 pixels. Show: .NET Application → EF Core → PostgreSQL → Vector Search.
Use arrows to connect stages. Color scheme: Blue tones.

All diagrams in this article were generated as SVG, resulting in excellent quality and lower token costs!

Pro Tip : If you don't need photographs or complex renders, always choose SVG.

Architecture Roadmap: Putting It All Together

Here's the recommended stack for building production LLM applications with .NET:

Orchestration : Microsoft.Extensions.AI + Semantic Kernel (when needed)
Vector Database : PostgreSQL + Pgvector.EntityFrameworkCore
RAG Pattern : Parent-Child chunks with 10-20% overlap
Tools : MCP servers for reusability
Reasoning : ReasoningEffortLevel instead of temperature
Prompting : Critical rules at the end
Cost Optimization : Make RAG a tool, not automatic

Key Takeaways

Let me summarize the most important production tips:

Temperature is gone → Use ReasoningEffortLevel with GPT-5
Rules at the end → Combat "Lost in the Middle"
RAG as a tool → Reduce costs significantly
Parent-Child pattern → Search small, respond with large
Always use overlap → 10-20% is the standard
pgvector for most cases → Unless you have billions of vectors
MCP for reusability → One codebase, works everywhere
SVG for diagrams → Better results, lower cost
Hybrid chat history → Recent in prompt, old in vector DB
RAG > Fine-tuning → For knowledge, not behavior

Happy coding! 🚀

Announcing Server-Side Rendering Support for ABP Framework Angular Applications

ABP.IO — Thu, 20 Nov 2025 06:46:59 +0000

Announcing Server-Side Rendering (SSR) Support for ABP Framework Angular Applications

We are pleased to announce that Server-Side Rendering (SSR) has become available for ABP Framework Angular applications! This highly requested feature brings major gains in performance, SEO, and user experience to your Angular applications based on ABP Framework.

What is Server-Side Rendering (SSR)?

Server-Side Rendering refers to an approach which renders your Angular application on the server as opposed to the browser. The server creates the complete HTML for a page and sends it to the client, which can then show the page to the user. This poses many advantages over traditional client-side rendering.

Why SSR Matters for ABP Angular Applications

Improved Performance

Quicker visualization of the first contentful paint (FCP): Because prerendered HTML is sent over from the server, users will see content quicker.
Better perceived performance : Even on slower devices, the page will be displaying something sooner.
Less JavaScript parsing time : For example, the initial page load will not require parsing and executing a large bundle of JavaScript.

Enhanced SEO

Improved indexing by search engines : Search engine bots are able to crawl and index your content quicker.
Improved rankings in search : The quicker the content loads and the easier it is to access, the better your SEO score.
Preview when sharing on social channels : Rich previews with the appropriate meta tags are generated when sharing links on social platforms.

Better User Experience

Support for low bandwidth : Users with slower Internet connections will have a better experience
Progressive enhancement : Users can start accessing the content before JavaScript has loaded
Better accessibility : Screen readers and other assistive technologies can access the content immediately

Getting Started with SSR

Adding SSR to an Existing Project

You can easily add SSR support to your existing ABP Angular application using the Angular CLI with ABP schematics:

Adds SSR configuration to your project

ng generate @abp/ng.schematics:ssr-add

Short form

ng g @abp/ng.schematics:ssr-add

If you have multiple projects in your workspace, you can specify which project to add SSR to:

ng g @abp/ng.schematics:ssr-add --project=my-project

If you want to skip the automatic installation of dependencies:

ng g @abp/ng.schematics:ssr-add --skip-install

What Gets Configured

When you add SSR to your ABP Angular project, the schematic automatically:

Installs necessary dependencies : Adds @angular/ssr and related packages
Creates Server Configuration : Creates server.ts and related files
Updates Project Structure :
- Creates main.server.ts to bootstrap the server
- Adds app.config.server.ts for standalone apps (or app.module.server.ts for NgModule apps)
- Configures server routes in app.routes.server.ts
Updates Build Configuration : updates angular.json to include:
- a serve-ssr target for local SSR development
- a prerender target for static site generation
- Proper output paths for browser and server bundles

Supported Configurations

The ABP SSR schematic supports both modern and legacy Angular build configurations:

Application Builder (Suggested)

The new @angular-devkit/build-angular:application builder
Optimized for Angular 17+ apps
Enhanced performance and smaller bundle sizes

Server Builder (Legacy)

The original @angular-devkit/build-angular:server builder
Designed for legacy Angular applications
Compatible with legacy applications

Running Your SSR Application

After adding SSR to your project, you can run your application in SSR mode:

# Development mode with SSR
ng serve

# Or specifically target SSR development server
npm run serve:ssr

# Build for production
npm run build:ssr

# Preview production build
npm run serve:ssr:production

Important Considerations

Browser-Only APIs

Some browser APIs are not available on the server. Use platform checks to conditionally execute code:

import { isPlatformBrowser } from '@angular/common';
import { PLATFORM_ID, inject } from '@angular/core';

export class MyComponent {
  private platformId = inject(PLATFORM_ID);

  ngOnInit() {
    if (isPlatformBrowser(this.platformId)) {
      // Code that uses browser-only APIs
      console.log('Running in browser');
      localStorage.setItem('key', 'value');
    }
  }
}

Storage APIs

localStorage and sessionStorage are not accessible on the server. Consider using:

Cookies for server-accessible data.
The state transfer API for hydration.
ABP's built-in storage abstractions.

Third-Party Libraries

Please ensure that any third-party libraries you use are compatible with SSR. These libraries can require:

Dynamic imports for browser-only code.
Platform-specific service providers.
Custom Angular Universal integration.

ABP Framework Integration

The SSR implementation is natively integrated with all of the ABP Framework features:

Authentication & Authorization : The OAuth/OpenID Connect flow functions seamlessly with ABP
Multi-tenancy : Fully supports tenant resolution and switching
Localization : Server-side rendering respects the locale
Permission Management : Permission checks work on both server and client
Configuration : The ABP configuration system is SSR-ready

Performance Tips

Utilize State Transfer : Send data from server to client to eliminate redundant HTTP requests
Optimize Images : Proper image loading strategies, such as lazy loading and responsive images.
Cache API Responses : At the server, implement proper caching strategies.
Monitor Bundle Size : Keep your server bundle optimized
Use Prerendering : The prerender target should be used for static content.

Conclusion

Server-side rendering can be a very effective feature in improving your ABP Angular application's performance, SEO, and user experience. Our new SSR schematic will make it easier than ever to add SSR to your project.

Try it today and let us know what you think!