ASP.NET
ASP.NET is a web framework developed by Microsoft for building web applications and services. Its modern iteration, ASP.NET Core, is open-source and cross-platform, running on Windows, Linux, macOS, and in Docker containers.[1] It enables developers to create dynamic websites, web APIs, and cloud-based services using languages like C# and technologies such as HTML, CSS, JavaScript, and Razor syntax.[2] Originally introduced as part of the .NET Framework in 2002, ASP.NET provided a server-side model for developing dynamic web pages, succeeding Active Server Pages (ASP). The legacy ASP.NET is Windows-only and proprietary, and has been in maintenance mode since 2022, receiving only security updates.[3] Over time, it evolved to include multiple programming models, such as Web Forms for rapid development with drag-and-drop controls, MVC (Model-View-Controller) for structured separation of concerns, and Web API for building RESTful services.[3] In 2016, Microsoft released ASP.NET Core, a redesigned, modular, and high-performance version that is cross-platform and open-source under the MIT License.[4] ASP.NET Core runs on the .NET runtime (formerly .NET Core), supporting features like dependency injection, middleware pipelines, and integration with Entity Framework for data access.[5] It powers interactive applications with Blazor for client-side web UI using C#, real-time functionality via SignalR, and scalable APIs with built-in support for OpenAPI (Swagger).[2] Key advantages of ASP.NET include its performance, as demonstrated in TechEmpower benchmarks where it outperforms many popular frameworks, and its seamless integration with Azure for cloud deployment.[6] As of November 2025, ASP.NET Core is the recommended framework for new development, with the recent release of .NET 10 / ASP.NET Core 10.0 focusing on enhanced security, minimal APIs, and improved developer productivity.[7] The framework's ecosystem supports microservices, single-page applications (SPAs), and progressive web apps (PWAs), making it a cornerstone of enterprise web development.[8]History and Development
Origins in .NET Framework
ASP.NET originated as a core component of Microsoft's .NET Framework, announced in July 2000 at the Professional Developers Conference (PDC) as part of the broader .NET Platform initiative aimed at advancing web services and application development.[9][10] Development began in the late 1990s under the codename Next Generation Windows Services (NGWS), evolving into a unified framework for building scalable web applications.[11] Following the announcement, Microsoft released initial beta versions of ASP.NET in 2000, with additional betas in 2001 to refine features and gather developer feedback before stabilization.[9] The first stable release, ASP.NET 1.0, launched on February 13, 2002, integrated with .NET Framework 1.0 to provide a robust server-side web development platform.[12] Designed as the successor to classic Active Server Pages (ASP), ASP.NET shifted from interpreted scripting to compiled code execution, enabling event-driven programming models and seamless integration with .NET languages such as C# and VB.NET for enhanced performance and productivity.[13] This evolution addressed limitations in classic ASP, such as runtime parsing and COM interop inefficiencies, by leveraging the Common Language Runtime (CLR) for managed code execution.[11] At launch, ASP.NET introduced key innovations including server controls—reusable components that abstract HTML rendering and handle user interactions declaratively—and view state, a mechanism for persisting page and control data across HTTP requests without server-side session storage.[14] Additionally, ADO.NET provided a disconnected data access architecture with datasets and data adapters, facilitating efficient integration of database operations into web applications. Early adoption faced challenges due to its exclusive dependency on Windows Server and Internet Information Services (IIS) for hosting, limiting deployment options compared to platform-agnostic alternatives. Developers transitioning from classic ASP's procedural scripting encountered a steeper learning curve, requiring adaptation to object-oriented paradigms, state management concepts like view state, and the post-back model.[13] Despite these hurdles, ASP.NET quickly gained traction among enterprise developers for its structured approach to web development.Evolution and Key Milestones
ASP.NET evolved through iterative enhancements to the .NET Framework, introducing features that improved developer productivity and web application capabilities. The release of .NET Framework 2.0 in November 2005 marked a significant milestone, bringing master pages for consistent layout management across pages and initial support for AJAX through extensions that enabled partial page updates without full postbacks.[15][16] In 2007, .NET Framework 3.5 extended these capabilities with the introduction of Language Integrated Query (LINQ), allowing developers to query data sources using a unified syntax integrated into C# and Visual Basic, which simplified data access in ASP.NET applications.[17][18] By 2010, .NET Framework 4.0 further refined the framework with a streamlined Web.config file to reduce configuration complexity and built-in URL routing for Web Forms, enabling cleaner, SEO-friendly URLs without mapping directly to physical files.[12][19] A pivotal shift occurred in 2009 with the release of ASP.NET MVC 1.0, which provided an alternative to the traditional Web Forms model by emphasizing the Model-View-Controller pattern for better separation of concerns, testability, and maintainability in web development.[20] This parallel programming model addressed growing demands for more structured architectures in complex applications. The most transformative milestone came in 2016 with the release of ASP.NET Core 1.0, a complete rewrite as an open-source, cross-platform framework under .NET Core, unifying MVC, Web API, and SignalR into a single, modular runtime.[21] This evolution was driven by needs for higher performance in resource-constrained environments, seamless integration with cloud platforms like Azure, and incorporation of open-source community feedback to enhance modularity and extensibility.[22] Subsequent developments included the unification of .NET Framework and .NET Core into a single .NET platform starting with .NET 5 in November 2020, which streamlined development by making ASP.NET Core the recommended path for new web applications and emphasizing cross-platform capabilities.[23] Key long-term support (LTS) releases, such as .NET 6 in 2021 and .NET 8 in 2023, further advanced performance, security, and features like minimal APIs and enhanced Blazor support, with .NET 9 released in November 2024 continuing this trajectory as of November 2025.[24]Core Architecture
ASP.NET Framework Components
The ASP.NET Framework relies on the Common Language Runtime (CLR) as its core runtime environment, enabling the execution of managed code written in languages like C# and VB.NET. The CLR provides essential services such as just-in-time (JIT) compilation, automatic memory management through garbage collection, and type safety to prevent runtime errors like invalid casts or null reference exceptions. This integration ensures that ASP.NET applications run in a secure, verifiable environment where code is executed within application domains for isolation and resource management.[25][26] Key subsystems in the ASP.NET Framework include the HTTP runtime, which processes incoming HTTP requests by parsing them, routing to appropriate handlers, and managing the overall request pipeline. Configuration is handled primarily through the Web.config file, an XML-based structure that defines settings for the application, such as connection strings, custom errors, and HTTP module registrations, allowing hierarchical inheritance from machine-wide to application-specific levels. The compilation model supports dynamic compilation, where pages and code are compiled on the first request for rapid development, or pre-compilation, which builds assemblies in advance for deployment to improve performance and enable error detection before runtime.[27][28][29] The page framework forms a central component, implementing an event-driven lifecycle that begins with request acquisition by the HTTP runtime, proceeds through initialization, loading of view state, event handling, and data binding, and concludes with rendering the response to the client. This lifecycle supports server controls, such as the GridView for displaying tabular data with built-in sorting and paging, and validation controls like RequiredFieldValidator for ensuring input integrity without custom code. These controls are instantiated and managed during specific lifecycle phases to maintain state across postbacks.[30][31][32] Integration with Windows services is foundational, particularly with Internet Information Services (IIS) for hosting, where ASP.NET extends IIS through ISAPI filters and extensions in classic mode or integrated pipeline mode for seamless request processing. Authentication providers, configurable via Web.config, include Windows authentication leveraging IIS's Negotiate/NTLM/Kerberos mechanisms and forms authentication for custom credential storage, ensuring secure user sessions within the IIS environment. Unlike ASP.NET Core's lightweight Kestrel server, the Framework's components are tightly coupled to IIS for Windows-specific hosting.[33][34]ASP.NET Core Modular Design
ASP.NET Core introduces a modular foundation built on the .NET runtime, where core functionality is delivered through lightweight NuGet packages rather than a monolithic installation. This design enables developers to include only the necessary components, such as MVC or Razor Pages, via methods likeAddControllersWithViews() or AddRazorPages(), resulting in smaller application footprints and improved performance. By decoupling features into packages, ASP.NET Core supports cross-platform development and facilitates easier updates without requiring a full framework reinstall.[35][22]
Central to this modularity is the middleware pipeline, a customizable chain of components that processes incoming HTTP requests and outgoing responses in a sequential manner. Each middleware handles specific tasks, such as logging via UseLogging(), authentication with UseAuthentication(), or routing through UseRouting(), allowing developers to compose the pipeline in the Program.cs file using extension methods like app.Use(). This pipeline operates on the HttpContext object, enabling flexible, ordered execution that can be tailored to application needs without tight coupling to the underlying runtime. The modular nature of middleware promotes reusability and separation of concerns, contrasting with the more rigid processing in earlier frameworks.[36][35]
ASP.NET Core includes a built-in dependency injection (DI) container that manages object creation and lifetimes, integrated directly into the framework via the IServiceCollection interface. Services are registered during application startup using methods like services.AddSingleton(), services.AddScoped(), or services.AddTransient(), which define how instances are shared—singleton for application-wide single instances, scoped for per-request lifecycles, and transient for new instances per resolution. This DI system supports inversion of control, allowing components to request dependencies through constructors, enhancing testability and modularity by avoiding hardcoded dependencies. For example, database contexts can be registered with services.AddDbContext<MyContext>() to inject configuration-aware services automatically.[37][38]
Configuration in ASP.NET Core is handled through a provider-based system that prioritizes JSON files like appsettings.json, with support for environment-specific overrides such as appsettings.Development.json. The IConfiguration interface aggregates sources including environment variables and command-line arguments, enabling seamless adaptation across deployment scenarios without recompilation. This approach separates configuration from code, reinforcing the modular design by allowing runtime adjustments that align with the framework's independence from operating system specifics. Hosting is abstracted via the IHost or WebApplication models, which decouple the application from platform dependencies, supporting diverse environments through configurable builders.[39][35]
Programming Models
Web Forms and Post-Back Model
ASP.NET Web Forms provides an event-driven, stateful programming model within the ASP.NET Framework, enabling developers to create dynamic web pages using a rich set of server controls and a post-back mechanism for handling user interactions. This model abstracts much of the underlying HTTP protocol, allowing for rapid application development similar to desktop programming paradigms. Developers can utilize drag-and-drop functionality in Visual Studio to place server controls on pages, which are then processed on the server to generate HTML output sent to the client.[40][41] Central to this model are server controls, such as the Button and TextBox, which encapsulate both markup and behavior. These Web server controls render as standard HTML elements in the browser but maintain server-side logic for events and state. For instance, a Button control generates an<input type="submit"> element that, when clicked, initiates a post-back to the server, while a TextBox renders as an <input type="text"> for user input. The framework automatically handles the conversion between these controls and their HTML representations, simplifying the creation of interactive user interfaces.[14])
To maintain state across the inherently stateless HTTP requests, Web Forms employs View State, a mechanism that serializes the properties of pages and controls into a base64-encoded string stored in a hidden form field named __VIEWSTATE. This data is automatically restored on subsequent post-backs, preserving values like user-entered text in a TextBox or the selected index in a dropdown list without requiring manual intervention. View State is enabled by default for all server controls but can be disabled selectively to optimize performance, though doing so requires alternative state management for affected elements.[42]
The post-back mechanism forms the core of user interaction in Web Forms, where client-side actions like button clicks or form submissions send the entire page (or portions thereof) back to the server for processing. Synchronous post-backs refresh the full page, triggering server-side events such as Button.Click or page-level Load. For asynchronous post-backs, the UpdatePanel control enables partial page updates by wrapping sections of the page, reducing the data transferred and avoiding full reloads while still invoking the server event model. This approach supports scenarios like updating a grid without disrupting the entire layout.[43]
Page processing in Web Forms follows a well-defined lifecycle of events, ensuring consistent handling of initialization, state restoration, event execution, and rendering, particularly during post-backs. The sequence begins with the Init event, where controls are initialized and any master pages or themes are applied, but View State properties are not yet loaded. Next, the Load event restores control properties from View State and control state, allowing access to persisted values. If the request is a post-back, control-specific event handlers (e.g., Button.Click) are then invoked, followed by validation if applicable. The PreRender event provides the final opportunity for modifications before View State is serialized and saved. Finally, the Unload event handles cleanup tasks, such as closing database connections, after the response has been generated but before the page is discarded. This structured lifecycle facilitates predictable behavior and debugging in stateful applications.[44]
Web Forms excels in use cases requiring rapid development of data-driven user interfaces, such as enterprise applications with forms, grids, and validation logic, where the control library and event model accelerate prototyping and maintenance. However, the heavy reliance on View State and full or partial post-backs can lead to larger page payloads, potentially impacting load times and complicating SEO optimization due to dynamic content generation. Additionally, the server-centric approach may hinder native mobile responsiveness, as post-backs do not align seamlessly with touch-based interactions or varying screen sizes without additional CSS and JavaScript adaptations.[41][42]
MVC, Razor Pages, and API Development
ASP.NET Core MVC implements the Model-View-Controller (MVC) design pattern, which promotes separation of concerns by dividing application logic into three interconnected components: the model for data and business rules, the view for rendering the user interface, and the controller for handling user input and coordinating responses.[45] This separation facilitates testable code, as controllers can be unit tested independently without relying on views or full HTTP contexts, enabling developers to mock dependencies and verify behavior in isolation.[45] Controllers are classes that inherit fromController or ControllerBase, processing incoming HTTP requests, interacting with models, and selecting appropriate views or returning data directly.
Views in MVC utilize Razor templating, a syntax that embeds C# code within HTML markup to generate dynamic content, such as declaring a model with @model IEnumerable<Product> or iterating over data with @foreach (var item in Model) { <p>@item.Name</p> }.[46] Razor syntax supports conditional rendering, partial views for reusable UI components, and Tag Helpers for server-side attributes that produce cleaner HTML, like <input asp-for="Email" /> for model-bound form inputs.[47] This approach ensures views remain focused on presentation while leveraging strongly typed models for type safety and IntelliSense support in development tools.[46]
Razor Pages, introduced in ASP.NET Core 2.0, offer a page-focused programming model that simplifies development for page-centric applications, particularly those involving basic CRUD operations, by combining the handler logic and markup within a single .cshtml file or its associated code-behind.[48] Each Razor Page consists of a .cshtml file containing HTML with embedded Razor syntax and a corresponding PageModel class (in .cshtml.cs) that defines properties for data binding and handler methods like OnGetAsync() for retrieving data on page load or OnPostAsync() for form submissions.[49] The @page directive at the top of the .cshtml file registers the page as an endpoint, enabling convention-based routing where the file name determines the URL, such as Pages/Index.cshtml mapping to "/".[48]
This model reduces boilerplate compared to traditional MVC by colocating related code, making it easier to maintain small-scale web apps without separate controllers for each page; for instance, a handler might bind form data automatically and redirect after processing, as in public async Task<IActionResult> OnPostAsync(Product product) { if (ModelState.IsValid) { await _context.SaveChangesAsync(); return RedirectToPage("./Index"); } return Page(); }. Razor Pages support model binding, validation with attributes like [Required], and dependency injection for services, aligning with ASP.NET Core's modular design while maintaining stateless, HTTP-compliant behavior.[48]
Web API development in ASP.NET Core centers on building RESTful services that expose endpoints for data operations, typically using controllers derived from ControllerBase to handle HTTP methods without view rendering.[50] Attribute routing simplifies URL mapping with attributes like [Route("api/[controller]")] on the controller class and [HttpGet], [HttpPost] on actions, allowing patterns such as GET /api/products for listing items or POST /api/products for creation, where the controller name (e.g., ProductsController) fills the placeholder.[50] The [ApiController] attribute enables API-specific conventions, including automatic model validation that returns 400 Bad Request for invalid inputs and inference of response types.[50]
JSON serialization and deserialization are handled by System.Text.Json, the default formatter in ASP.NET Core, which converts objects to and from JSON streams efficiently, supporting features like case-insensitive property matching and polymorphic serialization via options configuration. For example, an action might return return Ok(new { Id = 1, Name = "Product" }); to produce JSON output, or use CreatedAtAction(nameof(GetProduct), new { id = product.Id }, product); for 201 Created responses with location headers, ensuring adherence to REST principles for scalable, stateless APIs.[50]
Blazor integrates with ASP.NET Core to enable interactive web UIs using C# and .NET components instead of JavaScript. As of .NET 8 and continuing in .NET 9, Blazor primarily uses a unified model in Blazor Web Apps with render modes that determine interactivity and hosting: static server-side rendering for non-interactive content, Interactive Server for server-side rendering with real-time updates via SignalR (similar to legacy Blazor Server), Interactive WebAssembly for client-side execution in the browser through WebAssembly, and Interactive Auto which starts with server rendering and switches to WebAssembly. Legacy Blazor Server and standalone Blazor WebAssembly apps remain supported for existing projects.[51] In Interactive Server mode, Razor components (.razor files) render on the server, with UI events triggering diffs sent over SignalR for efficient updates, suitable for low-latency intranet apps.[52] Blazor WebAssembly downloads the .NET runtime to the client, allowing full offline capability and direct API calls, while sharing Razor syntax for component markup like @page "/counter" <h1>Counter</h1> <p>Current count: @currentCount</p> <button @onclick="IncrementCount">Click me</button> @code { private int currentCount = 0; private void IncrementCount() { currentCount++; } }.[53] This integration leverages ASP.NET Core's routing and middleware pipeline for hosting Blazor apps alongside MVC or Razor Pages endpoints.[52]
Hosting and Deployment
IIS Integration and Pipeline
ASP.NET Framework applications are hosted on Internet Information Services (IIS) in Windows environments through the use of Internet Server Application Programming Interface (ISAPI) extensions and filters, which enable the server to route requests to the appropriate ASP.NET handler based on file extensions. For instance, requests for .aspx files are mapped to aspnet_isapi.dll, the core ISAPI extension that bridges IIS and the ASP.NET runtime, allowing the framework to process dynamic content.[54]) This model, prominent in IIS 6.0 and earlier, operates in classic mode, where ASP.NET maintains a separate request pipeline from IIS's native pipeline, limiting interoperability between native ISAPI components and managed ASP.NET modules.) The introduction of integrated pipeline mode in IIS 7.0, released in 2008, marked a significant evolution by unifying the IIS native pipeline with the ASP.NET managed pipeline into a single, cohesive request-processing architecture.[33] In this mode, ASP.NET modules can execute at any stage of the request lifecycle alongside native IIS modules, enabling uniform processing of all requests—regardless of handler—for shared features such as authentication, authorization, and caching.[55] This integration allows pre-conditioned handler mappings to automatically select the appropriate ASP.NET version and runtime, directing requests to managed handlers instead of relying solely on ISAPI in classic mode.[33] The ASP.NET request pipeline in integrated mode progresses through a series of well-defined events, starting with BeginRequest and concluding with EndRequest, during which modules and handlers perform specific tasks. Modules, such as the UrlRoutingModule, intervene at stages like PostResolveRequestCache to handle URL routing, while handlers like PageHandlerFactory are invoked after the PostMapRequestHandler stage to process specific content types, such as rendering ASPX pages.) Key intermediate events include AuthenticateRequest for user identity verification and AuthorizeRequest for access checks, ensuring comprehensive request handling across the pipeline.[56] This staged approach provides extensibility, as developers can register custom modules and handlers to hook into these events for tailored processing.) Configuration of the IIS integration occurs primarily through the Web.config file, where the <system.webServer> section defines IIS-specific elements like handler mappings and module registrations. For example, handlers are added via theCross-Platform Hosting in ASP.NET Core
ASP.NET Core introduces cross-platform hosting capabilities, allowing applications to run on Windows, Linux, and macOS without dependency on Internet Information Services (IIS). This flexibility is achieved through the Kestrel web server, which serves as the default HTTP server and supports self-hosting scenarios. Unlike the original ASP.NET Framework, which was tightly coupled to Windows and IIS, ASP.NET Core's modular design enables deployment in diverse environments, including cloud platforms and containers.[58][59] Kestrel is a lightweight, high-performance, cross-platform web server implemented in managed code, capable of handling HTTP/1.1, HTTP/2, and HTTP/3 protocols. It is included by default in ASP.NET Core projects and can be configured programmatically to bind to specific ports, enable HTTPS, and set limits such as maximum request body size or concurrent connections. For instance, developers can customize Kestrel options in theProgram.cs file using the UseKestrel method on the host builder, allowing fine-tuned control over listening endpoints and security settings. This configuration ensures compatibility across operating systems, with Kestrel leveraging platform-specific networking APIs for optimal performance on Linux and macOS.[58][60][61]
The hosting environment in ASP.NET Core is typically initialized in Program.cs using the modern minimal hosting model with WebApplication.CreateBuilder (recommended since .NET 6 in 2021), which sets up a cross-platform web host with built-in support for Kestrel, configuration providers, logging, and dependency injection. This approach automatically detects the runtime environment and configures the application to run seamlessly on Windows, Linux, or macOS, including content root and web root paths adjusted for the host OS, while reducing boilerplate code by integrating service registration and middleware configuration directly in Program.cs. The older WebHost.CreateDefaultBuilder method remains available for backward compatibility but is legacy. An example setup might look like this:[35]
This approach abstracts away OS-specific details, enabling developers to build once and deploy across platforms without code changes.[35] In production environments, Kestrel is rarely exposed directly to the internet due to its focus on core request processing; instead, it integrates with reverse proxy servers like Nginx or Apache for enhanced security, load balancing, and static file serving. These proxies forward requests to Kestrel while preserving client information, such as the real IP address, through thecsharpvar builder = WebApplication.CreateBuilder(args); // Add services to the container. builder.Services.AddControllersWithViews(); var app = builder.Build(); // Configure the HTTP request pipeline. if (!app.Environment.IsDevelopment()) { app.UseExceptionHandler("/Error"); app.UseHsts(); } app.UseHttpsRedirection(); app.UseStaticFiles(); app.UseRouting(); app.UseAuthorization(); app.MapControllerRoute( name: "default", pattern: "{controller=Home}/{action=Index}/{id?}"); app.Run();var builder = WebApplication.CreateBuilder(args); // Add services to the container. builder.Services.AddControllersWithViews(); var app = builder.Build(); // Configure the HTTP request pipeline. if (!app.Environment.IsDevelopment()) { app.UseExceptionHandler("/Error"); app.UseHsts(); } app.UseHttpsRedirection(); app.UseStaticFiles(); app.UseRouting(); app.UseAuthorization(); app.MapControllerRoute( name: "default", pattern: "{controller=Home}/{action=Index}/{id?}"); app.Run();
ForwardedHeaders middleware in the application's pipeline. Configuration involves enabling the middleware early in the request pipeline and setting trusted proxy networks to prevent spoofing. For example, Nginx can be set up to proxy requests to Kestrel on a local port, ensuring robust handling of HTTPS termination and traffic routing on Linux-based servers.[62]
Deployment options for cross-platform hosting emphasize containerization and cloud services. Docker containers package ASP.NET Core applications with their dependencies, allowing consistent execution on any Docker-supported host, including Linux servers or Kubernetes clusters; official .NET Docker images facilitate multi-stage builds for efficient runtime images. Azure App Service provides managed hosting for ASP.NET Core apps on both Windows and Linux plans, supporting automatic scaling and integration with Kestrel via built-in reverse proxy capabilities. In hybrid scenarios, IIS can act as a reverse proxy on Windows, forwarding requests to a self-hosted Kestrel instance while leveraging IIS for URL rewriting and authentication. These options enable scalable, platform-agnostic deployments without altering the core application logic.[63][64][65]
Versions and Lifecycle
ASP.NET Framework Releases
The ASP.NET Framework, part of the .NET Framework, has evolved through several versions since its initial release, each introducing enhancements to web development capabilities, performance, and integration with emerging technologies. The original ASP.NET was tightly coupled with the Windows ecosystem and Internet Information Services (IIS), focusing on server-side rendering and state management for dynamic web applications. Releases were tied to .NET Framework versions, with key innovations in controls, security, and asynchronous processing to support enterprise-scale web apps.[66] The version history spans from 1.0 in 2002 to 4.8 in 2019, with a minor update in 4.8.1 in 2022. Early versions emphasized foundational web forms and postback models, while later ones added AJAX support, improved rendering, and async patterns. Mainstream support for most versions ended between 2009 and 2022, but extended security updates continue for select versions like 3.5 and 4.8, reflecting its ongoing use in legacy systems. Microsoft provides paths for migration to ASP.NET Core for modern applications, though the Framework persists in many enterprise environments due to its stability and backward compatibility.[67][12]| Version | Release Date | Key ASP.NET Features | End of Support |
|---|---|---|---|
| 1.0 | February 13, 2002 | Introduced Web Forms for event-driven programming, server controls, data binding, and mobile controls; built on CLR 1.0 for basic web application development.[66] | Ended January 13, 2009 (extended).[12] |
| 1.1 | April 30, 2003 | Enhanced performance with better mobile support, themes for consistent styling, precompilation for faster deployment, and improved security via built-in cryptography; supported side-by-side execution with 1.0.[68][66] | Ended July 14, 2009 (extended).[12] |
| 2.0 | November 7, 2005 | Added master pages for layout consistency, membership and role providers for authentication, personalization services, new controls like GridView and DetailsView, and client callbacks for partial updates; integrated with CLR 2.0 for generics and improved scalability.[69][66] | Ended April 12, 2011 (mainstream); extended support ended April 10, 2013.[12] |
| 3.0 | November 6, 2006 | Introduced Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF) integration for service-oriented apps, with ASP.NET hosting support; no major ASP.NET-specific changes but enhanced overall framework for web services.[66] | Ended July 12, 2011 (mainstream); extended support ended April 10, 2013.[12] |
| 3.5 | November 19, 2007 | Built-in AJAX controls and extensions for asynchronous updates without full postbacks, LINQ integration for data querying, and RESTful services via WCF; included AJAX Control Toolkit for richer client interactions.[70][66] | Mainstream ended January 13, 2015; extended support ends January 9, 2029 (for 3.5 SP1).[12][67] |
| 4.0 | April 12, 2010 | Improved HTML rendering for cleaner markup, URL routing for SEO-friendly paths, permanent redirects, client ID mode control to avoid naming conflicts, and enhanced ViewState management; supported MVC 3 with Razor syntax.[71][72][66] | Ended January 12, 2016 (all support).[12][73] |
| 4.5 | August 15, 2012 | Async support using Task-based patterns for better scalability in I/O-bound operations, bundling and minification for optimized resource delivery, model binding enhancements, and lazy request validation to handle unvalidated input selectively.[74][66] | Ended January 12, 2016 (all support).[12][73] |
| 4.5.1 | October 17, 2013 | Added One ASP.NET for unified configuration across Web Forms, MVC, and Web API; improved Bootstrap integration, new membership system with OWIN support, and better mobile responsiveness.[75][66] | Ended January 12, 2016 (all support).[12][73] |
| 4.5.2 | May 5, 2014 | Enhanced async logging and tracing, per-core locking for better multi-threading, and improved support for cloud environments; minor ASP.NET updates focused on performance tuning.[66] | Ended April 26, 2022 (all support).[67] |
| 4.6 | July 15, 2015 | HTTP/2 protocol support for faster web performance, improved cryptography with TLS 1.1/1.2 defaults, and Roslyn compiler integration for better editing; ASP.NET benefited from enhanced JIT compilation.[66] | Ended April 26, 2022 (all support).[67] |
| 4.6.1 | November 18, 2015 | Added support for new TLS versions, improved debugging, and algebraic data types in some libraries; ASP.NET updates included better JSON handling and authentication middleware.[66] | Ended April 26, 2022 (all support).[67] |
| 4.6.2 | August 2, 2016 | Introduced child process debugging, better high-DPI support, and SQL Server 2016 compatibility; ASP.NET saw enhancements in cross-device rendering.[66] | Active until January 12, 2027 (extended).[67] |
| 4.7 | April 5, 2017 | Improved TLS 1.3 support, better WPF accessibility, and .NET Standard 2.0 compatibility; ASP.NET features focused on security hardening and performance.[66] | Active (support aligned with Windows OS lifecycle; no announced end date as of November 2025).[67] |
| 4.7.1 | October 17, 2017 | Enhanced support for OpenSSH, better ARM64 compatibility, and improved serialization; minor ASP.NET updates for authentication flows.[66] | Active (support aligned with Windows OS lifecycle; no announced end date as of November 2025).[67] |
| 4.7.2 | April 30, 2018 | Added support for new cryptographic algorithms, better Windows 10 integration, and accessibility improvements; ASP.NET benefited from updated hosting models.[66] | Active (support aligned with Windows OS lifecycle; no announced end date as of November 2025).[67] |
| 4.8 | April 18, 2019 | Focused on reliability with fixes for WPF and Windows Forms interop, improved High-DPI support, and accessibility enhancements; ASP.NET updates included better compatibility for legacy web apps without major new features.[15][66] | Active (support aligned with Windows OS lifecycle; no announced end date as of November 2025).[67] |
| 4.8.1 | August 9, 2022 | Minor update with security fixes, support for newer TLS protocols, and ARM64 enhancements; no significant new ASP.NET features, emphasizing maintenance for existing apps.[15] | Active (support aligned with Windows OS lifecycle; no announced end date as of November 2025).[67] |
ASP.NET Core Releases and Support
ASP.NET Core, as an integral part of the .NET platform, follows the annual release cadence established for .NET starting from version 5.0, with earlier .NET Core versions released on a similar schedule. The initial release, ASP.NET Core 1.0, arrived in June 2016 alongside .NET Core 1.0, introducing a modular, cross-platform framework for web development. Subsequent versions built incrementally: ASP.NET Core 2.0 in August 2017, 2.1 (LTS) in May 2018, and 2.2 in December 2018; then 3.0 in September 2019 and 3.1 (LTS) in December 2019. This progression continued with ASP.NET Core 5.0 in November 2020, 6.0 (LTS) in November 2021, 7.0 in November 2022, 8.0 (LTS) in November 2023, and 9.0 in November 2024.[21][24] Microsoft provides two support tiers for .NET releases, including ASP.NET Core: Long Term Support (LTS) versions receive three years of support, while Standard Term Support (STS) versions receive 18 months (or extended for alignment in some cases), with security updates and bug fixes during that period. For instance, .NET 8 LTS, which includes ASP.NET Core 8.0, is supported until November 10, 2026. .NET 9, an STS release incorporating ASP.NET Core 9.0, has support until November 10, 2026, aligning with the end of .NET 8 support to facilitate smoother transitions for developers.[21][76] As of 2025, ASP.NET Core 9.0 introduces enhancements focused on performance, security, and developer productivity, including expanded Native AOT (Ahead-of-Time) compilation support for minimal APIs and Razor Pages, which reduces startup times and memory usage in cloud-native scenarios. Improved monitoring tools, such as opt-out HTTP metrics for specific endpoints, enable better memory analysis and tracing without overhead in high-traffic applications. Additionally, new AI integration primitives, like extensions to TensorPrimitives for efficient math operations and interop with libraries such as ML.NET and ONNX Runtime, simplify embedding AI capabilities into web applications.[77][24][78] Upgrading between ASP.NET Core versions often involves addressing breaking changes to ensure compatibility, with Microsoft providing detailed migration guides. A notable example is the shift to endpoint routing in ASP.NET Core 3.0, which replaced the previous routing middleware and required updates to route configuration and link generation in MVC applications for better performance and extensibility. Subsequent upgrades, such as from 7.0 to 8.0, emphasize minimal disruptions through backward compatibility but may require adjustments for new defaults like enhanced JSON serialization.[79][80]| Version | Release Date | Support Type | End of Support |
|---|---|---|---|
| 1.0 | June 2016 | STS | June 2019 |
| 2.0 | August 2017 | STS | October 2018 |
| 2.1 | May 2018 | LTS | August 2021 |
| 2.2 | December 2018 | STS | December 2019 |
| 3.0 | September 2019 | STS | March 2020 |
| 3.1 | December 2019 | LTS | December 2022 |
| 5.0 | November 2020 | STS | May 2022 |
| 6.0 | November 2021 | LTS | November 2024 |
| 7.0 | November 2022 | STS | May 2024 |
| 8.0 | November 2023 | LTS | November 2026 |
| 9.0 | November 2024 | STS | November 2026 |