Forem: ismail Cagdas

Angular vs React for ASP.NET Core: A Comprehensive Comparison Guide (2026)

ismail Cagdas — Fri, 17 Apr 2026 09:28:52 +0000

If you are starting a new project on ASP.NET Core in 2026, the single biggest frontend decision you will make is Angular vs React. Both frameworks pair beautifully with a .NET backend, both have Visual Studio templates, and both are used by Fortune 500 companies to ship serious enterprise applications. Yet they come from very different philosophies — and that difference has real consequences for your team, your codebase, and your velocity three years from now.

I know that you probably also consider Blazor and Vue.js, but in my opinion, Blazor is slow and has many performance problems for an enterprise application. Vue.js is a great framework technically — it is clean, approachable, and has a loyal community — but it is not a realistic choice for most ASP.NET Core teams. There is no first-party Visual Studio template for Vue + ASP.NET Core, the .NET community around Vue is very small, and enterprise-grade UI libraries (especially the ones .NET shops actually use — Kendo, Syncfusion, DevExpress, PrimeNG-equivalents) have weaker Vue support than they do for Angular or React. If you are hiring .NET developers who also need to pick up a frontend, the talent pool and learning resources skew heavily toward Angular and React. That is why we are leaving Vue out of this comparison.

In this guide, we will compare Angular and React side by side, specifically through the lens of a .NET developer who needs to pick a frontend for an ASP.NET Core backend. We will look at architecture, TypeScript, learning curve, performance, ecosystem, AI and agentic coding support, enterprise fit, and integration. No marketing fluff — just the tradeoffs that actually matter when you are staring at an empty git init on Monday morning.

The Short Answer
Architecture: Opinionated vs Library
TypeScript: Mandatory vs Optional
Learning Curve
Performance and Bundle Size
Ecosystem and Community
AI and Agentic Coding
Enterprise Fit
Integration with ASP.NET Core
The Decision Matrix
Bonus: Where Does Blazor Fit?
Frequently Asked Questions
Conclusion

The Short Answer

Before we go deep, here is the one-paragraph version for the busy reader.

Pick Angular if you have a large team, complex forms, strict coding standards, or you want a "batteries included" framework that makes architectural decisions for you. Pick React if you want flexibility, a smaller initial API surface, or you already have frontend engineers who prefer composing their own stack. Pick both if you are building a product platform and want to offer your customers a choice — this is exactly what ASP.NET Zero does out of the box.

Now let's unpack why.

Architecture: Opinionated vs Library

The most important difference between Angular and React is not syntax. It is philosophy.

Angular is an opinionated framework. It ships with a router, an HTTP client, a forms library, a dependency injection container, a testing framework, a CLI, and a build pipeline. When you run ng new, you get a complete, working application structure that every Angular developer in the world will recognize. There is one right way to do most things, and that way is documented.

React is a library. It ships with components and a renderer. Everything else — routing, state management, data fetching, forms, testing — is something you choose and assemble yourself. When you run npm create vite@latest -- --template react-ts, you get React, a build tool, and nothing else. You will add React Router (or TanStack Router), Zustand (or Redux, or Jotai), React Query (or SWR), React Hook Form (or Formik), and a dozen other decisions before your first feature ships.

For a .NET developer, the cleanest analogy is this:

Angular is ASP.NET Core with WebApplication.CreateBuilder() — you get DI, routing, configuration, logging, and middleware in one curated box.
React is writing an HTTP server from System.Net.HttpListener — maximum flexibility, maximum assembly required.

Neither is objectively better. They optimize for different things.

Note: "Opinionated" is not a bad thing. Strong opinions make it easier for a team of 50 engineers to write consistent code, onboard new hires, and avoid endless bikeshedding about folder structure. But strong opinions can also feel like a straitjacket when your problem doesn't fit the mold.

TypeScript: Mandatory vs Optional

If you are coming from C#, this one matters more than you might think.

Angular is written in TypeScript and requires TypeScript in your application code. Every ng new project starts with strict TypeScript configured, and all Angular features — components, services, decorators, dependency injection — are deeply integrated with TypeScript's type system. There is no "plain JavaScript Angular" escape hatch.

React is framework-agnostic about TypeScript. You can write React in JavaScript, TypeScript, or anything that compiles to JavaScript. The React team supports TypeScript as a first-class citizen, but it is not enforced. This means you will see React codebases with inconsistent typing conventions, partial any sprinkled throughout, and third-party libraries that ship with questionable type definitions.

For a team coming from C#, TypeScript is a superpower. It gives you the same kind of compile-time safety, refactoring confidence, and IDE tooling that you already rely on in Rider or Visual Studio. Angular makes that safety non-negotiable. React leaves the discipline to you.

Here is a small taste of how natural TypeScript feels to a .NET developer:

interface Customer {
  id: number;
  name: string;
  email: string;
  isActive: boolean;
}

class CustomerService {
  private apiUrl = '/api/customers';

  async getCustomer(id: number): Promise<Customer> {
    const response = await fetch(`${this.apiUrl}/${id}`);
    return response.json();
  }
}

If you squint, this is C# with different keywords. Both frameworks let you write code like this — Angular just requires it.

Learning Curve

This is where the two frameworks diverge most visibly for newcomers.

React has a gentler initial slope. You can learn the fundamentals of React — components, props, state, and hooks — in a weekend. Your first working app will probably take an afternoon. The API surface is small: there are only a handful of built-in hooks (useState, useEffect, useContext, useMemo, useCallback, useRef) and everything else is composition.

Angular has a steeper initial slope. Before you ship your first real feature, you will need to understand modules (or standalone components), components, services, dependency injection, RxJS observables, the CLI, Angular's change detection, and its forms library (Reactive or Template-driven). That is a lot of concepts to absorb at once.

But here is the twist: React's learning curve flattens early, then gets steep again once your app grows. That's when you hit the "ecosystem wall": choosing a router, choosing a state manager, deciding how to fetch data, structuring folders, handling authentication, setting up forms. Every one of these is a separate library with its own docs, its own conventions, and its own opinions. Experienced React teams spend significant time making and defending these architectural choices.

Angular's learning curve is high upfront, then flattens. Once you understand the framework, scaling it to a 500-component application does not require new mental models. The module system, DI, and CLI scaffolding carry you through.

Which matters more for your team?

If your team will hire frequently or rotate engineers across projects, Angular's shallower long-term curve is an asset — Angular code looks the same everywhere.
If your team is small, stable, and experienced, React's upfront simplicity lets you move fast and encode your own conventions.

Performance and Bundle Size

Let's get to the numbers. We built the same simple CRUD app (a product catalog with 5 screens, forms, and API calls to the same ASP.NET Core backend) in both Angular 21 and React 19. Here is what we measured:

Metric	Angular 21	React 19 (Vite)
Initial bundle (gzipped)	~180 KB	~65 KB
Time to Interactive (3G throttled)	~2.1s	~1.3s
Lighthouse Performance score	91	97
Runtime memory (10k rows rendered)	~42 MB	~38 MB
Dev-mode rebuild time	~1.2s	~0.3s

What this tells us:

React ships less code. For the same feature set, a React + Vite app is meaningfully smaller than an Angular app. If initial load time is critical (public-facing marketing pages, mobile users on slow networks), this matters.
Angular's gap narrows at scale. As your app grows past 50+ components, Angular's tree-shaking and lazy-loaded routes close much of the bundle-size gap. A 50-component React app and a 50-component Angular app are not 3x apart anymore.
Runtime performance is comparable. Both frameworks are fast. Once your app is rendered, users will not feel a difference. Where they will feel a difference is in scenarios involving heavy re-renders — and both frameworks have mature tools to solve that (Angular's OnPush change detection, React's memo and concurrent rendering).
Developer experience favors Vite. Vite's HMR is simply faster than the Angular CLI's dev server. This is not a framework limitation — it's a build tool difference. Angular is moving toward esbuild and Vite-based builds, so expect this gap to shrink.

Note: Benchmarks are situational. Your mileage will vary based on how you structure your code, which libraries you add, and how aggressively you apply lazy loading and code splitting. Treat these numbers as a rough calibration, not gospel.

Ecosystem and Community

Both frameworks have enormous communities. The differences are structural, not quantitative.

React's ecosystem is wide and shallow. There are typically 3-5 popular options for every problem (state management, routing, forms, data fetching), and those options change every 2-3 years. React apps from 2021 often look very different from React apps in 2026 — not because React changed much, but because the surrounding stack did. This is great for innovation; it's less great for long-term maintenance.

Angular's ecosystem is narrow and deep. The Angular team ships first-party solutions for most problems — @angular/router, @angular/forms, @angular/common/http — and third-party libraries tend to integrate with those rather than replace them. Angular code from 2020 is still recognizable in 2026. The tradeoff is less choice and less churn.

A few data points worth considering:

npm downloads: React has significantly more weekly downloads, but a lot of that is React Native, Next.js, and library-wrapping usage — not apples to apples.
GitHub activity: Both repos are extremely active, with regular releases and healthy issue engagement.
Stack Overflow: React questions outnumber Angular questions, but Angular questions tend to get more detailed answers (because there is "one way").
Job market: Both frameworks are in high demand globally. React has a slight edge in startups and product companies; Angular leads in enterprise, banking, healthcare, and government sectors.

For a .NET shop building an enterprise product, the Angular ecosystem's stability is usually a better fit. The last thing you want is to rewrite your state management layer every three years.

AI and Agentic Coding

This is the section that did not exist in 2023 but has become impossible to ignore in 2026. If your team uses Copilot, Claude Code, Cursor, or any other AI coding assistant — and honestly, who isn't? — your framework choice now interacts directly with how productive those tools are in your codebase.

AI assistants know React better than Angular. This is not a value judgment; it is a consequence of training data. There is simply more React code on GitHub, more React tutorials, more React Stack Overflow answers, and more React examples in public documentation than there are for Angular. When an AI model predicts the next line of code, it predicts from the distribution it learned — and that distribution leans heavily React.

In practice, this shows up in a few concrete ways:

First-shot accuracy is higher in React. Ask an AI agent to "add a paginated, searchable table with server-side sorting" in a React + Vite project, and you will usually get working code on the first attempt. Ask the same question in an Angular project, and the agent is more likely to mix patterns (old NgModule syntax with standalone components, @Input() decorators with signal inputs, or deprecated RxJS operators).
Angular churns faster than training data refreshes. Angular has shipped significant API changes in the last two years — standalone components, signals, the new @if/@for control flow, typed reactive forms, signal inputs, inject() over constructor injection. AI models trained even 6 months ago can still produce outdated patterns. React's core API (hooks, JSX, components) has been relatively stable since 2019, so AI suggestions age better.
React's flexibility becomes an AI advantage. Because React apps compose from small, well-known libraries (React Router, TanStack Query, Zustand, Zod, React Hook Form), AI agents can recognize and integrate them quickly. Angular's "one framework, one way" is great for humans, but it means the AI has fewer familiar building blocks to reach for.

But Angular has a few counterweights worth naming:

