The new ABP Studio release introduces a deeply integrated set of features designed around one idea: an AI coding agent that truly understands ABP solutions, sitting inside an IDE that already knows how to build, run, monitor, and iterate on them.

At the center is ABP Agent, our AI coding assistant. Around it are long-standing ABP Studio capabilities that have been brought together into a single development loop. Together they turn ABP Studio into a single place where you architect and code your ABP solutions.

Meet ABP Agent

ABP Agent is the AI coding assistant built into ABP Studio. It operates in three modes, each tuned for a different stage of work:

• Agent mode: the implementation mode. The agent reads the solution, writes and edits files, builds the affected projects, runs your apps, watches the runtime, and iterates until the change works end-to-end.
• Plan mode: read-only planning. The agent investigates the codebase, researches the official ABP documentation, and produces a structured implementation plan (Problem, Solution, Workflow Diagram, Files Affected, Expected Result). When you are happy with the plan, a single click promotes it into Agent mode and the implementation starts from the plan.
• Ask mode: read-only Q&A. The agent explains how something works, draws diagrams, and answers questions about your code without touching any files.

The agent is ABP-aware by default. It is instructed to prefer ABP base classes over plain POCOs, repositories over direct DbContext injection, ApplicationService over plain services, the ABP permission system over [Authorize(Roles=…)], localized strings over hardcoded text, BusinessException/UserFriendlyException over plain Exception, the distributed cache abstraction over raw memory cache, and background job abstractions over hand-rolled hosted services. When it is unsure about an ABP feature, it consults the official ABP documentation as a primary source of truth, not random blog posts on the web.

Why It Was Needed

General-purpose AI coding tools (Cursor, Claude Code, Windsurf, opencode and similar) are excellent for horizontal, file-shaped work. They read source files, edit them, and run shell commands. That works well for small scripts or front-end apps.

ABP solutions are different. A typical ABP solution is system-shaped, not just file-shaped: the important context is not only where files are located, but how modules, layers, permissions, contracts, localization, persistence, and UI pieces work together:

• It is split across multiple modules and layers (Domain, Application, EntityFrameworkCore, HttpApi, Web, etc.) with strict dependency rules.
• It is composed of many runnable units: HTTP services, gateways, identity servers, background workers, SPAs, mobile apps, plus the Docker containers they depend on.
• It follows a strong set of conventions: aggregate roots, repositories, application services, DTOs, permissions, localization, event bus, distributed cache, background jobs.
• It is a living system at design time. You don't just read code, you run it, watch logs, follow distributed events, hit HTTP endpoints, and iterate.

A generic agent has none of that vocabulary. It does not know what a module is, which project is the Domain layer, or that an ApplicationService should not depend on a DbContext directly. It cannot start "the gateway, the auth server, and the two microservices my React app talks to". It just runs dotnet run in some folder and hopes. It cannot tell you that the agent's latest edit caused a runtime exception in the Identity service or made the OrderPlacedEto event handler silently fail, because it has no concept of "running app".

ABP Agent and the surrounding ABP Studio features were built to close exactly that gap. The agent is born inside an IDE that already understands modules, run profiles, builds, migrations, proxies, Docker containers, Kubernetes services, and distributed runtime telemetry, and it uses every one of them.

How ABP Agent Sees Your Application: The Analyze Engine

Before ABP Agent answers anything, it needs to understand your solution. This is where the Analyze feature does the heavy lifting.

When you open a solution, ABP Studio analyzes every package and builds a structural map: the application's skeleton. It identifies what each type actually is in ABP terms: an aggregate root, an entity, a value object, a repository interface or implementation, a domain service, an application service or interface, a DTO, an integration service, a controller, an HTTP API, a background job or worker, an event handler, an ETO, a SignalR hub, a DbContext (EF Core or MongoDB), a permission/feature/setting provider, a global feature, a Mapperly or AutoMapper profile, a fluent validator, a menu contributor, a data seed contributor, an options class, an ABP module with its [DependsOn] chain, and many more.

