Chapter 2: Understanding ASP.NET Core

Introduction

This chapter introduces why web frameworks and ASP.NET Core exist, the framework's application approaches, and how .NET developers can decide whether to adopt or migrate to ASP.NET Core.

• Chapter scope and outcomes: Describe that the chapter provides background on the usefulness and origins of ASP.NET Core, its application paradigms, and guidance for choosing or migrating to it.
  Why it matters: This roadmap helps you connect the chapter's background material to practical adoption decisions.
• Developer adoption guidance: Explain that the chapter is intended both to orient developers new to .NET and to help existing .NET developers judge whether to focus on .NET Core and .NET 7, including ASP.NET Core's advantages over earlier ASP.NET versions.
  Why it matters: Your previous .NET experience affects which adoption and migration questions matter most.

Key terms: web frameworks, ASP.NET Core, application paradigms, migrating, .NET development, .NET Core, .NET 7, previous versions of ASP.NET

2.1 Using a web framework

This section explains why web frameworks such as ASP.NET Core are needed to build secure, maintainable, dynamic web applications rather than only simple static sites.

• Web framework value: Explain why building a static web application without a web framework is possible but becomes difficult when the application needs security or dynamic behavior. Describe how ASP.NET Core makes web development faster, easier, and more secure than building those capabilities from scratch.
  Why it matters: This explains the practical reason to use ASP.NET Core instead of writing all web-application infrastructure yourself.
• Framework-provided capabilities: Describe the kinds of common capabilities ASP.NET Core provides, including dynamic pages, user login and Facebook login, application structure, configuration, static image serving, and request logging. Explain that these libraries provide reusable support for recurring web-application needs.
  Why it matters: Recognizing these built-in capabilities shows how a framework reduces the amount of infrastructure an application must create itself.
• Dynamic web page purpose: Explain that a dynamic web page can show different data for the logged-in user or display content submitted by users. State that dynamic web frameworks make login and personalized content possible, enabling sites such as Amazon, eBay, and Stack Overflow.
  Why it matters: Dynamic, personalized content is the essential capability that distinguishes modern interactive websites from simple static sites.

Key terms: web framework, static web application, ASP.NET Core, security, dynamic behavior, libraries, configuration files, logging requests, maintainable applications, Facebook accounts

2.2 Why ASP.NET Core was created

This section explains why Microsoft rebuilt ASP.NET as ASP.NET Core on the modern, cross-platform .NET platform and how its modular design addresses limitations of legacy ASP.NET.

• ASP.NET Core design goals: Explain the five goals that motivated ASP.NET Core: cross-platform development and execution, modularity, open-source development, web standards, and support for modern web development such as client-side apps and cloud deployment.
  Why it matters: These goals explain the architectural choices and trade-offs you will see throughout ASP.NET Core.
• Modern .NET platform relationship: Describe how ASP.NET Core runs on .NET Core and its successor .NET 5+, rather than on the Windows-only .NET Framework. Distinguish .NET Core from .NET 5+ as the book uses those names, and explain that the modern platform is separate from, not a fork of, .NET Framework.
  Why it matters: Knowing which underlying platform an application targets clarifies why ASP.NET Core can run across operating systems and differs from legacy ASP.NET.
• Legacy ASP.NET constraints: Explain why the legacy ASP.NET stack became limiting: Web Forms had a complex stateful model, weak testability, and limited control over generated HTML, while ASP.NET's System.Web.dll and IIS coupling tied it to Windows and made framework evolution slow.
  Why it matters: The limitations of the older stack make clear why ASP.NET Core involved a rewrite rather than another incremental ASP.NET update.
• Modular application composition: Describe ASP.NET Core as a layer added to a cross-platform .NET console application, where web capabilities are composed from libraries. Distinguish commonly used base capabilities, such as configuration and logging, from optional libraries for application-specific features such as third-party logins.
  Why it matters: This composition model prepares you to understand why ASP.NET Core applications explicitly add services and request-handling features.
• Framework rewrite and conventions: State that ASP.NET Core is a new, rewritten framework and technology stack, not merely another incremental ASP.NET version, while retaining familiar ideas for existing .NET developers. Describe how common APIs, extension libraries, and shared configuration conventions collectively make up the broad term ASP.NET Core.
  Why it matters: This helps you expect familiarity in application development without assuming complete compatibility with older ASP.NET.

Key terms: cross-platform, modular architecture, open-source software, web standards, client-side applications, cloud environments, .NET Framework, .NET Core, .NET 5+, .NET 5

2.3 Understanding the many paradigms of ASP.NET Core