Strict TypeScript catches AI mistakes faster. When an AI agent hallucinates a property or wires up a service incorrectly, Angular's strict compiler screams immediately. React without TypeScript can let those errors slip through to runtime.
Structured projects are easier to navigate. Angular's opinionated folder structure and DI container give an agent clear places to look for services, guards, and interceptors. Agentic workflows that read a project before editing it benefit from predictable structure.
The gap is narrowing. Anthropic, Google, and Microsoft are all updating their models with fresher code. Expect the Angular-vs-React knowledge gap to shrink with each model release, though it will not disappear entirely — the training-data distribution is skewed, and the skew is structural.

What this means for your team:

If you are a small team leaning heavily on AI to ship fast, React + Vite + TypeScript gives you the highest raw velocity today. Agents write more of the code correctly on the first try, and rework costs are lower.
If you are a larger team that values structure and correctness over raw speed, Angular still wins — AI mistakes are caught earlier, and the framework's guardrails prevent agents from introducing ad-hoc patterns that would fragment your codebase over time.
If you adopt either framework in 2026, pair your AI tooling with CLAUDE.md / AGENTS.md files that encode your framework version, preferred patterns, and "don't use the old API" rules. This closes most of the AI knowledge gap regardless of which framework you pick.

Honest take: if agentic coding is central to how your team works and you have no strong opinion otherwise, this is a real tiebreaker in favor of React in 2026. In 2027 it may not be.

Enterprise Fit

This is where the two frameworks really start to separate for our target reader — a .NET developer building a business-critical application.

Forms

Angular's Reactive Forms are arguably the best form library in any framework. Typed forms, declarative validation, dynamic form generation, cross-field validation, async validators — it is all built-in and it all works together. For enterprise applications where forms are 60% of the UI, this is a massive productivity win.

React's forms are a pick-your-own-adventure. React Hook Form is the current leader, with Zod or Yup for validation, but you are assembling a stack. It works well once you settle on a pattern, but the first team member who joins will need to learn your conventions.

State Management

Angular uses services + RxJS observables as the default state pattern. For async state (API calls, websockets, user events), RxJS is a superpower — but it has a learning curve of its own. For simpler state, Angular Signals (introduced in recent versions) give you a lightweight, reactive primitive that feels closer to React's useState.

React uses hooks + a state library of your choice. useState and useReducer cover simple cases. For global state, Zustand is lightweight and pragmatic; Redux Toolkit is heavier but widely known; Jotai and Recoil cover atomic patterns. For server state, TanStack Query is essentially mandatory.

Testing

Both frameworks have excellent testing stories. Angular's TestBed + Jasmine + Karma is the default; many teams have moved to Jest or Vitest. React uses Vitest + React Testing Library, which is very ergonomic. End-to-end testing (Playwright, Cypress) is framework-agnostic and works identically for both.

CI/CD and DevOps

Both produce static assets that can be served from any static host, embedded in an ASP.NET Core wwwroot, or deployed to CDNs. No meaningful difference here.

Team Scaling

This is where Angular's opinionated nature pays off. A team of 10 Angular developers will write code that looks the same. A team of 10 React developers will write 10 flavors of React unless you invest heavily in shared conventions and ESLint rules. If your org is growing fast, Angular reduces the coordination overhead.

Integration with ASP.NET Core

Both frameworks integrate cleanly with ASP.NET Core, and the mechanics are nearly identical:

Visual Studio templates: Visual Studio 2026 ships with first-party templates for both "ASP.NET Core with Angular" and "ASP.NET Core with React (Vite)". Both give you a pre-wired project with proxy configuration, launch profiles, and HTTPS.
SPA middleware: ASP.NET Core's SPA middleware can host both Angular and React dev servers during development. In production, both frameworks produce static dist folders that sit in wwwroot or are served via a CDN.
Authentication: JWT-based authentication with ASP.NET Core Identity works identically for both. Interceptors (Angular's HttpInterceptor, React's Axios or fetch wrappers) handle token injection the same way.
CORS and proxying: Both dev servers support proxying to the ASP.NET Core backend. Angular uses proxy.conf.json; Vite uses vite.config.ts. Same concept, slightly different syntax.

If you have already read our previous guides:

You will notice the setup steps are structurally identical: create the frontend, create the Web API, configure CORS, set up the proxy, make the first call. The frameworks differ on the frontend side; the .NET side is unchanged.

This is actually a big deal. It means the cost of switching frontend frameworks later — or supporting both simultaneously — is bounded. Your API layer, your database, your domain model, your authentication, your business rules: all of that is reusable. Only the frontend changes.

The Decision Matrix

Here is a practical matrix for choosing between Angular and React based on the shape of your project and team:

Scenario	Recommended
Large enterprise team (20+ engineers) with strict standards	Angular
Heavy forms, complex validation, admin dashboards	Angular
Long-lived product (5+ year horizon) with staff rotation	Angular
Regulated industry (banking, healthcare, government)	Angular
Small team (2-10 engineers), startup velocity	React
Public-facing marketing site or landing pages	React
Mobile-first application with bundle size pressure	React
Team with existing React expertise	React
Team with existing C#/Java background, no JS experience	Angular
Heavy reliance on AI / agentic coding for day-to-day development	React

The "Effortless" Option

If you do not want to design a layered architecture from scratch, or spend weeks on the non-business parts of an ASP.NET Core SPA — authentication, multi-tenancy, role management, audit logging, CRUD boilerplate — skip that work entirely and use ASP.NET Zero with either its Angular or React option.

You still make the Angular vs React call based on everything above. You just do not reinvent the backend and infrastructure to get there.

Bonus: Where Does Blazor Fit?

We cannot finish this article without mentioning Blazor — the .NET-native frontend option that keeps surprising people with how good it has gotten.

Pick Blazor when:

Your team is 100% .NET and adding JavaScript/TypeScript is a real cost.
You are building internal admin tools where bundle size matters less.
You want maximum code sharing between frontend and backend (DTOs, validation, domain logic).
You are on .NET 10 and can use Blazor United (Server + WASM + Hybrid in one model).

Don't pick Blazor when:

You need the richest possible component ecosystem (Angular and React still win here).
You are building a public-facing app where every KB matters (Blazor WASM has a larger runtime baseline).
Your team needs to hire frontend specialists (the Blazor talent pool is smaller).

Frequently Asked Questions

Is Angular dead in 2026?

No. Angular v21 brought standalone components, typed reactive forms, deferrable views, signals, and a faster build pipeline. The framework is evolving actively and is used by Google, Microsoft (in Teams and parts of Azure Portal), Deutsche Bank, Forbes, and thousands of enterprises. It is as alive as React.

Is React really faster than Angular?

For initial load on small apps, yes. For runtime performance on large apps, the difference is negligible. Bundle size is where React's advantage is most visible, but Angular's lazy loading and tree-shaking narrow the gap for real-world applications.

Which is better for an ASP.NET Core backend?

Technically, neither. Both integrate via HTTP/JSON, both have Visual Studio templates, both work with JWT or cookie auth, and both can be deployed alongside ASP.NET Core. The backend does not care. Pick based on your team and product, not on the backend.

Can I switch from React to Angular (or vice versa) later?

Yes, and your ASP.NET Core backend stays the same. You will rewrite the frontend, which is real work, but your APIs, domain logic, authentication, and data layer carry over. This is a major advantage of using a clean API boundary. See our migration guides (coming in Phase 3 of our content plan) for concrete playbooks.

What if my team doesn't know either?

For a team with strong C#/Java background and no JS experience, start with Angular. TypeScript feels familiar, the opinionated structure reduces decision fatigue, and the patterns (DI, services, modules) map cleanly to backend concepts. For a team with some JavaScript experience, React is often faster to start.

Does ASP.NET Zero support both?

Yes. ASP.NET Zero ships an Angular UI, a React UI (since v15.1, with RAD tooling for code generation since v15.2), and an MVC UI. The same license gives you access to all three, so you can pick later or maintain both.

Conclusion

If you are choosing between Angular and React for your next ASP.NET Core project, the honest answer is: both are great, and the decision is less about the frameworks and more about your team, your product, and your time horizon.

Pick Angular for structure, stability, and long-term maintainability in enterprise settings.
Pick React for flexibility, smaller bundles, and startup-grade velocity.
Pick both — via ASP.NET Zero — if you are building a product platform and want to hand the choice to your customers.

Whatever you pick, the hard part is not the frontend framework. The hard part is building authentication, multi-tenancy, role management, audit logging, and the dozens of infrastructure pieces that every enterprise application needs. That is where you should be spending your engineering budget — not on CRUD forms and login pages.

Ready to skip the infrastructure work? Consider ASP.NET Zero and get a production-ready Angular or React frontend, wired up to a full-featured ASP.NET Core backend with authentication, multi-tenancy, and Power Tools for code generation. You can change your mind about the frontend later — your backend will be ready either way.

React + ASP.NET Core: Enterprise Project Getting Started Guide

ismail Cagdas — Tue, 07 Apr 2026 06:08:01 +0000

If you are building a modern enterprise web application in 2026, React with ASP.NET Core is one of the most practical stacks you can choose. React gives you a flexible component model, excellent ecosystem support, and strong performance with a Vite-based workflow. ASP.NET Core gives you a high-performance backend, robust security primitives, and a mature architecture for APIs.

In this guide, we will walk through three different ways to start a React + ASP.NET Core project:

Manual setup with Vite + ASP.NET Core Web API
Visual Studio template setup
ASP.NET Zero React UI setup for enterprise-grade applications

By the end, you will know which approach is best for your team and timeline.

Prerequisites
Approach 1 - Manual Setup
- Step 1: Create the React App with Vite
- Step 2: Create the ASP.NET Core Web API
- Step 3: Configure CORS
- Step 4: Configure the Vite Proxy
- Step 5: Make the First API Call from React
Approach 2 - Visual Studio Template
Approach 3 - ASP.NET Zero React UI
Comparison
Common Issues and Solutions
Next Steps

Prerequisites

Before we start, install and verify the following tools:

Node.js 24.x or later - download here
Vite (installed per project, no global install required)
.NET 10 SDK - download here
Visual Studio 2026 or VS Code
Optional but recommended: pnpm or yarn for faster dependency management

Run these commands to verify your environment:

node --version
npm --version
dotnet --version

You should see Node.js 24+, npm 11+, and .NET 10.x.

Approach 1 - Manual Setup

This approach gives you full control and helps you understand each moving part. It is ideal when you want to shape your own architecture from day one.

Step 1: Create the React App with Vite

Open a terminal and run:

npm create vite@latest myapp.client -- --template react-ts
cd myapp.client
npm install
npm run dev

Open http://localhost:5173. You should see the Vite + React starter page.

We use the react-ts template because TypeScript is a better default for enterprise codebases. It improves refactoring safety and makes large teams more productive.

Step 2: Create the ASP.NET Core Web API

Open a second terminal in the parent folder:

dotnet new webapi -n MyApp.Api --use-controllers
cd MyApp.Api
dotnet run

The API starts on a port shown in terminal output, usually like http://localhost:52xx and https://localhost:72xx.

The default WeatherForecastController is enough for the first integration test. Open this URL in your browser to verify the API:

http://localhost:{port}/WeatherForecast

If you can see JSON data, backend setup is ready.

Step 3: Configure CORS

React and ASP.NET Core run on different origins in development. The browser blocks cross-origin calls unless we explicitly allow them.

Open Program.cs in the API project and update it like this:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();
builder.Services.AddOpenApi();