For each of these, the analyzer captures the structural information that actually matters: properties, method signatures with their line ranges, injected dependencies, base classes, the permission groups and items, the feature tree, the settings catalog, the database tables and collections, without parsing C# at runtime.

ABP Agent receives this analyzed skeleton at the start of every session. That means:

• The agent already knows what types exist in each project and what role each one plays, before you ask anything.
• When you say "add a Category to my Catalog module", the agent already knows where the Domain project is, what the existing aggregate roots look like, which DbContext should get the new entity, where the permissions provider lives, and which application service to extend.
• When the agent needs to change an existing type, it can fetch a precise outline (base classes, properties, method signatures with exact line ranges) instead of reading thousands of lines of source. That is dramatically faster, dramatically cheaper, and dramatically more accurate.
• When you modify code, ABP Studio re-analyzes only the affected packages and refreshes the agent's understanding.

This is what we mean by solution-aware AI. The agent does not "look at folders and guess"; it works from a typed, ABP-shaped index of your application.

Native .NET Awareness: No Shell Gymnastics

A common pattern in generic agentic IDEs is to do everything through the terminal. Building? Run dotnet build in a shell. Restarting an app? Spawn a process. Adding a migration? More shell. Checking whether the build succeeded? Parse terminal output and pray.

ABP Agent does not work through a terminal for these things. Building, running, restarting, adding migrations, generating proxies, installing client-side libraries: all of these are first-class operations the agent invokes directly. Build calls return structured results with errors and warnings the agent can act on immediately. Starting an application returns a structured outcome: which apps started, which failed, and a summarized error log for each failure. There is no string-scraping, no "did the spinner stop yet?" guessing.

The agent also scopes builds intelligently. It can build a single project, a single module, or the entire solution depending on what changed. After editing a few files in your Application layer, it builds just that module (not the whole solution), and only escalates the scope when needed.

Solution Runner & Live Runtime Monitor

This is the half of ABP Agent that no general-purpose AI IDE can replicate, because no general-purpose AI IDE has a first-class runner for distributed .NET solutions.

Solution Runner is the ABP Studio feature that knows about every runnable thing in your solution: web apps, microservices, gateways, identity servers, background workers, CLI applications, mobile and SPA front-ends, plus the Docker containers your stack depends on (databases, caches, message brokers). Apps are grouped into folders and can be launched as a coherent set under a named run profile. You start everything with one click; ABP Studio handles ports, dependencies, restart-on-failure, and embedded browser previews.

ABP Agent talks to the Solution Runner directly. It can:

• Start, stop, or restart a specific application, every application inside a folder ("Backend/API"), or all applications.
• Start or stop Docker containers separately from applications.
• Run tasks defined in your run profile (database migrations, npm scripts, custom scripts).

When the agent starts an application that crashes on startup, it does not loop forever restarting it. It captures the recent logs from that application, summarizes the failure, returns a structured report to itself, and uses that to fix the underlying bug in the code before trying again.

But starting apps is only half of it. The runtime monitor is the other half. When your applications run under ABP Studio, the IDE collects, in real time:

• Exceptions: type, message, full stack trace, inner exceptions, source application.
• Logs: timestamps, log level, application, message.
• HTTP requests: method, URL, status code, response time.
• Distributed events: name, source, direction (published/received), and payload.

ABP Agent can query all of this. The development loop becomes:

Generate the code → Build the affected module → Restart the affected application → Hit the endpoint or perform the action → Ask the agent to inspect the last exceptions, the failing HTTP requests, and the distributed events → Fix the bug → Repeat.

That is the loop a generic IDE cannot do, because it cannot see your application after it starts. ABP Agent can.

Custom Workflows & Task Runner Integration: Determinism When You Need It