This section surveys the ASP.NET Core paradigms for server-rendered websites, HTTP and gRPC APIs, and interactive Blazor applications, and relates each to suitable application styles.

• ASP.NET Core paradigm range: Describe the main ASP.NET Core paradigms and the kinds of applications they support: minimal APIs, web APIs, gRPC APIs, Razor Pages, MVC controllers, Blazor WebAssembly, and Blazor Server. Explain that they share ASP.NET Core core functionality while layering paradigm-specific features on top.
  Why it matters: Knowing the available paradigms helps you match ASP.NET Core’s application model to the app you need to build.
• Server-rendered website paradigms: Distinguish Razor Pages and MVC controllers as the two ASP.NET Core paradigms for traditional page-based, server-side-rendered web applications. State that Razor Pages uses a page-based paradigm, whereas MVC controllers offer a different style, although the two share many concepts.
  Why it matters: This distinction prepares you to understand the two main approaches for building dynamic HTML websites with ASP.NET Core.
• HTTP and gRPC service choices: Describe minimal APIs and web APIs as approaches for building HTTP or REST API servers, with web APIs providing more structure and features than minimal APIs. Distinguish these from gRPC, which supports efficient binary RPC-style, server-to-server communication, and state that REST commonly uses lightweight, stateless HTTP calls to read, create or update, and delete data.
  Why it matters: Choosing the appropriate service style lets an ASP.NET Core application serve mobile apps, browser SPAs, or other servers effectively.
• Blazor hosting models: Distinguish Blazor WebAssembly from Blazor Server. Explain that WebAssembly apps run .NET code in the browser for client-side interactivity, whereas Blazor Server runs the application on the server and sends user events over WebSockets and UI updates back to the browser, requiring a constant internet connection.
  Why it matters: The Blazor hosting model determines where application code runs and what connection requirements the interactive application has.
• Book paradigm focus: State that this book focuses on traditional server-rendered web applications and RESTful web APIs, while also covering background worker services later, rather than teaching Blazor in detail.
  Why it matters: This sets expectations for which ASP.NET Core paradigms receive practical coverage in the book.

Key terms: Minimal APIs, Web APIs, gRPC APIs, Razor Pages, MVC controllers, Blazor WebAssembly, server-side-rendered, page-based paradigm, REST, RESTful

2.4 When to choose ASP.NET Core

This section frames the choice of ASP.NET Core around support considerations and whether you are new to .NET or are building or converting an application.

• ASP.NET Core selection factors: Describe the primary factors this chapter uses to decide whether ASP.NET Core is appropriate: whether you are already a .NET developer and whether the work is a new application or a conversion of an existing application.
  Why it matters: These two dimensions organize the more specific adoption guidance in the following subsections.
• Support and open development: Explain why platform support is a nontechnical consideration for ASP.NET Core, including Microsoft's support commitment for LTS releases and the role of the open-source community.
  Why it matters: A platform choice includes confidence that help and support will remain available after adoption.
• Default preference with caveats: State that ASP.NET Core will be the choice in most cases over legacy .NET Framework ASP.NET, while recognizing that important caveats still need consideration.
  Why it matters: The section establishes ASP.NET Core as the usual direction without presenting it as an automatic choice in every situation.

Key terms: ASP.NET Core, .NET 7, legacy .NET Framework ASP.NET, new application, existing application, Long Term Support (LTS), .NET, open-source software, Microsoft, caveats

2.4.1 If you’re new to .NET development

This subsection explains why ASP.NET Core is an approachable choice for developers new to .NET, emphasizing C#, cross-platform deployment, containers, and familiar web-development patterns.

• C# as primary language: State that C# is the primary language for .NET and ASP.NET Core, and describe why developers from C, Java, or similar object-oriented languages may find it familiar. Explain that the book uses C# but does not teach the language from scratch.
  Why it matters: You need enough C# familiarity to follow the examples while recognizing that ASP.NET Core is the book’s main subject.
• Cross-platform IL deployment: Explain the compile-once, run-anywhere model: an application compiles to platform-independent Intermediate Language (IL) and can run on Mac, Windows, or Linux when the target has the .NET 7 runtime. Distinguish this from a self-contained deployment, which packages the runtime but produces files customized for a particular target machine.
  Why it matters: This portability lets you develop on one operating system and deploy the same application to another.
• Container deployment advantages: Describe why containers suit ASP.NET Core deployments: compared with virtual machines, containers are lightweight, layered, quick to start, and do not require booting a separate operating system. Relate lightweight ASP.NET Core and .NET 7 applications to thin container deployments.
  Why it matters: Containers can make scalable application deployment and provisioning more efficient than heavier virtual-machine deployments.