builder.Services.AddCors(options =>
{
    options.AddPolicy("ReactDev", policy =>
    {
        policy.WithOrigins("http://localhost:5173")
              .AllowAnyHeader()
              .AllowAnyMethod();
    });
});

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.MapOpenApi();
}

app.UseHttpsRedirection();
app.UseCors("ReactDev");
app.UseAuthorization();
app.MapControllers();
app.Run();

Note: Keep this policy strict in production. Only allow your real frontend domain.

Step 4: Configure the Vite Proxy

CORS works, but during development a proxy is cleaner. Your frontend calls /api/*, and Vite forwards those requests to ASP.NET Core.

Open vite.config.ts in your React project and add proxy settings:

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [react()],
  server: {
    proxy: {
      '/WeatherForecast': {
        target: 'http://localhost:5266',
        changeOrigin: true,
        secure: false,
      },
    },
  },
})

Replace 5266 with your actual API HTTP port.

Restart Vite after this change:

npm run dev

Step 5: Make the First API Call from React

Now let us fetch data from ASP.NET Core and render it in React.

Update src/App.tsx:

import { useEffect, useState } from 'react'
import './App.css'

type WeatherForecast = {
  date: string
  temperatureC: number
  temperatureF: number
  summary: string
}

function App() {
  const [forecasts, setForecasts] = useState<WeatherForecast[]>([])
  const [loading, setLoading] = useState(true)
  const [error, setError] = useState<string | null>(null)

  useEffect(() => {
    fetch('/WeatherForecast')
      .then(async response => {
        if (!response.ok) {
          throw new Error(`Request failed: ${response.status}`)
        }
        const data = (await response.json()) as WeatherForecast[]
        setForecasts(data)
      })
      .catch(err => setError(err.message))
      .finally(() => setLoading(false))
  }, [])

  if (loading) {
    return <p>Loading weather data...</p>
  }

  if (error) {
    return <p>Error: {error}</p>
  }

  return (
    <main style={{ padding: 24 }}>
      <h1>Weather Forecast</h1>
      <table>
        <thead>
          <tr>
            <th>Date</th>
            <th>Temp (C)</th>
            <th>Temp (F)</th>
            <th>Summary</th>
          </tr>
        </thead>
        <tbody>
          {forecasts.map(item => (
            <tr key={item.date}>
              <td>{item.date}</td>
              <td>{item.temperatureC}</td>
              <td>{item.temperatureF}</td>
              <td>{item.summary}</td>
            </tr>
          ))}
        </tbody>
      </table>
    </main>
  )
}

export default App

Save the file and refresh the page. If everything is configured correctly, your React app will display forecast data from ASP.NET Core.

At this point, your baseline architecture is ready.

Approach 2 - Visual Studio Template

If you prefer a faster start with less manual setup, use the built-in template from Visual Studio.

Open Visual Studio 2026.
Select Create a new project.
Search for ASP.NET Core with React.
Choose .NET 10 as target framework.
Create and run the project.

The template gives you:

A ready ASP.NET Core backend
A React frontend project integrated into the solution
Launch profiles for local debugging
Basic dev-time wiring between frontend and backend

This is a good option for PoCs and small-to-medium internal apps.

What is still missing for most enterprise projects:

End-to-end authentication and authorization flows
Multi-tenancy
Role/permission management UI
Audit logging and operational tooling
Accelerated CRUD scaffolding

You can build all of these, but it takes significant time.

Approach 3 - ASP.NET Zero React UI

If your goal is to ship an enterprise product quickly, this is the highest-leverage option.

ASP.NET Zero provides a production-ready architecture with official React UI support (available since v15.1) and RAD capabilities in v15.2.

Quick Start

Go to aspnetzero.com and get your package.
Select the React option while downloading.
Open the solution.
Update connection strings in appsettings.json.
Run the migrator project.
Start the backend host.
Start the React UI project.

Example run flow:

cd src/MyCompanyName.AbpZeroTemplate.Migrator
dotnet run

cd ../MyCompanyName.AbpZeroTemplate.Web.Host
dotnet run

cd ../../react
npm install
npm run dev

Then open your local React URL and sign in with seeded admin credentials.

For detailed environment-specific setup, follow the official docs:

React getting started docs: docs.aspnetzero.com

Why This Matters for Enterprise Teams

With ASP.NET Zero React UI, you start with critical features already built:

Authentication and authorization
Role and permission management
Tenant management and subscriptions
Audit logs and notifications
Production-ready UI infrastructure
Battle-tested architecture conventions

v15.2 RAD Advantage

The v15.2 RAD (Rapid Application Development) flow significantly reduces repetitive coding.

You define an entity once, and tooling generates:

Backend entity and migration
DTOs and application service methods
API endpoints
React list/create/edit pages
Boilerplate integration code

This means your team spends time on business logic, not repeated scaffolding.

Comparison

Here is a practical side-by-side comparison:

Criteria	Manual Setup	VS Template	ASP.NET Zero React UI
Setup speed	Medium	Fast	Fast
Architecture control	Full	High	Full (source included)
Learning value	Very high	Medium	High
Built-in auth	No	No	Yes
Multi-tenancy	No	No	Yes
Role/permission UI	No	No	Yes
Production-ready admin UI	No	Basic	Yes (Metronic-based)
CRUD acceleration	No	No	Yes (RAD/Power Tools)
Best for	Custom frameworks, education	Prototypes	Enterprise delivery

Bottom line:

Choose manual setup when you want complete transparency and control.
Choose VS template when you need a quick, clean starting point.
Choose ASP.NET Zero React UI when delivery speed and enterprise features are top priority.

Common Issues and Solutions

Vite Proxy Returns 404

Symptom: Calls to /WeatherForecast return 404.

Why it happens: Proxy path does not match backend route or API port is wrong.

Fix:

Verify backend route in your controller.
Verify the target port in vite.config.ts.
Restart Vite after config changes.

HMR Not Refreshing Correctly

Symptom: UI changes are not reflected immediately.

Why it happens: Stale dev server state or package mismatch.

Fix:

rm -rf node_modules package-lock.json
npm install
npm run dev

If you are on Windows PowerShell, use:

Remove-Item node_modules -Recurse -Force
Remove-Item package-lock.json -Force
npm install
npm run dev

CORS Error in Browser Console

Symptom: blocked by CORS policy.

Why it happens: Missing or incorrect CORS policy in ASP.NET Core.

Fix: Ensure you registered and applied the policy in correct order:

app.UseHttpsRedirection();
app.UseCors("ReactDev");
app.UseAuthorization();

Authentication Integration Complexity

Symptom: Login appears to work, but protected API calls fail.

Why it happens: Missing token forwarding or inconsistent token storage strategy.

Fix:

Centralize API calls with a single HTTP client layer.
Add request interceptors to attach bearer tokens.
Implement refresh token handling early.

If you want this fully prebuilt, ASP.NET Zero already includes this flow.

Next Steps

Now your React + ASP.NET Core baseline is ready. Continue with one of these paths:

Add JWT authentication and protected routes.
Add CRUD modules with server-side validation and pagination.
Introduce role-based authorization and admin screens.
Evaluate ASP.NET Zero React UI if you want to skip infrastructure coding.

Useful links:

ASP.NET Core docs: learn.microsoft.com
ASP.NET Zero React docs: docs.aspnetzero.com
ASP.NET Zero React page: aspnetzero.com/react

Building enterprise software is not only about choosing a frontend library. It is about reducing risk, increasing delivery speed, and keeping architecture maintainable as the product grows. React + ASP.NET Core is an excellent foundation, and with the right starting point, your team can move much faster.

Angular + ASP.NET Core: Enterprise Project Getting Started Guide (2026)

ismail Cagdas — Tue, 07 Apr 2026 06:07:32 +0000

If you are building an enterprise web application in 2026, the combination of Angular and ASP.NET Core is one of the strongest choices you can make. Angular gives you TypeScript safety, a powerful component architecture, and a mature ecosystem. ASP.NET Core gives you a high-performance, cross-platform backend with first-class dependency injection and a rich middleware pipeline.

In this post, we will walk through three different ways to start an Angular + ASP.NET Core project — from a fully manual setup to a one-click enterprise starter. By the end, you will have a clear understanding of which approach fits your project best.

Prerequisites
Approach 1 — Manual Setup
- Step 1: Create the Angular App
- Step 2: Create the ASP.NET Core Web API
- Step 3: Configure CORS
- Step 4: Set Up the Angular Proxy
- Step 5: Make the First API Call
Approach 2 — Visual Studio Template
Approach 3 — ASP.NET Zero
Comparison
Common Issues and Solutions
Next Steps

Prerequisites

Before we start, make sure you have the following tools installed:

Node.js 24.x or later — download here
Angular CLI 21.x — install with npm install -g @angular/cli
.NET 10 SDK — download here
Visual Studio 2026 (Latest stable version) or VS Code with the C# Dev Kit extension
A terminal you are comfortable with (PowerShell, bash, or the VS Code integrated terminal)

You can verify your setup by running:

node --version    # v24.x (use latest stable)
ng version        # Angular CLI 21.x
dotnet --version  # 10.x

Approach 1 — Manual Setup

This approach gives you full control over every detail. It is the best choice if you want to understand how the pieces fit together or if you have specific architectural requirements.

Step 1: Create the Angular App

Open a terminal and run:

ng new MyApp.Client --style=scss --routing=true --ssr=false
cd MyApp.Client
ng serve

Navigate to http://localhost:4200 — you should see the default Angular welcome page.

Step 2: Create the ASP.NET Core Web API

Open a new terminal in the parent directory and create the API project:

dotnet new webapi -n MyApp.Api --use-controllers
cd MyApp.Api

Let's add a simple endpoint to test the connection. Open Controllers/WeatherForecastController.cs — the template already includes a GET /WeatherForecast endpoint that returns random forecast data. We will use this for our first integration test.

Run the API:

dotnet run

The API will start on a port shown in the terminal output (e.g. http://localhost:5266). You can verify it by navigating to http://localhost:{port}/WeatherForecast in your browser. Take note of this port — you will need it for the proxy configuration in Step 4.

Step 3: Configure CORS

By default, your Angular app on localhost:4200 cannot call the API on localhost:5001 because of the browser's same-origin policy. We need to enable CORS on the API side.

Open Program.cs and add the following:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();
builder.Services.AddOpenApi();

// Add CORS policy
builder.Services.AddCors(options =>
{
    options.AddPolicy("Angular", policy =>
    {
        policy.WithOrigins("http://localhost:4200")
              .AllowAnyHeader()
              .AllowAnyMethod();
    });
});

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.MapOpenApi();
}

app.UseHttpsRedirection();

// Use the CORS policy
app.UseCors("Angular");

app.UseAuthorization();
app.MapControllers();
app.Run();

Note: This CORS configuration is for development only. In production, you should restrict the allowed origins to your actual domain.

Step 4: Set Up the Angular Proxy

While CORS works, a cleaner approach during development is to use Angular's built-in proxy. This way, the Angular dev server forwards API requests to the backend, and you avoid CORS entirely.

Create a file called proxy.conf.json in the root of your Angular project:

{
  "/WeatherForecast": {
    "target": "http://localhost:5266",
    "secure": false,
    "changeOrigin": true
  }
}

Note: Replace 5266 with the actual port your API is running on. You can find it in the terminal output when you run dotnet run — look for the line that says Now listening on: http://localhost:XXXX. Also, we are proxying the /WeatherForecast path directly because the default .NET template does not use an /api prefix. In a real project, you would typically add a common prefix like /api to all your controllers (using [Route("api/[controller]")]) and proxy that single prefix instead.

Update angular.json to use the proxy. Find the serve section and add the proxyConfig option:

"serve": {
  "options": {
    "proxyConfig": "proxy.conf.json"
  }
}

Now restart the Angular dev server with ng serve. Any request to /WeatherForecast from your Angular app will be forwarded to the .NET backend.

Step 5: Make the First API Call

Let's update the root component to fetch weather data from the API. First, we need to configure HttpClient. Open src/app/app.config.ts and add provideHttpClient():

import { ApplicationConfig } from '@angular/core';
import { provideRouter } from '@angular/router';
import { provideHttpClient } from '@angular/common/http';

import { routes } from './app.routes';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes),
    provideHttpClient()
  ]
};

Now open src/app/app.ts and update it:

import { Component, inject, OnInit, signal } from '@angular/core';
import { HttpClient } from '@angular/common/http';

interface WeatherForecast {
  date: string;
  temperatureC: number;
  temperatureF: number;
  summary: string;
}

@Component({
  selector: 'app-root',
  templateUrl: './app.html',
  styleUrl: './app.scss'
})
export class App implements OnInit {
  private http = inject(HttpClient);
  forecasts = signal<WeatherForecast[]>([]);

  ngOnInit() {
    this.http.get<WeatherForecast[]>('/WeatherForecast')
      .subscribe(data => this.forecasts.set(data));
  }
}

Then update src/app/app.html with the template:

<h1>Weather Forecast</h1>
@if (forecasts().length > 0) {
  <table>
    <thead>
      <tr>
        <th>Date</th>
        <th>Temp (C)</th>
        <th>Temp (F)</th>
        <th>Summary</th>
      </tr>
    </thead>
    <tbody>
      @for (f of forecasts(); track f.date) {
        <tr>
          <td>{{ f.date }}</td>
          <td>{{ f.temperatureC }}</td>
          <td>{{ f.temperatureF }}</td>
          <td>{{ f.summary }}</td>
        </tr>
      }
    </tbody>
  </table>
}

Save the file and check your browser. You should see the weather data rendered in a table. Your Angular frontend is now talking to your ASP.NET Core backend.

Approach 2 — Visual Studio Template

If you prefer a faster start with less manual configuration, Visual Studio 2022 ships with a built-in Angular + ASP.NET Core project template.

Open Visual Studio 2026 and select Create a new project.
Search for "ASP.NET Core with Angular" and select the template.
Configure the project name, location, and solution name.
On the next screen, select .NET 10 as the target framework.
Click Create.

Visual Studio generates a solution with two projects:

An ASP.NET Core backend with a sample WeatherForecast API.
An Angular frontend with proxy configuration already wired up.

Press F5 to run the project. Both the backend and the frontend will start together, and you will see a working Angular app fetching data from the API.

What you get out of the box:

Pre-configured proxy (proxy.conf.js)
HTTPS development certificate setup
Integrated launch profiles for debugging both projects simultaneously

What you don't get:

Authentication / authorization
Multi-tenancy
Role management
A production-ready UI framework

This template is a great starting point for prototypes or simple applications. For enterprise projects, you will need to add these features yourself — or use a framework that includes them. But, be aware that this option may have problems time to time because some pf the NPM packages intorduce breaking changes and it takes time for maintainer team to release a working version.

Approach 3 — ASP.NET Zero

ASP.NET Zero is a production-ready starter kit built on ASP.NET Core that supports Angular, React, and MVC (Razor) as frontend options. It is designed specifically for enterprise applications and includes dozens of features out of the box.

Here is how to get started:

Go to aspnetzero.com and sign up for a license.
Navigate to the Download page, select Angular as your frontend, and download the project.
Open the solution in Visual Studio or VS Code.
Update the database connection string in appsettings.json.
Run the migrator project to create and seed the database:

cd src/MyProject.Migrator
dotnet run

Start the backend:

cd src/MyProject.Web.Host
dotnet run

Start the Angular frontend:

cd angular
yarn 
yarn create-dynamic-bundles
yarn start

Navigate to http://localhost:4200 and log in with the default admin credentials. You will see a fully working enterprise application.

To run the project propertly, you can follow Angular Getting Started Document.

What you get out of the box:

Authentication & Authorization: Login, registration, two-factor authentication, social logins, LDAP/Active Directory integration — all pre-built and configurable.
Multi-Tenancy: Host/tenant architecture with separate databases or shared database options. Tenant registration, subscription management, and edition management are built in.
Role & Permission Management: A granular permission system with role-based and user-based authorization.
Organization Units: Hierarchical organizational structure with the ability to assign users and roles per unit.
Audit Logging: Every action is logged with user, timestamp, and change details.
Real-Time Notifications: Built-in notification system with SignalR integration.
UI Theme: A polished admin theme based on Metronic with responsive design, dark mode, and multiple layout options.
Power Tools: A Visual Studio extension and a CLI tool that generates entities, DTOs, application services, API controllers, Angular components, and unit tests from a simple entity definition. Instead of writing CRUD code manually, you describe your entity and Power Tools generates everything.

Let's see Power Tools in action. Say you want to add a Product entity to your application. You define the entity fields (Name, Price, Category, etc.) in Power Tools, click Generate, and it creates:

The Product entity and database migration
ProductAppService with full CRUD operations
ProductDto and CreateProductDto classes
Angular components for listing, creating, and editing products
Unit tests for the app service
UI tests for your Angular pages

What would take hours of boilerplate coding is done in under a minute.

Comparison

Here is how the three approaches compare:

Feature	Manual Setup	VS Template	ASP.NET Zero
Setup time	30-60 min	5 min	10 min
Authentication	You build it	You build it	Built-in
Authorization / Roles	You build it	You build it	Built-in
Multi-tenancy	You build it	You build it	Built-in
Organization units	You build it	You build it	Built-in
Audit logging	You build it	You build it	Built-in
UI theme	None	Basic	Metronic (production-ready)
Code generation tools	None	None	Power Tools
Real-time notifications	You build it	You build it	Built-in
Learning value	High	Medium	High
Flexibility	Full	Full	Full (source code included)
Cost	Free	Free	Licensed

Bottom line: If you are learning or building a simple prototype, the manual setup or VS template is perfect. If you are building an enterprise application and want to skip months of infrastructure work, ASP.NET Zero gives you a massive head start.

Common Issues and Solutions

CORS Errors

Symptom: The browser console shows Access to XMLHttpRequest has been blocked by CORS policy.

Solution: Make sure your Program.cs includes the CORS middleware and that app.UseCors() is called before app.UseAuthorization(). Also verify that the origin URL matches exactly (including the port number and protocol).

// Correct order
app.UseCors("Angular");
app.UseAuthorization();

Proxy Not Working

Symptom: API calls return 404 or the Angular app tries to serve the request itself.

Solution: Double-check the proxy.conf.json path in angular.json. Make sure the target URL matches the port your API is running on. Restart ng serve after any proxy configuration change — the proxy config is only read at startup.

SSL Certificate Errors

Symptom: ERR_CERT_AUTHORITY_INVALID or proxy shows UNABLE_TO_VERIFY_LEAF_SIGNATURE.

Solution: For development, set "secure": false in your proxy.conf.json. This tells the Angular dev server to accept self-signed certificates. Alternatively, trust the .NET development certificate:

dotnet dev-certs https --trust

Angular CLI Version Mismatch

Symptom: Build errors or unexpected behavior after creating the project.

Solution: Make sure your global Angular CLI version matches the version in the project's package.json. You can check with ng version and update with:

npm install -g @angular/cli@19

Next Steps

Now that your Angular + ASP.NET Core project is up and running, here are some next steps depending on which approach you chose:

Add authentication: If you went with the manual setup or VS template, check out the ASP.NET Core Identity documentation to add login and registration.
Explore ASP.NET Zero: If you are interested in the enterprise approach, contact ASP.NET Zero Team and explore the documentation. The Angular getting started guide will have you running in under 10 minutes.
Try Power Tools: If you are already using ASP.NET Zero, generate your first entity with Power Tools and see how much time it saves.

Building enterprise applications is hard. Choosing the right foundation makes it significantly easier. Whether you start from scratch or stand on the shoulders of a mature framework, Angular and ASP.NET Core together give you a rock-solid stack for 2026 and beyond.

Angular + ASP.NET Core: Enterprise Project Getting Started Guide

ismail Cagdas — Thu, 02 Apr 2026 10:29:43 +0000

Prerequisites
Approach 1 — Manual Setup
- Step 1: Create the Angular App
- Step 2: Create the ASP.NET Core Web API
- Step 3: Configure CORS
- Step 4: Set Up the Angular Proxy
- Step 5: Make the First API Call
Approach 2 — Visual Studio Template
Approach 3 — ASP.NET Zero
Comparison
Common Issues and Solutions
Next Steps

Prerequisites

Before we start, make sure you have the following tools installed:

Node.js 24.x or later — download here
Angular CLI 21.x — install with npm install -g @angular/cli
.NET 10 SDK — download here
Visual Studio 2026 (Latest stable version) or VS Code with the C# Dev Kit extension
A terminal you are comfortable with (PowerShell, bash, or the VS Code integrated terminal)

You can verify your setup by running:

node --version    # v24.x (use latest stable)
ng version        # Angular CLI 21.x
dotnet --version  # 10.x

Approach 1 — Manual Setup

This approach gives you full control over every detail. It is the best choice if you want to understand how the pieces fit together or if you have specific architectural requirements.

Step 1: Create the Angular App

Open a terminal and run:

ng new MyApp.Client --style=scss --routing=true --ssr=false
cd MyApp.Client
ng serve

Navigate to http://localhost:4200 — you should see the default Angular welcome page.

Step 2: Create the ASP.NET Core Web API

Open a new terminal in the parent directory and create the API project:

dotnet new webapi -n MyApp.Api --use-controllers
cd MyApp.Api

Run the API:

dotnet run

Step 3: Configure CORS

By default, your Angular app on localhost:4200 cannot call the API on localhost:5001 because of the browser's same-origin policy. We need to enable CORS on the API side.

Open Program.cs and add the following:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();
builder.Services.AddOpenApi();

// Add CORS policy
builder.Services.AddCors(options =>
{
    options.AddPolicy("Angular", policy =>
    {
        policy.WithOrigins("http://localhost:4200")
              .AllowAnyHeader()
              .AllowAnyMethod();
    });
});

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.MapOpenApi();
}

app.UseHttpsRedirection();

// Use the CORS policy
app.UseCors("Angular");

app.UseAuthorization();
app.MapControllers();
app.Run();

Note: This CORS configuration is for development only. In production, you should restrict the allowed origins to your actual domain.

Step 4: Set Up the Angular Proxy

While CORS works, a cleaner approach during development is to use Angular's built-in proxy. This way, the Angular dev server forwards API requests to the backend, and you avoid CORS entirely.

Create a file called proxy.conf.json in the root of your Angular project:

{
  "/WeatherForecast": {
    "target": "http://localhost:5266",
    "secure": false,
    "changeOrigin": true
  }
}

Update angular.json to use the proxy. Find the serve section and add the proxyConfig option:

"serve": {
  "options": {
    "proxyConfig": "proxy.conf.json"
  }
}

Now restart the Angular dev server with ng serve. Any request to /WeatherForecast from your Angular app will be forwarded to the .NET backend.

Step 5: Make the First API Call

Let's update the root component to fetch weather data from the API. First, we need to configure HttpClient. Open src/app/app.config.ts and add provideHttpClient():

import { ApplicationConfig } from '@angular/core';
import { provideRouter } from '@angular/router';
import { provideHttpClient } from '@angular/common/http';

import { routes } from './app.routes';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes),
    provideHttpClient()
  ]
};

Now open src/app/app.ts and update it:

import { Component, inject, OnInit, signal } from '@angular/core';
import { HttpClient } from '@angular/common/http';

interface WeatherForecast {
  date: string;
  temperatureC: number;
  temperatureF: number;
  summary: string;
}

@Component({
  selector: 'app-root',
  templateUrl: './app.html',
  styleUrl: './app.scss'
})
export class App implements OnInit {
  private http = inject(HttpClient);
  forecasts = signal<WeatherForecast[]>([]);

  ngOnInit() {
    this.http.get<WeatherForecast[]>('/WeatherForecast')
      .subscribe(data => this.forecasts.set(data));
  }
}

Then update src/app/app.html with the template:

<h1>Weather Forecast</h1>
@if (forecasts().length > 0) {
  <table>
    <thead>
      <tr>
        <th>Date</th>
        <th>Temp (C)</th>
        <th>Temp (F)</th>
        <th>Summary</th>
      </tr>
    </thead>
    <tbody>
      @for (f of forecasts(); track f.date) {
        <tr>
          <td>{{ f.date }}</td>
          <td>{{ f.temperatureC }}</td>
          <td>{{ f.temperatureF }}</td>
          <td>{{ f.summary }}</td>
        </tr>
      }
    </tbody>
  </table>
}

Save the file and check your browser. You should see the weather data rendered in a table. Your Angular frontend is now talking to your ASP.NET Core backend.

Approach 2 — Visual Studio Template

If you prefer a faster start with less manual configuration, Visual Studio 2022 ships with a built-in Angular + ASP.NET Core project template.

Open Visual Studio 2026 and select Create a new project.
Search for "ASP.NET Core with Angular" and select the template.
Configure the project name, location, and solution name.
On the next screen, select .NET 10 as the target framework.
Click Create.

Visual Studio generates a solution with two projects:

An ASP.NET Core backend with a sample WeatherForecast API.
An Angular frontend with proxy configuration already wired up.

Press F5 to run the project. Both the backend and the frontend will start together, and you will see a working Angular app fetching data from the API.

What you get out of the box:

Pre-configured proxy (proxy.conf.js)
HTTPS development certificate setup
Integrated launch profiles for debugging both projects simultaneously

What you don't get:

Authentication / authorization
Multi-tenancy
Role management
A production-ready UI framework

Approach 3 — ASP.NET Zero

Here is how to get started:

Go to aspnetzero.com and sign up for a license.
Navigate to the Download page, select Angular as your frontend, and download the project.
Open the solution in Visual Studio or VS Code.
Update the database connection string in appsettings.json.
Run the migrator project to create and seed the database:

cd src/MyProject.Migrator
dotnet run

Start the backend:

cd src/MyProject.Web.Host
dotnet run

Start the Angular frontend:

cd angular
yarn 
yarn create-dynamic-bundles
yarn start

Navigate to http://localhost:4200 and log in with the default admin credentials. You will see a fully working enterprise application.

To run the project propertly, you can follow Angular Getting Started Document.

What you get out of the box:

Authentication & Authorization: Login, registration, two-factor authentication, social logins, LDAP/Active Directory integration — all pre-built and configurable.
Multi-Tenancy: Host/tenant architecture with separate databases or shared database options. Tenant registration, subscription management, and edition management are built in.
Role & Permission Management: A granular permission system with role-based and user-based authorization.
Organization Units: Hierarchical organizational structure with the ability to assign users and roles per unit.
Audit Logging: Every action is logged with user, timestamp, and change details.
Real-Time Notifications: Built-in notification system with SignalR integration.
UI Theme: A polished admin theme based on Metronic with responsive design, dark mode, and multiple layout options.
Power Tools: A Visual Studio extension and a CLI tool that generates entities, DTOs, application services, API controllers, Angular components, and unit tests from a simple entity definition. Instead of writing CRUD code manually, you describe your entity and Power Tools generates everything.

The Product entity and database migration
ProductAppService with full CRUD operations
ProductDto and CreateProductDto classes
Angular components for listing, creating, and editing products
Unit tests for the app service
UI tests for your Angular pages

What would take hours of boilerplate coding is done in under a minute.

Comparison

Here is how the three approaches compare:

Feature	Manual Setup	VS Template	ASP.NET Zero
Setup time	30-60 min	5 min	10 min
Authentication	You build it	You build it	Built-in
Authorization / Roles	You build it	You build it	Built-in
Multi-tenancy	You build it	You build it	Built-in
Organization units	You build it	You build it	Built-in
Audit logging	You build it	You build it	Built-in
UI theme	None	Basic	Metronic (production-ready)
Code generation tools	None	None	Power Tools
Real-time notifications	You build it	You build it	Built-in
Learning value	High	Medium	High
Flexibility	Full	Full	Full (source code included)
Cost	Free	Free	Licensed

Common Issues and Solutions

CORS Errors

Symptom: The browser console shows Access to XMLHttpRequest has been blocked by CORS policy.

// Correct order
app.UseCors("Angular");
app.UseAuthorization();

Proxy Not Working

Symptom: API calls return 404 or the Angular app tries to serve the request itself.

SSL Certificate Errors

Symptom: ERR_CERT_AUTHORITY_INVALID or proxy shows UNABLE_TO_VERIFY_LEAF_SIGNATURE.

dotnet dev-certs https --trust

Angular CLI Version Mismatch

Symptom: Build errors or unexpected behavior after creating the project.

Solution: Make sure your global Angular CLI version matches the version in the project's package.json. You can check with ng version and update with:

npm install -g @angular/cli@19

Next Steps

Now that your Angular + ASP.NET Core project is up and running, here are some next steps depending on which approach you chose:

Add authentication: If you went with the manual setup or VS template, check out the ASP.NET Core Identity documentation to add login and registration.
Explore ASP.NET Zero: If you are interested in the enterprise approach, contact ASP.NET Zero Team and explore the documentation. The Angular getting started guide will have you running in under 10 minutes.
Try Power Tools: If you are already using ASP.NET Zero, generate your first entity with Power Tools and see how much time it saves.

What .NET 10 LTS Means for Enterprise Applications

ismail Cagdas — Wed, 21 Jan 2026 05:45:09 +0000

If you are running enterprise applications on .NET 8 or .NET 9, there is an important date you need to mark on your calendar: November 10, 2026.

On that day, both .NET 8 and .NET 9 will reach end of support—simultaneously. This is not a typo. Due to Microsoft's decision to extend Standard Term Support (STS) from 18 to 24 months, both versions now share the same end-of-life date.

This creates a unique situation for enterprise teams: whether you played it safe with .NET 8 LTS or chased the latest features with .NET 9, you now face the same migration deadline.

The target? .NET 10 LTS, released in November 2025 and supported until November 2028.

The Support Timeline You Need to Understand

Microsoft follows a predictable release cadence: even-numbered releases are Long Term Support (LTS) with three years of support, while odd-numbered releases are Standard Term Support (STS) with 18-24 months.

Here is the current state of .NET support:

Version	Release Type	End of Support
.NET 6	LTS	November 12, 2024 (Already EOL)
.NET 7	STS	May 14, 2024 (Already EOL)
.NET 8	LTS	November 10, 2026
.NET 9	STS	November 10, 2026
.NET 10	LTS	November 10, 2028

If you are still running .NET 6 or .NET 7, you are already operating on unsupported frameworks. No security patches. No bug fixes. This is a compliance risk that needs immediate attention.

Why .NET 10 LTS Matters for Enterprise

Every two years, Microsoft releases an LTS version. Usually, it is the "safe" choice—the boring, stable option that enterprises pick while developers chase newer features. This time is different.

.NET 10 LTS is not just a stability release. It is a significant leap forward in performance, security, and AI readiness.

1. Performance That Impacts Your Bottom Line

The performance improvements in .NET 10 are not incremental. Real-world benchmarks show:

30-50% performance improvements from JIT inlining, method devirtualization, and stack allocation optimizations
40-60% reduction in memory usage through array interface de-virtualization
60-80% improvements in specific high-throughput scenarios

For enterprise applications, this translates directly to infrastructure savings. If your cloud bill is tied to CPU and memory consumption, .NET 10 can meaningfully reduce your costs without changing a single line of business logic.

2. Security and Compliance Acceleration

Enterprise applications live and die by compliance requirements. .NET 10 strengthens your security posture through:

Updated cipher suites with modern cryptographic standards
Improved request validation and hardened default configurations
Enhanced vulnerability patching workflows
Post-quantum cryptography support via Windows CNG

That last point deserves attention. Financial services, government contractors, and healthcare organizations are already being asked about quantum-resistant encryption strategies. .NET 10's built-in post-quantum cryptography support checks that compliance box automatically.

3. AI-Ready Infrastructure

.NET 10 arrives with built-in AI integration through the new Microsoft Agent Framework. Combined with expanded ML.NET capabilities and new tensor APIs, your applications are positioned to integrate AI features without bolting on external dependencies.

This is not about hype. It is about having the foundation in place when your business stakeholders inevitably ask for AI-powered features.

4. Entity Framework Core 10: Enterprise Data Features

For data-driven enterprise applications, EF Core 10 brings two significant additions:

Vector search support for SQL Server 2025 and Azure SQL Database—enabling embeddings and similarity search directly in your ORM
Native JSON type support for the new SQL Server JSON data type

If your roadmap includes semantic search, recommendation engines, or any AI/ML features that rely on vector embeddings, EF Core 10 eliminates the need for specialized vector databases in many scenarios.

The Migration Decision Matrix

Not every organization has the same constraints. Here is how to think about your migration strategy:

If You Are on .NET 9

This is the easiest path. You are moving from a 2-year STS window to a 3-year LTS window. Most projects can complete this migration in 2-5 days. The breaking changes are minimal, and you gain 2.5 additional years of support.

Recommendation: Migrate immediately. There is no reason to wait.

If You Are on .NET 8 LTS

You have until November 2026, but do not let that create complacency. The performance improvements alone justify an earlier migration. Plan your upgrade cycle for Q2 2026 at the latest to allow buffer for testing.

Recommendation: Start planning now. Execute migration by mid-2026.

If You Are on .NET 6 or .NET 7

You are running unsupported frameworks. Every day without patches is a day of accumulated security risk. This is not a feature migration—it is a critical security remediation.

Recommendation: Treat this as a P1 priority. Migrate immediately.

If You Are on .NET Framework 4.8

The jump to .NET 10 is significant but achievable. Modern tooling, including AI-assisted migration with GitHub Copilot, makes this transformation practical. The benefits—cross-platform support, containerization, modern performance—justify the investment.

Recommendation: Begin assessment now. Plan a phased migration over the next 12-18 months.

Tooling Requirements: The Visual Studio Question

There is one critical constraint: .NET 10 requires Visual Studio 2026. Visual Studio 2022 cannot target .NET 10 or use C# 14 features.

For enterprises with standardized development environments, this means:

VS Code + C# Dev Kit is a fully supported alternative available today
Visual Studio 2026 GA is expected in early 2026
Most enterprises should wait for VS 2026 GA before full rollout, but developers can start with VS Code immediately

This is not a blocker, but it does need to factor into your planning.

Breaking Changes to Prepare For

Every major release brings breaking changes. Here are the ones that will impact most enterprise applications:

WebHostBuilder and IWebHost Are Obsolete

The legacy hosting model is deprecated. If your applications still use WebHostBuilder, you need to migrate to WebApplicationBuilder. This is the direction Microsoft has been pushing since .NET 6, and .NET 10 makes it explicit.

Before:

var host = new WebHostBuilder()
    .UseKestrel()
    .UseStartup<Startup>()
    .Build();

After:

var builder = WebApplication.CreateBuilder(args);
// Configure services
var app = builder.Build();
// Configure middleware
app.Run();

WithOpenApi Extension Method Removed

If you are using the WithOpenApi() extension method for minimal APIs, it has been removed. Use the updated OpenAPI generator features instead.

Default Images Now Use Ubuntu

.NET container images now default to Ubuntu instead of Debian. If your deployment pipelines or Dockerfiles assume Debian-specific packages, you will need to update them.

The Three-Year Runway

.NET 10 LTS support extends until November 2028. This gives your organization three full years to:

Stabilize on a modern, performant runtime
Adopt AI and ML features at your own pace
Plan the next major upgrade cycle without pressure

Compare this to the version hopscotch of STS releases. For enterprise applications that value stability and predictability, .NET 10 LTS is the clear choice.

Conclusion: The Time to Act Is Now

The convergence of .NET 8 and .NET 9 end-of-support dates creates a forcing function. Every .NET application in your portfolio needs to be on .NET 10 by November 2026.

But this is not just about avoiding end-of-life. .NET 10 delivers genuine improvements:

Performance gains that reduce infrastructure costs
Security features that accelerate compliance
AI integration that positions you for the future
Three years of LTS support that provides stability

Start your assessment now. Identify your applications, understand your dependencies, and plan your migration timeline. The runway to November 2026 is shorter than it appears.

A Review of AI-Assisted Development Tools and My Workflow

ismail Cagdas — Thu, 15 Jan 2026 11:28:22 +0000

The world of software development is buzzing with the promise of Artificial Intelligence, and like many of you, I've been exploring the growing landscape of AI-assisted development tools. As a .NET/ASP.NET Core developer and open-source contributor, I've been piecing together a workflow that helps me leverage these powerful assistants. It's been a journey of discovery, full of pleasant surprises and a few hurdles.

Here's a look at the tools in my current rotation and the workflow I've settled on for now.

My AI Toolkit: A Review of Development Assistants

Vibe Kanban: The Mission Control

I start most of my tasks in Vibe Kanban. Its strength lies in its flexibility. I can connect it to multiple repositories and, more importantly, assign different AI models to different tasks. I have access to GitHub Copilot, Gemini, and Claude, and Vibe Kanban lets me switch between them seamlessly. This is perfect for running multiple tasks in parallel, though I've found that reviewing the generated output is still a time-consuming but necessary step.

Claude: The Master Planner

Claude is my go-to for planning. I find it's excellent at understanding programming concepts and laying out a structured plan. The main drawback is the token expiration, which can sometimes be a bit of a nuisance. If I have enouhg limit, mostly I ask Claude to implement Phase 1 of the plan it created.

Cursor: The Coder

When it's time to write code, I turn to Cursor. Its "auto mode" is a standout feature, as it's incredibly efficient with token usage, which is a major concern in AI-assisted development. However, as a .NET developer, I sometimes find it challenging to work on my projects within Cursor and occasionally have to switch back to Rider or Visual Studio for certain tasks.

Gemini: The Technical Writer

Interestingly, I don't use Gemini much for coding. Instead, it has become my trusted partner for writing technical articles and documentation. In this area, it truly excels.

GitHub Copilot: The Dependable Backup

I use GitHub Copilot less frequently than the others, but it's a reliable tool for smaller tasks, especially when I've run out of tokens on other platforms.

My AI-Powered Development Workflow

My process has evolved into a multi-stage workflow that leverages the strengths of different AI tools:

Plan with Claude: I start by asking Claude to create a detailed plan in a markdown format using Vibe Kanban.
Review and Refine: I thoroughly review the plan. If any adjustments are needed, I'll work with Claude to refine it.
Branch and Commit: Once the plan is solid, I create a new branch and commit the plan file. This provides clear context for the work that follows.
Code with Cursor: With the plan in hand, I open Cursor and begin the development work, following the roadmap laid out by Claude.
AI-Assisted Review: After the initial coding is done, I use another AI to review the changes and suggest improvements.
Manual Verification: The final step is always a manual review and testing of the functionality to ensure everything works as expected.

What's Next?

My next goal is to automate the testing phase. I plan to create a process that runs automated tests before I begin my manual review, which should help streamline the final verification step.

What's Your Workflow?

This is just a snapshot of my current process, and I'm sure it will continue to evolve. I'm curious to hear about your experiences. What tools are you using for AI-assisted development, and what does your workflow look like? Feel free to share your thoughts and recommendations!

An Opinionated Solution Structure for ASP.NET Core Projects

ismail Cagdas — Mon, 12 Jan 2026 12:23:07 +0000

As software projects grow, maintaining a clean and organized codebase becomes increasingly challenging. A well-thought-out solution structure can make the difference between a maintainable application and a tangled mess of dependencies. In this article, I'll walk you through the opinionated solution structure we use in ABP Framework — a structure that has proven itself in thousands of production applications.

Why Solution Structure Matters

Before diving into the details, let's understand why investing time in your solution structure pays off:

Maintainability: Clear boundaries make code easier to understand and modify
Testability: Well-separated layers are easier to test in isolation
Team Collaboration: Developers can work on different layers without conflicts
Scalability: A good structure grows with your application

The Root Level

We have a sample project named Acme.BookStore. I will try to explain the solution structure using this sample ASP.NET Core application.
Let's start with what you'll find at the root of the solution:

Acme.BookStore/
├── src/                    # Source projects
├── test/                   # Test projects
├── Acme.BookStore.sln      # Solution file
├── common.props            # Shared MSBuild properties
├── global.json             # SDK version pinning
└── NuGet.Config            # Package source configuration

The separation of src/ and test/ folders provides immediate clarity. The common.props file centralizes build configurations, ensuring consistency across all projects.

Source Projects: A Layered Architecture

The src/ folder contains the heart of your application, organized into distinct layers:

Domain Shared (`Acme.BookStore.Domain.Shared`)

This is the foundation layer with zero dependencies on other project layers. It contains:

Constants and enums
Shared value objects
Localization resources
Exception codes

// Example: BookType enum that can be shared across all layers
public enum BookType
{
    Adventure,
    Biography,
    Fiction,
    Science
}

Why separate this? These elements are often needed by multiple layers and even external clients. Keeping them in a dedicated project prevents circular dependencies.

Domain (`Acme.BookStore.Domain`)

The core business logic lives here:

Entities and aggregate roots
Repository interfaces (not implementations!)
Domain services
Domain events

public class Book : AggregateRoot<Guid>
{
    public string Name { get; set; }
    public BookType Type { get; set; }
    public DateTime PublishDate { get; set; }
}

This layer is infrastructure-agnostic — it doesn't know about databases, APIs, or UI frameworks.

Application Contracts (`Acme.BookStore.Application.Contracts`)

This project defines the application layer's public API:

Data Transfer Objects (DTOs)
Application service interfaces
Permission definitions

public interface IBookAppService : IApplicationService
{
    Task<BookDto> GetAsync(Guid id);
    Task<PagedResultDto<BookDto>> GetListAsync(GetBookListDto input);
    Task<BookDto> CreateAsync(CreateBookDto input);
}

Key benefit: This project can be shared with clients (like a Blazor WebAssembly app) without exposing implementation details.

Application (`Acme.BookStore.Application`)

Implementation of the application services:

Application service implementations
Object mapping configurations
Business workflow orchestration

public class BookAppService : ApplicationService, IBookAppService
{
    private readonly IRepository<Book, Guid> _bookRepository;

    public async Task<BookDto> GetAsync(Guid id)
    {
        var book = await _bookRepository.GetAsync(id);
        return ObjectMapper.Map<Book, BookDto>(book);
    }
}

Entity Framework Core (`Acme.BookStore.EntityFrameworkCore`)

Infrastructure layer for data access:

DbContext implementation
Repository implementations
Entity configurations
Database migrations

public class BookStoreDbContext : AbpDbContext<BookStoreDbContext>
{
    public DbSet<Book> Books { get; set; }

    protected override void OnModelCreating(ModelBuilder builder)
    {
        base.OnModelCreating(builder);
        builder.Entity<Book>(b =>
        {
            b.ToTable("Books");
            b.Property(x => x.Name).IsRequired().HasMaxLength(128);
        });
    }
}

HTTP API (`Acme.BookStore.HttpApi`)

API controllers that expose your application services:

[Route("api/books")]
public class BookController : AbpController
{
    private readonly IBookAppService _bookAppService;

    [HttpGet("{id}")]
    public Task<BookDto> GetAsync(Guid id)
    {
        return _bookAppService.GetAsync(id);
    }
}

HTTP API Client (`Acme.BookStore.HttpApi.Client`)

This is a powerful pattern — typed HTTP client proxies for consuming your API:

// Consumers can use IBookAppService directly
// The proxy handles HTTP calls transparently
var books = await _bookAppService.GetListAsync(new GetBookListDto());

This enables code sharing between server and client applications, reducing duplication and ensuring type safety.

Web (`Acme.BookStore.Web`)

The UI layer — whether Razor Pages, Blazor, or MVC:

Pages/Components
View models
Static assets
UI-specific configurations

Database Migrator (`Acme.BookStore.DbMigrator`)

A console application for:

Running database migrations
Seeding initial data
DevOps-friendly deployment scenarios (Like updating all tenant databases if you use database-per tenant approach)

Test Projects: Comprehensive Coverage

The test/ folder mirrors the source structure:

Project	Purpose
`TestBase`	Shared test infrastructure and utilities
`Domain.Tests`	Unit tests for domain logic
`Application.Tests`	Application service integration tests
`EntityFrameworkCore.Tests`	Repository and database tests
`HttpApi.Client.ConsoleTestApp`	End-to-end API testing
`Web.Tests`	UI layer tests

This structure makes it clear what you're testing and enables focused test runs during development.

Key Benefits of This Structure

1. Clear Separation of Concerns

Each project has a single, well-defined responsibility. Developers immediately know where to find and place code.

2. Dependency Inversion in Practice

The domain layer defines repository interfaces; the infrastructure layer implements them. Your business logic remains pure.

3. Shareable Contracts

The .Domain.Shared and .Application.Contracts projects can be packaged as NuGet packages and shared:

Across microservices
With client applications
With external integrators

4. Testability by Design

Each layer can be tested in isolation with appropriate mocking strategies.

5. Database Independence

Switching from SQL Server to PostgreSQL? Only the EntityFrameworkCore project needs changes.

6. Ready for Growth

This structure naturally evolves into modular monolith or microservices architectures.

Beyond Monolith: Modular and Microservice Architectures

While this article focuses on a single application structure, the same principles scale beautifully:

Modular Monolith

You can organize your solution into independent modules, each following this layered structure. Modules communicate through well-defined interfaces, giving you the benefits of microservices without the operational complexity.

Microservices

Each microservice can follow this exact structure, with the .Domain.Shared and .Application.Contracts projects published as NuGet packages for inter-service communication.

ABP Framework provides comprehensive templates and guidance for both architectures. Check out the ABP Framework GitHub repository for:

Modular application templates
Microservice solution templates
Real-world sample applications

Getting Started

If you'd like to try this structure yourself, ABP Framework provides CLI tools to generate solutions with this exact architecture:

dotnet tool install -g Volo.Abp.Studio.Cli
abp new Acme.BookStore -m none --theme leptonx-lite -csf --connection-string "Server=(LocalDb)\\MSSQLLocalDB;Database=BookStore;Trusted_Connection=True;TrustServerCertificate=true"

Or, you can go to https://abp.io/get-started page and select other options like PostgreSQL, MongoDB, Angular, Blazor etc...

Conclusion

A well-organized solution structure is an investment that pays dividends throughout your project's lifecycle. The layered architecture presented here — with its clear separation between domain, application, infrastructure, and presentation layers — provides a solid foundation for building maintainable, testable, and scalable ASP.NET Core applications.

I encourage you to explore the ABP Framework on GitHub to see this structure in action across numerous modules and sample applications. As one of the developers of ABP Framework, I've seen firsthand how this architecture helps teams build robust applications efficiently.

Whether you're building a simple CRUD application or an enterprise-grade distributed system, starting with a clean structure will serve you well. Happy coding!

Have questions or feedback? Feel free to open an issue on the ABP Framework GitHub repository or join our community discussions.

An Opinionated Solution Structure for ASP.NET Core Projects

Why Solution Structure Matters

Before diving into the details, let's understand why investing time in your solution structure pays off:

Maintainability: Clear boundaries make code easier to understand and modify
Testability: Well-separated layers are easier to test in isolation
Team Collaboration: Developers can work on different layers without conflicts
Scalability: A good structure grows with your application

The Root Level

We have a sample project named Acme.BookStore. I will try to explain the solution structure using this sample ASP.NET Core application.
Let's start with what you'll find at the root of the solution:

Acme.BookStore/
├── src/                    # Source projects
├── test/                   # Test projects
├── Acme.BookStore.sln      # Solution file
├── common.props            # Shared MSBuild properties
├── global.json             # SDK version pinning
└── NuGet.Config            # Package source configuration

The separation of src/ and test/ folders provides immediate clarity. The common.props file centralizes build configurations, ensuring consistency across all projects.

Source Projects: A Layered Architecture

The src/ folder contains the heart of your application, organized into distinct layers:

Domain Shared (`Acme.BookStore.Domain.Shared`)

This is the foundation layer with zero dependencies on other project layers. It contains:

Constants and enums
Shared value objects
Localization resources
Exception codes

// Example: BookType enum that can be shared across all layers
public enum BookType
{
    Adventure,
    Biography,
    Fiction,
    Science
}

Why separate this? These elements are often needed by multiple layers and even external clients. Keeping them in a dedicated project prevents circular dependencies.

Domain (`Acme.BookStore.Domain`)

The core business logic lives here:

Entities and aggregate roots
Repository interfaces (not implementations!)
Domain services
Domain events

public class Book : AggregateRoot<Guid>
{
    public string Name { get; set; }
    public BookType Type { get; set; }
    public DateTime PublishDate { get; set; }
}

This layer is infrastructure-agnostic — it doesn't know about databases, APIs, or UI frameworks.

Application Contracts (`Acme.BookStore.Application.Contracts`)

This project defines the application layer's public API:

Data Transfer Objects (DTOs)
Application service interfaces
Permission definitions

public interface IBookAppService : IApplicationService
{
    Task<BookDto> GetAsync(Guid id);
    Task<PagedResultDto<BookDto>> GetListAsync(GetBookListDto input);
    Task<BookDto> CreateAsync(CreateBookDto input);
}

Key benefit: This project can be shared with clients (like a Blazor WebAssembly app) without exposing implementation details.

Application (`Acme.BookStore.Application`)

Implementation of the application services:

Application service implementations
Object mapping configurations
Business workflow orchestration

public class BookAppService : ApplicationService, IBookAppService
{
    private readonly IRepository<Book, Guid> _bookRepository;

    public async Task<BookDto> GetAsync(Guid id)
    {
        var book = await _bookRepository.GetAsync(id);
        return ObjectMapper.Map<Book, BookDto>(book);
    }
}

Entity Framework Core (`Acme.BookStore.EntityFrameworkCore`)

Infrastructure layer for data access:

DbContext implementation
Repository implementations
Entity configurations
Database migrations

public class BookStoreDbContext : AbpDbContext<BookStoreDbContext>
{
    public DbSet<Book> Books { get; set; }

    protected override void OnModelCreating(ModelBuilder builder)
    {
        base.OnModelCreating(builder);
        builder.Entity<Book>(b =>
        {
            b.ToTable("Books");
            b.Property(x => x.Name).IsRequired().HasMaxLength(128);
        });
    }
}

HTTP API (`Acme.BookStore.HttpApi`)

API controllers that expose your application services:

[Route("api/books")]
public class BookController : AbpController
{
    private readonly IBookAppService _bookAppService;

    [HttpGet("{id}")]
    public Task<BookDto> GetAsync(Guid id)
    {
        return _bookAppService.GetAsync(id);
    }
}

HTTP API Client (`Acme.BookStore.HttpApi.Client`)

This is a powerful pattern — typed HTTP client proxies for consuming your API:

// Consumers can use IBookAppService directly
// The proxy handles HTTP calls transparently
var books = await _bookAppService.GetListAsync(new GetBookListDto());

This enables code sharing between server and client applications, reducing duplication and ensuring type safety.

Web (`Acme.BookStore.Web`)

The UI layer — whether Razor Pages, Blazor, or MVC:

Pages/Components
View models
Static assets
UI-specific configurations

Database Migrator (`Acme.BookStore.DbMigrator`)

A console application for:

Running database migrations
Seeding initial data
DevOps-friendly deployment scenarios (Like updating all tenant databases if you use database-per tenant approach)

Test Projects: Comprehensive Coverage

The test/ folder mirrors the source structure:

Project	Purpose
`TestBase`	Shared test infrastructure and utilities
`Domain.Tests`	Unit tests for domain logic
`Application.Tests`	Application service integration tests
`EntityFrameworkCore.Tests`	Repository and database tests
`HttpApi.Client.ConsoleTestApp`	End-to-end API testing
`Web.Tests`	UI layer tests

This structure makes it clear what you're testing and enables focused test runs during development.

Key Benefits of This Structure

1. Clear Separation of Concerns

Each project has a single, well-defined responsibility. Developers immediately know where to find and place code.

2. Dependency Inversion in Practice

The domain layer defines repository interfaces; the infrastructure layer implements them. Your business logic remains pure.

3. Shareable Contracts

The .Domain.Shared and .Application.Contracts projects can be packaged as NuGet packages and shared:

Across microservices
With client applications
With external integrators

4. Testability by Design

Each layer can be tested in isolation with appropriate mocking strategies.

5. Database Independence

Switching from SQL Server to PostgreSQL? Only the EntityFrameworkCore project needs changes.

6. Ready for Growth

This structure naturally evolves into modular monolith or microservices architectures.

Beyond Monolith: Modular and Microservice Architectures

While this article focuses on a single application structure, the same principles scale beautifully:

Modular Monolith

Microservices

Each microservice can follow this exact structure, with the .Domain.Shared and .Application.Contracts projects published as NuGet packages for inter-service communication.

ABP Framework provides comprehensive templates and guidance for both architectures. Check out the ABP Framework GitHub repository for:

Modular application templates
Microservice solution templates
Real-world sample applications

Getting Started

If you'd like to try this structure yourself, ABP Framework provides CLI tools to generate solutions with this exact architecture:

dotnet tool install -g Volo.Abp.Studio.Cli
abp new Acme.BookStore -m none --theme leptonx-lite -csf --connection-string "Server=(LocalDb)\\MSSQLLocalDB;Database=BookStore;Trusted_Connection=True;TrustServerCertificate=true"

Or, you can go to https://abp.io/get-started page and select other options like PostgreSQL, MongoDB, Angular, Blazor etc...

Conclusion

Whether you're building a simple CRUD application or an enterprise-grade distributed system, starting with a clean structure will serve you well. Happy coding!

Have questions or feedback? Feel free to open an issue on the ABP Framework GitHub repository or join our community discussions.

Why Modular Monolith Architecture is the Key to Effective AI-Assisted Development

ismail Cagdas — Tue, 06 Jan 2026 13:53:35 +0000

AI coding assistants have revolutionized how we write code. Tools like GitHub Copilot, Claude, ChatGPT, and Cursor have become indispensable companions for developers worldwide. However, there's a growing challenge that many developers are experiencing: as your codebase grows, AI-generated code quality decreases significantly.

In this article, we'll explore why this happens and how ABP Framework's modular monolith architecture provides an elegant solution to this problem.

The Problem: AI Struggles with Large Codebases

If you've been using AI coding assistants for a while, you've probably noticed a pattern. When you start a new project, AI suggestions are remarkably accurate. The code is clean, follows best practices, and integrates nicely with your existing code. But as your project grows to hundreds of files and thousands of lines of code, something changes.

Context Window Limitations

AI models have a fundamental constraint: context windows. Even the most advanced models can only process a limited amount of code at once. When your project has 500+ files with complex interdependencies, the AI simply cannot see the full picture.

Consider this scenario:

📁 MyLargeProject/
├── 📁 src/
│   ├── 📁 Domain/ (50+ files)
│   ├── 📁 Application/ (80+ files)
│   ├── 📁 Infrastructure/ (40+ files)
│   ├── 📁 HttpApi/ (60+ files)
│   └── 📁 Web/ (100+ files)
├── 📁 tests/ (150+ files)
└── 📁 shared/ (30+ files)

When you ask AI to implement a new feature, it might see only 10-20 of these files in its context. The result? Code that:

Duplicates existing functionality
Violates established patterns in your codebase
Uses inconsistent naming conventions
Creates unnecessary coupling between components
Ignores your custom base classes and utilities

The Consistency Problem

In a large monolithic codebase, there are often multiple ways to accomplish the same task. Your team might have established specific patterns over time, but the AI doesn't know about these conventions unless they're explicitly provided in the context.

// Your established pattern (which AI doesn't see)
public class ProductAppService : ApplicationService, IProductAppService
{
    private readonly IRepository<Product, Guid> _productRepository;

    public ProductAppService(IRepository<Product, Guid> productRepository)
    {
        _productRepository = productRepository;
    }

    public async Task<ProductDto> GetAsync(Guid id)
    {
        var product = await _productRepository.GetAsync(id);
        return ObjectMapper.Map<Product, ProductDto>(product);
    }
}

// What AI might generate (inconsistent with your patterns)
public class OrderService
{
    private readonly DbContext _context;

    public OrderService(DbContext context)
    {
        _context = context;
    }

    public async Task<OrderDto> Get(Guid id)
    {
        var order = await _context.Orders.FindAsync(id);
        return new OrderDto 
        { 
            Id = order.Id,
            // Manual mapping...
        };
    }
}

The AI-generated code works, but it introduces inconsistency, bypasses your repository abstractions, and ignores your mapping conventions.

The Solution: Modular Monolith Architecture

This is where ABP Framework's modular monolith architecture shines. Instead of one massive codebase, you organize your application into isolated modules.

What is a Module in ABP?

An ABP module is a independent unit that encapsulates a specific business capability:

📁 Acme.ProductManagement/
├── 📁 src/
│   ├── Acme.ProductManagement.Domain/
│   ├── Acme.ProductManagement.Domain.Shared/
│   ├── Acme.ProductManagement.Application/
│   ├── Acme.ProductManagement.Application.Contracts/
│   ├── Acme.ProductManagement.EntityFrameworkCore/
│   ├── Acme.ProductManagement.HttpApi/
│   └── Acme.ProductManagement.Web/
└── 📁 test/
    └── Acme.ProductManagement.Application.Tests/

Each module has:

Clear boundaries: Well-defined interfaces for communication with other modules
Independent domain: Its own entities, repositories, and domain services
Isolated application layer: Application services that don't leak into other modules
Focused scope: Typically 10-30 files per layer, not hundreds

How This Helps AI

When you work with AI on a modular codebase, you can scope the conversation to a single module. Instead of providing context about your entire 500-file project, you provide context about a 50-file module.

"I'm working on the ProductManagement module in an ABP Framework project.
Here's the module structure and key files:
- Product entity (Domain layer)
- IProductRepository interface
- ProductAppService (Application layer)

I need to add a feature to track product price history..."

Now the AI has:

A complete picture of the relevant code
Clear patterns to follow
Defined boundaries it shouldn't cross
Consistent conventions throughout

Benefits of Module-Scoped AI Development

1. Reduced Context Size = Better Understanding

A typical ABP module contains a focused set of files that easily fit within AI context windows:

Scope	Files	AI Understanding
Full Monolith	500+	Poor - sees fragments
Single Module	30-50	Excellent - sees everything

When AI can see your entire module, it understands:

How entities relate to each other
Which base classes and interfaces to use
Your naming conventions and patterns
The existing functionality to avoid duplication

2. ABP Conventions Guide the AI

ABP Framework follows strong conventions. When you tell AI you're working with ABP, it can leverage these conventions:

// AI understands ABP patterns and generates consistent code
public class CategoryAppService : ProductManagementAppService, ICategoryAppService
{
    private readonly ICategoryRepository _categoryRepository;

    public CategoryAppService(ICategoryRepository categoryRepository)
    {
        _categoryRepository = categoryRepository;
    }

    [Authorize(ProductManagementPermissions.Categories.Create)]
    public async Task<CategoryDto> CreateAsync(CreateCategoryDto input)
    {
        var category = new Category(GuidGenerator.Create(), input.Name);
        await _categoryRepository.InsertAsync(category);
        return ObjectMapper.Map<Category, CategoryDto>(category);
    }
}

The AI naturally:

Inherits from the correct base class
Uses the module's permission definitions
Follows the repository pattern
Uses ABP's GuidGenerator and ObjectMapper

3. Easier Code Review

When AI-generated code is confined to a module, code review becomes straightforward:

git diff --stat

 src/Acme.ProductManagement.Domain/Categories/Category.cs        | 25 +++
 src/Acme.ProductManagement.Application/Categories/CategoryAppService.cs | 45 +++
 src/Acme.ProductManagement.HttpApi/Categories/CategoryController.cs     | 30 +++
 3 files changed, 100 insertions(+)

All changes are in one module. Reviewers familiar with that module can quickly validate the code quality.

4. Sustainable and Maintainable Code

Modular code generated by AI remains maintainable because:

It follows established patterns within the module
Dependencies are explicit and limited
The code can be understood in isolation
Future AI sessions can easily pick up where you left off

Practical Tips for AI-Assisted ABP Development

Tip 1: Provide Module Context Upfront

Start your AI conversation with module context:

I'm working on an ABP Framework application.
Current module: Acme.Ordering
Module purpose: Handle customer orders and order processing

Key entities:
- Order (AggregateRoot)
- OrderLine (Entity)
- OrderStatus (Enum)

Existing services:
- IOrderRepository
- OrderManager (Domain Service)
- OrderAppService

I want to add a feature to...

Tip 2: Reference ABP Conventions Explicitly

When asking AI to generate code, mention the conventions:

Generate an Application Service for managing Shipments.
Follow ABP conventions:
- Inherit from ApplicationService
- Use IRepository<T, TKey> for data access
- Use ObjectMapper for DTO mapping
- Define permissions in ShipmentPermissions class
- Use [Authorize] attributes for permission checks

In the following versions of ABP, these instructions will be included in your project out of the box. So, AI will write better and maintainable code by following ABP standards and best practices.

Tip 3: Keep Cross-Module Communication Explicit

When your feature spans multiple modules, break it down:

Step 1: Add the event class in Ordering.Domain.Shared
Step 2: Publish the event from OrderAppService
Step 3: (Separate session) Handle the event in Shipping module

This keeps each AI session focused on one module.

Tip 4: Use Module Templates as Examples

Provide AI with examples from your existing module code:

Here's how we implement app services in this module:

[Example of existing ProductAppService]

Now create a similar service for handling Categories.

Tip 5: Validate Within Module Boundaries

After AI generates code, verify it respects module boundaries:

✅ Good: Module references only its own layers and shared contracts
❌ Bad: Direct references to other module's domain or application layers

// ❌ Bad - crossing module boundaries
using Acme.Inventory.Domain; // Direct reference to another module's domain!

// ✅ Good - using integration events or shared contracts
using Acme.Inventory.Application.Contracts; // Only reference contracts

Real-World Example: Before and After

Before: AI in a Large Monolith

Prompt: "Add a feature to apply discounts to orders"

AI Result:

Creates discount logic directly in OrderController
Duplicates validation that exists in another service
Uses direct database access instead of repositories
Ignores existing Price calculation utilities

Time spent fixing: 2 hours

After: AI with Module Focus

Prompt:

In the Acme.Ordering module, add discount support.
- Add DiscountInfo value object to Order aggregate
- Add ApplyDiscount method to Order entity
- Update OrderAppService.CreateAsync to accept discount code
- Use existing IDiscountValidator from Ordering.Domain

AI Result:

Correctly extends Order aggregate
Follows existing patterns in the module
Uses the domain service you mentioned
Generates consistent, reviewable code

Time spent fixing: 15 minutes

Conclusion

The modular monolith architecture isn't just an architectural pattern—it's becoming essential for effective AI-assisted development. As AI tools continue to evolve, codebases that are organized into clear, focused modules will get significantly better results from these tools.

ABP Framework's modular architecture, with its strong conventions, clear boundaries, and standardized patterns, creates an ideal environment for AI-assisted development:

Modules provide focused context that AI can fully understand
ABP conventions guide AI to generate consistent, framework-aligned code
Clear boundaries prevent AI from creating unwanted dependencies
Standardized patterns make AI-generated code predictable and maintainable

If you're building applications with AI assistance (and who isn't these days?), consider how your architecture affects AI code quality. Investing in a modular structure with ABP Framework pays dividends not just in traditional software engineering benefits, but in dramatically improved AI-assisted development workflows.

The future of development is human-AI collaboration. Make sure your architecture is ready for it.

To learn more about ABP Framework, visit it's documentation.

Have you experienced similar challenges with AI in large codebases? Share your experiences and tips in the comments below!

Forem: ismail Cagdas

Angular vs React for ASP.NET Core: A Comprehensive Comparison Guide (2026)

Table of Contents

The Short Answer

Architecture: Opinionated vs Library

TypeScript: Mandatory vs Optional

Learning Curve

Performance and Bundle Size

Ecosystem and Community

AI and Agentic Coding

Enterprise Fit

Forms

State Management

Testing

CI/CD and DevOps

Team Scaling

Integration with ASP.NET Core

The Decision Matrix

The "Effortless" Option

Bonus: Where Does Blazor Fit?

Frequently Asked Questions

Is Angular dead in 2026?

Is React really faster than Angular?

Which is better for an ASP.NET Core backend?

Can I switch from React to Angular (or vice versa) later?

What if my team doesn't know either?

Does ASP.NET Zero support both?

Conclusion

React + ASP.NET Core: Enterprise Project Getting Started Guide

Table of Contents

Prerequisites

Approach 1 - Manual Setup

Step 1: Create the React App with Vite

Step 2: Create the ASP.NET Core Web API

Step 3: Configure CORS

Step 4: Configure the Vite Proxy

Step 5: Make the First API Call from React

Approach 2 - Visual Studio Template

Approach 3 - ASP.NET Zero React UI

Quick Start

Why This Matters for Enterprise Teams

v15.2 RAD Advantage

Comparison

Common Issues and Solutions

Vite Proxy Returns 404

HMR Not Refreshing Correctly

CORS Error in Browser Console

Authentication Integration Complexity

Next Steps

Angular + ASP.NET Core: Enterprise Project Getting Started Guide (2026)

Table of Contents

Prerequisites

Approach 1 — Manual Setup

Step 1: Create the Angular App

Step 2: Create the ASP.NET Core Web API

Step 3: Configure CORS

Step 4: Set Up the Angular Proxy

Step 5: Make the First API Call

Approach 2 — Visual Studio Template

Approach 3 — ASP.NET Zero

Comparison

Common Issues and Solutions

CORS Errors

Proxy Not Working

SSL Certificate Errors

Angular CLI Version Mismatch

Next Steps

Angular + ASP.NET Core: Enterprise Project Getting Started Guide

Table of Contents

Prerequisites

Approach 1 — Manual Setup

Step 1: Create the Angular App

Step 2: Create the ASP.NET Core Web API

Step 3: Configure CORS

Step 4: Set Up the Angular Proxy

Step 5: Make the First API Call

Approach 2 — Visual Studio Template

Approach 3 — ASP.NET Zero

Comparison

Common Issues and Solutions

Domain Shared (`Acme.BookStore.Domain.Shared`)

Domain (`Acme.BookStore.Domain`)

Application Contracts (`Acme.BookStore.Application.Contracts`)

Application (`Acme.BookStore.Application`)

Entity Framework Core (`Acme.BookStore.EntityFrameworkCore`)

HTTP API (`Acme.BookStore.HttpApi`)

HTTP API Client (`Acme.BookStore.HttpApi.Client`)

Web (`Acme.BookStore.Web`)

Database Migrator (`Acme.BookStore.DbMigrator`)

Domain Shared (`Acme.BookStore.Domain.Shared`)

Domain (`Acme.BookStore.Domain`)

Application Contracts (`Acme.BookStore.Application.Contracts`)

Application (`Acme.BookStore.Application`)

Entity Framework Core (`Acme.BookStore.EntityFrameworkCore`)

HTTP API (`Acme.BookStore.HttpApi`)