LLMs are powerful but non-deterministic. In real teams, some steps must happen every time (before or after the agent works) and they must happen in a known order. That is what Custom Workflows are for.

A workflow is a named sequence of deterministic steps with a Before phase and an After phase. You can configure steps such as:

• Build (whole solution, specific modules, or specific packages)
• Start, stop, or restart applications (specific apps, an entire folder, or all)
• Start or stop containers
• Run a Task (any custom task defined in your run profile: npm install, custom scripts, code generators, database resets, anything your team already wired into ABP Studio's Task Runner)
• Add a database migration
• Install client-side libraries
• Generate C# or Angular client proxies for HTTP APIs

For example, you can configure a workflow that:

• Before the agent works: starts the required containers and runs a code-generation Task.
• After the agent works: builds the affected modules, regenerates client proxies, restarts the gateway and the SPA, and adds a database migration.

Workflows can be personal to you, or shared with your team through the solution's run profile file, so the deterministic pre/post pipeline travels with the repository and every developer gets the same behavior.

The result is a clean separation: the LLM handles the creative, ambiguous middle (designing the change and writing the code), while your workflow guarantees the boring, must-happen steps around it. The agent becomes more deterministic exactly where determinism matters, without losing flexibility where it doesn't.

The Task Runner integration is what makes the After phase especially valuable. You can run absolutely anything as a post-step: npm scripts, custom executables, code generators, integration test runners, lint passes, database refresh scripts. If your team already runs it as part of "I just changed some code, now do X", you can run it automatically after every agent turn.

Git & GitHub: Reviewing and Committing Without Leaving the IDE

ABP Studio now ships a full Git client with deep GitHub integration. The goal is simple: once the agent finishes a change, you should be able to review, commit, push, branch, and respond to review feedback without ever leaving ABP Studio.

The Git side covers everything you'd expect:

• Stage and commit changes with rich, package-grouped change views.
• Create, switch, and merge branches.
• Stash and restore work, including a clear flow for stashing before switching branches.
• View commit history and create branches from any commit.
• Resolve merge conflicts with a built-in conflict editor.
• Push, pull, fetch, with seamless OAuth-based GitHub authentication.

On the GitHub side:

• Browse and filter Issues, view their comments, and send an issue (or just its comments) directly to ABP Agent to start working on it.
• View existing Pull Requests, see their requested changes and comments inline, and send the requested-changes feedback straight into ABP Agent so it can address the reviewer's comments. You can send the feedback into the same session you used to write the change, or start a fresh agent session.
• A one-click "Create Pull Request" action opens the new-PR page on GitHub directly from the IDE, pre-targeted at the current branch.
• Jump to any file on GitHub directly from the IDE.

Two AI-assisted touches make this loop especially smooth:

• AI-generated commit messages. Click "Generate with AI" and ABP Agent writes a Conventional Commits-style message from the staged diff. Edit it if you want, then commit.
• AI Code Review on the diff. Select the files you want reviewed, run AI review, and inline suggestions stream into the IDE as the analysis runs. Crucially, this is not a generic code review; it is an ABP-aware review. The reviewer looks for ABP-specific pattern violations: plain POCOs where ABP base classes belong, direct DbContext injection where a repository should be used, hardcoded strings where localization should be used, plain exceptions where BusinessException belongs, role-based authorization where ABP Permissions are the right answer, and so on. When the reviewer is unsure, it consults the official ABP documentation before flagging an issue.

The result is a closed loop: the agent writes the change, you (or the AI reviewer agent) review the diff, you let the agent fix the comments, you commit with an AI-suggested message, you push, and you head to GitHub for the pull request, all from inside ABP Studio.

The End-to-End Development Loop

Put the pieces together and ABP Studio becomes the single place where the whole development cycle happens:

1. Open an issue from GitHub, send it to ABP Agent.
2. Switch to Plan mode; ABP Agent investigates the analyzed solution, consults the ABP docs, produces a structured plan.
3. Promote the plan to Agent mode. Implementation starts from the plan.
4. The Before workflow runs (start containers, run preparation tasks).
5. ABP Agent writes the code, batching edits across the affected modules, and fixes any compile errors directly.
6. The After workflow runs (build the affected modules, install client-side libraries, generate proxies, add a database migration, restart the impacted applications).
7. ABP Agent inspects the runtime monitor (exceptions, logs, HTTP requests, distributed events) and fixes any bug it sees.
8. You (or the AI reviewer) review the diff. Comments are sent back into the same agent session, or into a new one.
9. ABP Agent generates a commit message; you commit and push.
10. Open the new-pull-request page on GitHub with one click from ABP Studio. When reviewers leave requested changes, send them into the same agent session or start a fresh one, and iterate.

You do not need to switch to a terminal to build. You do not need a separate tool to start your microservices. You do not need a different IDE to watch logs. You do not need a separate window for Git and GitHub. ABP Studio is the only program you use during development, all in one.

Learning Over Time

ABP Agent also has a small but powerful feedback feature: when it makes a mistake and you (or the build, or the ABP docs) correct it, it can save that correction as a lesson. Lessons are short, verified notes that the agent carries forward into future turns and future sessions, so the same mistake does not happen twice. Over time, the agent gets better at the specific conventions and quirks of your solution, not just generic ABP.

Honest Comparison With Generic AI IDEs

To be fair: Cursor, Claude Code, Windsurf and opencode are excellent products. They have semantic search, plan/agent modes, sub-agents, file editing, and shell access, and we wouldn't dispute any of that. But for ABP development specifically, here is where ABP Agent is genuinely different:

| Capability | ABP Agent | Generic AI IDEs | | --- | --- | --- | | Aware of ABP roles (aggregate root, app service, repository, DTO, ETO, event handler, etc.) | Yes, structurally indexed | No (flat file/text view) | | Knows your solution's modules, layers and dependency rules | Yes | No | | Builds with module/package scope as a first-class operation | Yes, structured build result | No, runs dotnet build in a shell and parses output | | First-class Solution Runner for distributed .NET apps + containers | Yes | No, generic shell processes | | Restarting an application, opening its URL, waiting for it to be ready | Yes, built in | No | | Live runtime telemetry as a tool: exceptions, logs, HTTP requests, distributed events | Yes | No | | ABP-specific patterns checked during AI code review | Yes | Generic patterns only | | Pre/post workflows with deterministic build / start / migrate / generate-proxies steps | Yes | No first-class concept | | Task Runner integration for arbitrary pre/post steps owned by your team | Yes | No | | Adding EF Core migrations as a first-class agent action | Yes | Shell only | | Generating C#/Angular client proxies as a first-class agent action | Yes | Shell only | | Native ABP documentation as authoritative source for the agent's decisions | Yes | Generic web search | | Integrated Git + GitHub (issues, PR viewing, AI review) inside the same window | Yes | Partial / external |

The pattern is consistent: anything ABP-specific or runtime-specific belongs to ABP Agent and ABP Studio. Anything general-purpose is something everyone has. That is the line we drew on purpose.

What This Means For You

If you build with ABP Framework, this release changes how you work in three concrete ways:

1. You stop describing your solution to the AI. ABP Agent already knows it.
2. You stop bouncing between tools. Editor, runner, runtime monitor, Git, GitHub, AI review, they all live in one window with one feedback loop.
3. You stop accepting non-deterministic side effects. Custom workflows + Task Runner integration make the boring steps boring again, while the agent focuses on the creative ones.

This is the first release that brings AI assistance to ABP Studio, and we built it so that it is designed around the agent rather than bolted on. We think this is the natural shape of AI-assisted enterprise .NET development.

Short-Term Roadmap

This release is the first step. The features below are already on our short-term roadmap and will land in upcoming releases:

• Debug Mode: a dedicated mode where you and ABP Agent co-operate when debugging the solution. The agent can follow breakpoints, inspect state, propose fixes mid-session, and re-run after each change.
• Browser control for the agent: ABP Agent will be able to drive the embedded browser, browse pages, fill forms, and click buttons, so it can verify a UI flow end-to-end on its own and report what it observed.
• Custom Workflows improvements: more step types, richer conditions, finer-grained targets, and better visibility into which workflow ran for which agent turn.
• GitHub integration improvements: in-IDE pull request creation (no more jumping to the GitHub website), richer review handling, and more first-class issue and PR actions for the agent.
• Git integration improvements: more advanced day-to-day Git operations available without leaving the IDE.
• Design helper: ABP Agent will generate images.
• Create a new project with the agent: an AI-driven solution creation flow where you describe the application you want and ABP Agent helps choose the right template, modules, and configuration.
• ABP Suite integration: ABP Agent will be able to invoke ABP Suite for CRUD-page generation. Instead of asking the LLM to write the full set of layers for a CRUD page (which spends a lot of tokens and time), the agent will hand the task to ABP Suite, get a deterministic, production-quality result back, and continue with the parts that actually need the AI.

Live Demo

We have previewed the ABP Agent in our latest community talk. Click to watch it:

Also see

• https://abp.io/studio/ai-agent

We're excited to announce a new improvement to Docker integration in ABP Studio! With the latest update, you can now manage Docker containers individually, add or remove them dynamically, and launch them either separately or collectively — all within the Studio.

🔄 What Has Changed?

In previous versions, Docker dependencies were handled using a single docker-compose.override.yml file, which was automatically generated when creating a new solution if it is needed.

By default, this file included common development dependencies like PostgreSQL, Redis, RabbitMQ, etc., and was executed through a predefined script named docker-dependencies in the Solution Runner.

While this approach worked well for simple setups, it had some limitations:

• All services were bundled into a single compose file.
• Adding or removing services required modifying this central file.
• It wasn't possible to start or stop individual containers independently.

✅ What's New?

With the latest ABP Studio update:

• Each Docker container can now be defined in its own docker-compose file.
• Compose files can be added or removed from the Studio UI.
• Containers can be:
  • Started or stopped individually.
  • Started/stopped in bulk.
• The Solution Runner recognizes Docker containers and can run them alongside application projects.

⚠️ Important Notes Before You Start

Required: Use container_name for Docker Service Matching

When working with the new modular Docker system in ABP Studio, each service must define a container_name. This name is used by ABP Studio to identify and map Docker containers to their corresponding service entries in the Studio UI.

Why is this mandatory?

• ABP Studio relies on container_name to:
  • Detect whether the service is stopped or continue running.
  • Perform start, stop, and status check operations reliably.
  • Match Studio UI entries with actual running Docker containers.
• Without a container_name, container discovery may fail and service management features might not work as expected.

Example:

services:
  redis:
    container_name: redis
    image: redis:7
    ports:
      - "6379:6379"
    networks:
      - my-network

If you do not define container_name, ABP Studio will be unable to track or control the service properly.

📥 Migrating from the Old System

If you're using the old method with a centralized compose file:

Before:

docker-compose -f docker-compose.override.yml up -d

Now:

1. Create separate docker-compose files for each service (e.g., docker-compose.postgres.yml, docker-compose.redis.yml).
2. Go to the Solution Runner tab in ABP Studio.
3. Use the “Add Docker Service” option in Studio to register each file.
4. Optionally remove or archive the old monolithic compose file.

If your original docker-compose.override.yml contains multiple services, you can split it into individual files — Docker Compose and ABP Studio both support modular composition.

⚙️ Advanced: Shared Network

If your containers need to communicate over a shared network, you can define an external network in each compose file like this:

networks:
  my-network:
    external: true

ABP Studio automatically creates the network if they do no exist. But if you like you can create the network once using:

docker network create my-network

📚 Additional Resources

• Docker Compose Documentation
• ABP Studio Documentation (link to updated docs when ready)
• Report Issues on GitHub

In this article, we will build a basic real time messaging application in a distributed architecture. We will use Abp Framework for infrastructure and tiered startup template, SignalR for real time server-client communication and RabbitMQ as the distributed event bus.

When Web & API tiers are separated, it is impossible to directly send a server-to-client message from the HTTP API. This is also true for a microservice architected application. We suggest to use the distributed event bus to deliver the message from API application to the web application, then to the client.

Above, you can see the data-flow that we will implement in this article. This diagram represents how data will flow in our application when Client 1 sends a message to Client 2. It is explained in 5 steps:

1. Client 1 sends a message data to Web Application via REST call.
2. Web Application redirects the message data to Http Api.
3. The message data is processed in Http Api and Http Api publishes an event that holds the data that will be sent to Client 2.
4. Web application, that is subscribed to that event, receives it.
5. Web Application sends the message to Client 2.

For this example flow, we could send message from Client 1 to Client 2 directly on the SignalR Hub. However, what we are trying here to demonstrate is sending a real-time message from the Http Api to a specific user who is connected to the web application.

Implementation

Startup template and initial run

Abp Framework offers startup templates to get into the business faster. We can download a new tiered startup template using Abp CLI:

abp new SignalRTieredDemo --tiered

After download is finished, we run *.DbMigrator project to create the database and seed initial data (admin user, role etc). Then we run *.IdentityServer, *.HttpApi.Host and *.Web to see our application working.

Creating Application Layer

We create an application service that publishes the message as event.

In *.Application.Contracts project:

using System.Threading.Tasks;
using Volo.Abp.Application.Services;

namespace SignalRTieredDemo
{
    public interface IChatAppService : IApplicationService
    {
        Task SendMessageAsync(SendMessageInput input);
    }
}

Input DTO for SendMessageAsync method:

namespace SignalRTieredDemo
{
    public class SendMessageInput
    {
        public string TargetUserName { get; set; }

        public string Message { get; set; }
    }
}

Event transfer object (ETO) for communication on event bus:

using System;

namespace SignalRTieredDemo
{
    public class ReceivedMessageEto
    {
        public string ReceivedText { get; set; }

        public Guid TargetUserId { get; set; }

        public string SenderUserName { get; set; }

        public ReceivedMessageEto(
        Guid targetUserId, string senderUserName, string receivedText)
        {
            ReceivedText = receivedText;
            TargetUserId = targetUserId;
            SenderUserName = senderUserName;
        }
    }
}

In *.Application project:

using System.Threading.Tasks;
using Microsoft.AspNetCore.Identity;
using Volo.Abp.EventBus.Distributed;
using Volo.Abp.Identity;

namespace SignalRTieredDemo
{
    public class ChatAppService: SignalRTieredDemoAppService, IChatAppService
    {
        private readonly IIdentityUserRepository _identityUserRepository;
        private readonly ILookupNormalizer _lookupNormalizer;
        private readonly IDistributedEventBus _distributedEventBus;

        public ChatAppService(IIdentityUserRepository identityUserRepository, ILookupNormalizer lookupNormalizer, IDistributedEventBus distributedEventBus)
        {
            _identityUserRepository = identityUserRepository;
            _lookupNormalizer = lookupNormalizer;
            _distributedEventBus = distributedEventBus;
        }

        public async Task SendMessageAsync(SendMessageInput input)
        {
            var targetId = (await _identityUserRepository.FindByNormalizedUserNameAsync(_lookupNormalizer.NormalizeName(input.TargetUserName))).Id;

            await _distributedEventBus.PublishAsync(new ReceivedMessageEto(targetId, CurrentUser.UserName, input.Message));
        }
    }
}

Creating API Layer

We create an endpoint for sending message that redirects the process to application layer:

In controllers folder of *.HttpApi project:

using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Volo.Abp.AspNetCore.Mvc;

namespace SignalRTieredDemo.Controllers
{
    [Route("api/app/chat")]
    public class ChatController : AbpController, IChatAppService
    {
        private readonly IChatAppService _chatAppService;

        public ChatController(IChatAppService chatAppService)
        {
            _chatAppService = chatAppService;
        }

        [HttpPost]
        [Route("send-message")]
        public async Task SendMessageAsync(SendMessageInput input)
        {
            await _chatAppService.SendMessageAsync(input);
        }
    }
}

Adding SignalR

To add SignalR to our solution, we add Volo.Abp.AspNetCore.SignalR nuget package to *.Web project.

And then add AbpAspNetCoreSignalRModule dependency:

namespace SignalRTieredDemo.Web
{
    [DependsOn(
        ...
        typeof(AbpAspNetCoreSignalRModule) // <---
        )]
    public class SignalRTieredDemoWebModule : AbpModule
    {

Also, we need to add @abp/signalr npm package to package.json in *.Web project, then run abp install-libs command.

{
  .
  .
  "dependencies": {
    .
    .
    "@abp/signalr": "^2.9.0"
  }
}

Remember to add the latest package version.

You can find more information for Abp SignalR Integration on the related document.

Creating A Hub

We need a hub for SignalR connection. We can inherit it from AbpHup base class.

In *.Web project:

using Microsoft.AspNetCore.Authorization;
using Volo.Abp.AspNetCore.SignalR;

namespace SignalRTieredDemo.Web
{
    [Authorize]
    public class ChatHub : AbpHub
    {
    }
}

While you could inherit from the standard Hub class, AbpHub has some common services pre-injected as base properties, which is useful on your development.

Adding & Configuring RabbitMQ

To add RabbitMQ to our solution, we add Volo.Abp.EventBus.RabbitMQ nuget package to *.HttpApi.Host and *.Web projects.

Launch a command line, navigate to directory where *.HttpApi.Host.csproj file exist, and run the command below using Abp CLI:

 abp add-package Volo.Abp.EventBus.RabbitMQ

Then do the same for *.Web project.

After we add the package, we configure RabbitMQ by adding configuration in appsettings.json files of those projects.

For *.HttpApi.Host project:

{
  ...
  "RabbitMQ": {
    "Connections": {
      "Default": {
        "HostName": "localhost"
      }
    },
    "EventBus": {
      "ClientName": "SignalRTieredDemo_HttpApi",
      "ExchangeName": "SignalRTieredDemoTest"
    }
  },
  ...
}

For *.Web project:

{
  ...
  "RabbitMQ": {
    "Connections": {
      "Default": {
        "HostName": "localhost"
      }
    },
    "EventBus": {
      "ClientName": "SignalRTieredDemo_Web",
      "ExchangeName": "SignalRTieredDemoTest"
    }
  },
  ...
}

Handling New Message Event

Once we publish a new message event from Http Api, we must to handle it in Web Application. Therefore we need an event handler in *.Web Project:

using System.Threading.Tasks;
using Microsoft.AspNetCore.SignalR;
using Volo.Abp.DependencyInjection;
using Volo.Abp.EventBus.Distributed;

namespace SignalRTieredDemo.Web
{
    public class ReceivedMessageEventHandler :    
        IDistributedEventHandler<ReceivedMessageEto>, 
        ITransientDependency
    {
        private readonly IHubContext<ChatHub> _hubContext;

        public ReceivedMessageEventHandler(IHubContext<ChatHub> hubContext)
        {
            _hubContext = hubContext;
        }

        public async Task HandleEventAsync(ReceivedMessageEto eto)
        {
            var message = $"{eto.SenderUserName}: {eto.ReceivedText}";

            await _hubContext.Clients
                .User(eto.TargetUserId.ToString())
                .SendAsync("ReceiveMessage", message);
        }
    }
}

Creating Chat Page

We create the files below in Pages folder of *.Web Project.

Chat.cshtml:

@page
@using Volo.Abp.AspNetCore.Mvc.UI.Packages.SignalR
@model SignalRTieredDemo.Web.Pages.ChatModel
@section styles {
    <abp-style src="/Pages/Chat.css" />
}
@section scripts {
    <abp-script type="typeof(SignalRBrowserScriptContributor)" />
    <abp-script src="/Pages/Chat.js" />
}
<h1>Chat</h1>

<div>
    <abp-row>
        <abp-column size-md="_6">
            <div>All Messages:</div>
            <ul id="MessageList" style="">
            </ul>
        </abp-column>
        <abp-column size-md="_6">
            <form>
                <abp-row>
                    <abp-column>
                        <label for="TargetUser">Target user:</label>
                        <input type="text" id="TargetUser" />
                    </abp-column>
                </abp-row>
                <abp-row class="mt-2">
                    <abp-column>
                        <label for="Message">Message:</label>
                        <textarea id="Message" rows="4"></textarea>
                    </abp-column>
                </abp-row>
                <abp-row class="mt-2">
                    <abp-column>
                        <abp-button type="submit" id="SendMessageButton" button-type="Primary" size="Block" text="SEND!" />
                    </abp-column>
                </abp-row>
            </form>
        </abp-column>
    </abp-row>
</div>

Chat.cshtml.cs:

using Microsoft.AspNetCore.Mvc.RazorPages;

namespace SignalRTieredDemo.Web.Pages
{
    public class ChatModel : PageModel
    {
        public void OnGet()
        {
        }
    }
}

Chat.css:

#MessageList {
    border: 1px solid gray;
    height: 400px;
    overflow: auto;
    list-style: none;
    padding-left: 0;
    padding: 10px;
}

#TargetUser {
    width: 100%;
}

#Message {
    width: 100%;
}