• Transferable framework patterns: Describe how ASP.NET Core uses established web-framework design patterns, including pipelines, dependency injection, and MVC. Explain that prior familiarity with these patterns transfers to ASP.NET Core, while newcomers can learn them as industry practices.
  Why it matters: Recognizing these recurring patterns makes ASP.NET Core easier to learn and prepares you for its major programming models.

Key terms: C#, LINQ, closures, asynchronous programming, Roslyn, .NET 7, Intermediate Language (IL), compile-once, run-anywhere, self-contained deployment (SCD), runtime

2.4.2 If you’re a .NET Framework developer creating a new application

This section explains why .NET Framework developers should choose ASP.NET Core for new applications, emphasizing cross-platform deployment, its Kestrel-based hosting model, modular features, and modern release model.

• Cross-platform adoption considerations: Explain why .NET Framework developers can consider ASP.NET Core and .NET 7 mature choices for new applications. Describe the cross-platform benefits and the limitation of using Windows-specific APIs.
  Why it matters: This helps you decide whether a new application can gain portability and hosting flexibility by moving to ASP.NET Core.
• Kestrel self-hosting model: Describe how ASP.NET Core's hosting model differs from the previous ASP.NET model: an ASP.NET Core application is a console application that self-hosts an HTTP server, normally Kestrel, and handles requests directly rather than IIS calling into application-specific integration points.
  Why it matters: The self-hosting model explains how ASP.NET Core runs, debugs, and deploys independently of a tightly coupled IIS host.
• Reverse proxy responsibilities: Explain the role of a reverse proxy in front of Kestrel: it receives internet-facing requests and forwards them to the application web server. Distinguish the proxy's security, process-management, and internet-connection concerns from Kestrel's responsibility for generating HTTP responses.
  Why it matters: Knowing this separation helps you understand common production deployments without treating a reverse proxy and Kestrel as redundant.
• Modular platform and releases: Describe ASP.NET Core's modular, pay-for-play design and its modern release approach. Explain that applications start bare-bones and opt into needed packages and infrastructure, while .NET releases predictable major versions and can deliver fixes, minor updates, and NuGet functionality independently.
  Why it matters: This explains why ASP.NET Core applications can avoid unnecessary dependencies while gaining framework capabilities when needed.
• New application recommendation limits: State the section's recommendation that Microsoft-supported ASP.NET Core is generally appropriate for new systems, while recognizing that unsupported programming models such as Web Forms and WCF Server can be a practical obstacle.
  Why it matters: This frames the recommendation correctly: a new application is a different decision from converting an existing ASP.NET application.

Key terms: .NET 7, cross-platform, Windows Compatibility Pack, Registry, Directory Services, hosting model, Kestrel, HTTP server, self-host, console application

2.4.3 Converting an existing ASP.NET application to ASP.NET Core

This section explains how to judge, plan, and reduce the risk of moving an existing ASP.NET application to ASP.NET Core.

• Porting value assessment: Justify porting an existing ASP.NET application only when its tangible benefits, such as cross-platform deployment, modular features, or performance, outweigh the significant rewrite effort.
  Why it matters: A migration should solve a worthwhile business or technical problem rather than consume effort merely to use a newer framework.
• Web Forms migration strategies: Describe why ASP.NET Web Forms cannot be directly converted to ASP.NET Core and outline the possible gradual migration paths through Blazor server or web APIs.
  Why it matters: Recognizing that Web Forms is tied to older infrastructure helps you plan a replacement or staged migration instead of expecting a direct port.
• WCF support limitations: Explain that ASP.NET Core supports WCF only partially, distinguish its client-side and server-side options, and state when retaining .NET Framework may be necessary.
  Why it matters: WCF dependencies can determine whether an application can move to ASP.NET Core without losing required capabilities.
• Incremental porting approach: Describe how application size and use of legacy MVC, web API extensibility points, or message handlers increase porting difficulty, and explain how iterative migration using the strangler fig pattern reduces risk.
  Why it matters: Moving functionality in small pieces can avoid the risk of attempting a single large rewrite of a valuable application.
• Candidate application selection: Distinguish applications that are poor porting candidates from those for which porting may be worthwhile.
  Why it matters: Prioritizing the right applications directs migration effort toward work that will deliver future value.

Key terms: cross-platform deployment, modular features, performance, rewrite, ASP.NET Web Forms, System.Web.dll, IIS, Blazor server, web API, ViewState

2.5 Summary

This summary recaps ASP.NET Core's modern cross-platform design, its fit for new or migrating applications, and its typical reverse-proxy deployment arrangement.