Chat.js:

$(function () {
    var connection = new signalR.HubConnectionBuilder().withUrl("/signalr-hubs/chat").build();

    connection.on("ReceiveMessage", function (message) {
        console.log(message);
        $('#MessageList').append('<li><strong><i class="fas fa-long-arrow-alt-right"></i> ' + message + '</strong></li>');
    });

    connection.start().then(function () {

    }).catch(function (err) {
        return console.error(err.toString());
    });

    $('#SendMessageButton').click(function (e) {
        e.preventDefault();

        var targetUserName = $('#TargetUser').val();
        var message = $('#Message').val();
        $('#Message').val('');


        signalRTieredDemo.controllers.chat.sendMessage({
            targetUserName: targetUserName,
            message: message
        }).then(function() {
            $('#MessageList')
                .append('<li><i class="fas fa-long-arrow-alt-left"></i> ' + abp.currentUser.userName + ': ' + message + '</li>');
        });
      
    });
});

Then we can add this new page to menu on *MenuContributor.cs in Menus folder:

    ...
    public class SignalRTieredDemoMenuContributor : IMenuContributor
    {
        ...
        private Task ConfigureMainMenuAsync(MenuConfigurationContext context)
        {
        ...
            context.Menu.Items.Add(new ApplicationMenuItem("SignalRDemo.Chat", "Chat", "/Chat")); // <-- We add this line

            return Task.CompletedTask;
        }
      ...
    }

Running & Testing

We run *.IdentityServer, *.HttpApi.Host and *.Web in order. After *.Web project is ran, firstly login with admin username and 1q2w3E* password.

After we login, go to /Identity/Users page and create a new user. So that we can chat with them.

Then we open the application in another browser and login with the user we created above. Now we can go to chat page and start messaging:

We can test with more user. All sent and incoming messages are displayed in the left box.

Source code

Source code of the final application can be found on the GitHub repository.