Loading AI tools
ASP.NET是由微软在.NET Framework框架中所提供，开发Web应用程式的类别库，封装在System.Web.dll档案中，显露出System.Web命名空间，并提供ASP.NET网页处理、扩充以及HTTP通道的应用程式与通讯处理等工作，以及Web Service的基础架构。ASP.NET是ASP技术的后继者，但它的发展性要比ASP技术要强大许多。
 | 此条目需要补充更多来源。 (2014年1月22日) |
ASP.NET可以运行在安装了.NET Framework的IIS伺服器上，若要在非微软的平台上执行，则需要使用Mono平台[1]，ASP.NET在2.0版本已经定型，在.NET Framework 3.5上则加上了许多功能，像是ASP.NET AJAX、ASP.NET MVC Framework、ASP.NET Dynamic Data与Microsoft Silverlight的伺服器控制项等。
很多人都把 ASP.NET 当做是一种程式语言，但它实际上只是一个由 .NET Framework 提供的一种开发平台 (development platform)，并非程式语言。也可认为ASP.NET是.NET组件，任何.NET语言，例如C#，可以引用该组件，创建网页或Web服务。
为了因应云端化所诱发的多作业平台整合与开发能力，微软特别开发一个新一代的 ASP.NET，称为 ASP.NET vNext，并于 2014 年命名为 ASP.NET 5，但随后于 2016 年将它更名为 ASP.NET Core，由于架构上的差异颇大，因此未来 ASP.NET 与 ASP.NET Core 将是分别发展与维护，Windows 平台的 ASP.NET 4.6 以上版本仍维持 Windows Only，但 ASP.NET Core 则是具有跨平台 (Windows, Mac OSX 与 Linux) 的能力。
ASP.NET的前身ASP技术，是在IIS 2.0上首次推出（Windows NT 3.51），当时与 ADO 1.0 一起推出，在IIS 3.0（Windows NT 4.0）发扬光大，成为伺服器端应用程式的热门开发工具，微软还特别为它量身打造了Visual InterDev开发工具，在1994年到2000年之间，ASP技术已经成为微软推展Windows NT 4.0平台的关键技术之一，数以万计的ASP网站也是这个时候开始如雨后春笋般的出现在网路上。由于它的简单以及高度客制化的能力，也是它能迅速窜起的原因之一。
不过ASP的缺点也逐渐的浮现出来：
- 义大利面型的程式开发方法，让维护的难度提高很多，尤其是大型的ASP应用程式。
- 直译式的VBScript或JScript语言，让效能有些许的受限。
- 延展性因为其基础架构扩充性不足而受限，虽然有COM元件可用，但开发一些特殊功能（像档案上传）时，没有来自内建的支援，需要寻求第三方软体商开发的元件。
1997年时，微软开始针对ASP的缺点（尤其是义大利面型的程式开发方法）准备开始一个新专案来开发，当时ASP.NET的主要领导人斯科特·格思里刚从杜克大学毕业，他和IIS团队的Mark Anders经理一起合作两个月，开发出了下一代ASP技术的原型，这个原型在1997年的圣诞节时被发展出来，并给予一个名称：XSP[2]，这个原型产品使用的是Java语言。不过它马上就被纳入当时还在开发中的CLR平台，Scott Guthrie事后也认为将这个技术移植到当时的CLR平台，确实有很大的风险（huge risk），但当时的XSP团队却是以CLR开发应用的第一个团队。
为了将XSP移植到CLR中，XSP团队将XSP的核心程式全部以C#语言重新撰写（在内部的专案代号是 "Project Cool"，但是当时对公开场合是保密的），并且改名为ASP+，作为ASP技术的后继者，并且也会提供一个简单的移转方法给ASP开发人员。ASP+首次的Beta版本以及应用在PDC 2000中亮相，由Bill Gates发表Keynote（即关键技术的概览），由富士通公司展示使用COBOL语言撰写ASP+应用程式，并且宣布它可以使用Visual Basic.NET、C#、Perl与Python语言（后两者由ActiveState公司开发的互通工具支援）来开发。
在2000年第二季时，微软正式推动.NET策略，ASP+也顺理成章的改名为ASP.NET，经过四年的开发，第一个版本的ASP.NET在2002年1月5日亮相（和.NET Framework 1.0），Scott Guthrie也成为ASP.NET的产品经理（到现在已经开发了数个微软产品，像ASP.NET AJAX和Microsoft Silverlight）。
ASP.NET 运行的架构分为几个阶段：
- 在 IIS 与 Web 伺服器中的讯息流动阶段。
- 在 ASP.NET 网页中的讯息分派。
- 在 ASP.NET 网页中的讯息处理。
当装载(hosting) ASP.NET 的 Web 伺服器接收到 HTTP 请求时，HTTP 聆听程式 (HTTP Listener，实际上是内核态的HTTP.SYS) 会将请求转交给 URL 指定的网站应用程式池中的工作者进程 (Worker Process)[3]，ASP.NET 的工作者进程接收到这个请求之后，装载专用于处理ASP.NET页面的一个ISAPI扩展“aspnet_isapi.dll”，并将HTTP请求传给它。若是 IIS 5.0 时则是 aspnet_wp.exe。
aspnet_isapi.dll负责加载ASP.NET应用程序的运行环境CLR（IIS 7集成模式下，CLR是预加载的），每个ASP.NET应用程序都运行于自己的应用程序域（AppDomain）中。每个应用程序域都对应着一个ApplicationManager类的实例（通过AppManagerAppDomainFactory创建），负责管理运行在域中的ASP.NET应用程序（启动和停止一个ASP.NET应用程序、创建对象等）。ApplicationManager还会创建一个HostingEnvironment对象，提供了ASP.NET应用程序的一些管理信息（如ASP.NET应用程序的标识、虚拟目录与对应的物理目录等）。
应用程序域创建完成之后，创建 System.Web.Hosting 命名空间中的基于ISAPIRuntime的一个对象，调用其ProcessRequest()方法。在此方法中，根据传入的HTTP请求信息屏蔽了版本差异化后封装实例化了一个HttpWorkerRequest的对象并初始化一个HttpRuntime对象。调用HttpRuntime的ProcessRequestInternal方法。ProcessRequestInternal方法实例化一个HttpContext对象（其构造函数内部又实例化了在ASP.NET编程中非常重要的HttpRequest和HttpResponse对象）、通过HttpApplicationFactory获取HttpApplication对象实例。再调用HttpApplication对象的BeginProcessRequest方法启动整个HTTP请求的处理过程（即HTTP管线模式）。
System.Web.UI.Page类提供了“Requset”和“Response”属性来引用这两个对象，因此在ASP.NET网页中可以直接访问这两个对象。同样，System.Web.UI.Page类的Context属性引用HttpContext对象。
HttpRuntime类的ProcessRequest()方法除了创建HttpContext对象之外，还完成了另一个很重要的工作——向HttpApplicationFactory类的一个实例（它管理一个HttpApplication对象池）申请分配一个HttpApplication对象用于管理整个“HTTP请求处理管线（HTTP Pipeline）”中的各种事件的激发。在HttpApplication对象的InitModules()方法中创建HTTP模块（HTTP Module），通常在HTTP模块对象（实现IHttpModule接口）的Init()方法中响应HttpApplication对象所激发的特定事件。开发者可以创建基于IHttpHandler接口的对象，在Web.Config中插入特定的内容可以将自定义的HTTP模块加入到HTTP请求的处理流程中。 在IIS6和IIS7经典模式下，是用 Event+事件名称做key将所有事件的保存在HttpApplication的Events属性对象里，然后在BuildSteps里统一按照顺序组装。在IIS7集成模式下，是通过HttpModule名称+RequestNotification枚举值作为key将所有的事件保存在HttpApplication的ModuleContainers属性对象里，这个属性的类型是PipelineModuleStepContainer[]。
“HTTP请求处理管线（HTTP Pipeline）”的处理过程为：
- 预处理阶段：由多个HTTP模块参与，通过事件来驱动，主要是对HttpContext对象的各种属性进行修改。
- 处理阶段：由System.Web.UI.Page类接手HttpContext对象。Page类实现了IHttpHandler接口，因此有ProcessRequest()方法并被自动调用。ProcessRequest()方法的执行结果刷新了HttpContext对象的内容。
- 后处理阶段：HttpApplication对象继续激发后继的事件。如果有特定的HTTP模块响应这些事件，则它们会被自动调用。在管线末端，信息传回到 ISAPIRuntime，以及 aspnet_isapi.dll，最后交由 HTTP Listener 回传给用户端。当HTTP请求处理完毕，相关的对象被释放，但创建的应用程序域，以及HttpApplication等对象仍然存活，以响应下一次HTTP请求。
具体的处理管线：
- BeginRequest: 开始处理请求。当ASP.NET运行时接收到新的HTTP请求的时候引发这个事件
- AuthenticateRequest授权验证请求，获取用户授权信息。当ASP.NET 运行时准备验证用户身份的时候引发这个事件
- PostAuthenticateRequest：验证身份成功。通过HttpContext.User获取
- AunthorizeRequest 用户权限授权。当ASP.NET运行时准备授权用户访问资源的时候引发这个事件
- PostAuthorizeRequest:获得授权
- ResolveRequestCache:获取页面缓存结果，如果存在直接返回结果
- PostResolveRequestCache 缓存检查结束
- MapRequestHandler：IIS7集成模式才支持
- 查找并创建HttpHandler：根据URL路径或扩展名和匹配规则查找创建，赋值给HttpContext.Handler属性（仅限于IIS6与IIS7经典模式）
- PostMapRequestHandler 成功创建IHttpHanlder对象
- AcquireRequestState 获取请求状态，一般用于获取Session：先判断当前页面对象是否实现了IRequiresSessionState接口，如果实现了，则从浏览器发来的请求报文体中获得SessionID,并到服务器的Session池中获得对应的Session对象，最后赋值给HttpContext的Session属性
- PostAcquireRequestState 成功获得Session
- PreRequestHandlerExecute:准备执行HttpHandler处理程序。
- 执行HttpHandler处理程序（仅限于IIS6与IIS7经典模式）：调用HttpHandler的ProcessRequest方法（同步）或BeginProcessRequest方法（异步）。
- PostRequestHandlerExecute 执行HttpHandler处理程序结束。
- ReleaseRequestState 准备释放请求状态（Session）
- PostReleaseRequestState 成功释放请求状态（Session）
- Filter：将内容写入Filter（仅限于IIS6与IIS7经典模式）
- UpdateRequestCache 更新缓存
- Filter：将内容写入Filter（仅限于IIS7集成模式）
- PostUpdateRequestCache 已更新缓存
- LogRequest 为当前请求执行日志记录（仅限于IIS7集成模式）
- PostLogRequest 已完成日志（仅限于IIS7集成模式）
- EndRequest 完成。把响应内容发送到客户端之前引发这个事件。
- Noop：扩展使用（仅限于IIS6与IIS7经典模式）
- PreSendRequestHeaders：根据发送的Headers动态设置一些参数（仅限于IIS7集成模式）
- PreSendRequestContent：可对输出内容做压缩（仅限于IIS7集成模式）
在 ASP.NET 内部的 HTTP 处理器有：
- ISAPIRuntime：由 aspnet_isapi.dll 呼叫，初始化 HttpWorkerRequest 物件（会由IIS的版本决定要初始化的版本）。
- HttpRuntime：提供请求伫列 (Request Queue)、呼叫 HttpWorkerRequest 中的 ProcessRequest() 方法，以及后续的处理工作。
- HttpWorkerRequest：产生 HttpApplication、HttpRequest、HttpResponse 等基础物件的 HTTP 请求物件，并将要求转送到要处理的物件（并呼叫它的 ProcessRequest() 方法）。
- IHttpHandler 与 IHttpAsyncHandler：负责处理 HTTP 请求的单元，由 ProcessRequest() 来分派与执行请求。
当 HttpWorkerRequest 呼叫 ASP.NET 网页（System.Web.UI 命名空间的 Page 类别）的 Page.ProcessRequest() 方法时，它会依序的引发 Page 内的各个事件，并同时呼叫在 Page 中所有控制项的相关事件，其引发顺序为[4]：
启动阶段：设置页面基本属性，如 Request 和 Response。在此阶段，页面还将确定请求是回发请求还是新请求，并设置 IsPostBack 属性。
- PreInit 事件：执行预先初始化的工作，在ASP.NET 2.0中，若要动态调整主版页面 (Master Page)、布景主题 (Theme) 时，要在这个事件中调整。设置页面一些最基本的特性，如加载个性化信息和主题、运行时Culture。
- Init 事件：执行初始化工作。根据页面的服务器标签及其属性设置，生成各个服务器控件的实例和给这些服务器控件的实例的属性进行赋值，并存入ViewState，但因为本阶段的赋值行为优先于ViewState的TrackViewState被调用，所以这些视图的值都将不会存入最终呈现的视图状态隐藏字段中。
- InitCompleted 事件：在完成初始化工作后引发。调用ViewState的TrackViewState方法，开启对视图状态更改的跟踪。
- Preload 事件：载入表单传值）。页面方法调用LoadViewState、LoadControlState、ProcessPostData，服务器控件对应调用LoadViewState和实现IPostBackDataHandler接口的LoadPostData方法
- Load 事件：执行载入的工作，大多数的网页都拥有 Page_Load 事件处理常式，使用者控制项 (user control) 中也有 Page_Load 事件常式，都会在此时呼叫。
- 控制项的 PostBack 变更通知：当网页侦测到是 PostBack 要求时，会引发 PostBack 讯息通知的事件。
- 控制项的 PostBack 相关事件：当网页侦测到是 PostBack 要求时，会引发 PostBack 讯息指定的控制项的事件。
- LoadCompleted 事件：执行载入完成后的工作。
- PreRender 事件：处理在产生 HTML 结果前的工作。
- SaveStateCompleted 事件：处理页面状态（ViewState 与 ControlState）储存完成后的事件。
- Render 事件：处理产生 HTML 的工作。
- Unload 事件：处理结束网页处理时的工作。
如果 HttpWorkerRequest 呼叫的是实作 IHttpHandler 介面的 HTTP 处理常式 时，它只会呼叫 IHttpHandler.ProcessRequest() 方法，由它来处理程式的输出，不像 Page.ProcessRequest() 会处理事件顺序，因此 HTTP Handler 很适合轻量级的资料处理，像是输出档案资料流或是图片资料流等。
ASP.NET 的原始设计构想，就是要让开发人员能够像 VB 开发工具那样，可以使用事件驱动式程式开发模式 (Event-Driven Programming Model) 的方法来开发网页与应用程式，若要以ASP技术来做到这件事的话，就必须要使用大量的辅助资讯，像是查询字串或是表单栏位资料来识别与判断物件的来源、事件流向以及呼叫的函式等等，需要撰写的程式码量相当的多，但 ASP.NET 很巧妙利用表单栏位和JavaScript指令码把事件的传递模型隐藏起来了。
ASP.NET 的事件模型是由 <form runat="server"></form> 以及数个 Hidden Field 组合而成，基于 HTTP 模型的限制，所有的网页程式在执行结果输出到用户端后，程式就会结束执行，为了维护在 ASP.NET 网页与控制项的状态资料，因此在输出 ASP.NET 控制项时，ASP.NET 会将部份状态资料储存到网页的 Hidden Field 中，这类型的状态资料称为 ViewState（ID 为 __VIEWSTATE），在伺服器端即会被解译出状态与事件资料。在大多数的内建 Web 控制项中都有使用到这个机制，因此在使用大量 ASP.NET Web 控制项的网页中，会有许多的 ViewState 会存放在网页中并随著 HTTP 资料流输出到用户端，ViewState 在输出时，会被加密为一组乱码字串，其金钥值定义在电脑中，并且每一个物件都会被序列化 (serialize) 成字串（因此若是自订物件要放到 ViewState 时，则应要让它支援序列化），再输出到 __VIEWSTATE 栏位中，在每次的网页来回时都会被传输，较大的 ViewState 会让网页大小膨胀，不利于快速的网路传输，不过 ASP.NET 本身有提供将 ViewState 关闭的功能，因此如果控制项不需要状态保存时，可将它关闭以减少输出的大小。
为确保控制项的事件能够确实被引发，让事件驱动能够被执行，因此控制项事件引发命令时需要的参数，是交由 JavaScript 指令码在用户端引发时，填入另一个 Hidden Field（ID 为 __EVENTTARGET 以及 __EVENTARGUMENT），并且引发表单的送出指示 (submit)，传送到伺服端后，伺服端的 HttpApplication 中的工具函式会解析 __EVENTTARGET 和 __EVENTARGUMENT 栏位中的资讯，并且交由控制项所实作的 RaisePostBackEvent() 来引发事件，并由 .NET Framework 内部的事件处理机制接手处理（呼叫控制项设定的事件处理常式）。
在 ASP.NET 运行的时候，经常会有网页的来回动作 (round-trip)，在 ASP.NET 中称为 PostBack，在传统的 ASP 技术上，判断网页的来回是需要由开发人员自行撰写，到了 ASP.NET 时，开发人员可以用 Page.IsPostBack 机能来判断是否为第一次执行（当 ASP.NET 发现 HTTP POST 要求的资料是空值时），它可以保证 ASP.NET 的控制项事件只会执行一次，但是它有个缺点（基于 HTTP POST 本身的缺陷），就是若使用者使用浏览器的重新整理功能（按 F5 或重新整理的按钮）刷新网页时，最后一次执行的事件会再被执行一次，若要避免这个状况，必须要强迫浏览器清空快取才可以。
ASP.NET 2.0 中有新增三个来回模式：
- Cross Page Postback：允许跨不同的网页执行 PostBack，伺服端可使用 Page.IsCrossPostBack 来判断是否是跨网页型的来回。
- Async Page Mode：允许网页使用非同步的方式执行，伺服端可用 Page.IsAsync 来判断。
- Callback：ASP.NET 2.0 新增的由网页回呼用户端指令的功能，伺服端可用 Page.IsCallback 来判断是否要求是来自 Callback。
来回模式不仅是 ASP.NET 运作时的核心，它也是 ASP.NET 应用程式的一个主要缺点，尤其是在设计复杂度高的页面时，在网页中隐藏的 ViewState 的大小会相当大，而在每次的来回动作中，都会传送 ViewState 在内的表单资讯，大量的 ViewState 会使得传送的时间拉长，而且每次来回动作都会让整个网页被刷新，而出现闪烁的情况（就算在本地端也一样），但在AJAX技术尚未成熟时，只能够忍受这种因底层限制所带来的问题，在ASP.NET AJAX技术发展出来后，透过UpdatePanel成功的缓解了这个问题（但 ViewState 传送的问题仍然未根本的解决，必须要使用像 Page Method 这样的方式才能彻底的解决）。
熟悉 ASP 技术的人都知道，程式码都是混在 HTML 标签之间，以输出预期需要的 HTML 指令，这个技术在 ASP.NET 中，由各控制项的绘制 (Render) 机制包装起来了，绘制机制装载了 HtmlTextWriter 物件，由它来产生 HTML 指令，它会输出至 HttpContext 的 Response 输出资料流中（即 ASP 技术的 Response.Write()），下列程式码为绘制技术的示例：
[System.Security.Permissions.PermissionSet(System.Security.Permissions.SecurityAction.Demand, Name="FullTrust")]
protected override void Render(HtmlTextWriter output)
{
if ( (HasControls()) && (Controls[0] is LiteralControl) )
{
output.Write("<H2>Your Message: " + ((LiteralControl) Controls[0]).Text + "</H2>");
}
}
为了让控制项的输出有阶层性，ASP.NET 开发了一个可以阶层化输出控制项 HTML 指令的方式，称为控制项树 (Control Tree)，借由控制项树，可以让各个控制项的输出可以阶层化，不论是否是收纳型控制项，还是一般型的控制项，都可以按照控制项的顺序来输出。
状态管理 (state management) 在Web应用程式中，一向是很重要的课题，良好的状态管理可以帮助开发人员发展出具有状态持续能力的应用程式（像是工作流程型应用程式或是电子商务应用程式），但状态管理功能会视应用程式的部署状态以及资讯的共用程度来选择，在 ASP.NET 中，分为伺服器端状态管理以及用户端状态管理，用户端状态管理为ViewState以及Cookies，伺服端状态管理则是Session与Application物件。它们的差异点在于：
- ViewState 是加密的资料流，和 HTML 一起输出到用户端。
- Cookies 是加密（也可不加密）的小型资料，和 HTML 不同，它可以快取在用户端浏览器中。
- Session 是伺服器端的状态保存机制，每个用户端均有独立的空间（以浏览器执行个体来赋与唯一的SessionID值）。
- Application 是伺服器端的状态保存机制，但应用程式所有的用户端共用同一份状态资料。
Application 物件会在应用程式的 Application_OnStart 事件中初始化，并使用名称来识别资料（它是一个 NameObjectCollectionBase 集合的实作品），它会储存在应用程式的范围内，所有的连线（使用者）都可以使用，属于共用型的储存体，适合储存所有使用者都可使用的资料，在多人使用的情况下，可以适当的使用 Lock/Unlock 的机制来确保应用程式状态的更新。
Application.Lock();
Application["PageRequestCount"] =
((int)Application["PageRequestCount"])+1;
Application.UnLock();
连线层级的物件是 Session，以浏览器的执行个体为识别单位，资料依浏览器的执行个体来储存，在浏览器的执行个体第一次连到应用程式时，ASP.NET会设定一个Session ID，并且使用它来识别 Session，每一个 Session 都是 ICollection 与 IEnumerate 的实作，用 key 来识别资料值，并且具有时间的限制 (timeout)，若超出时限时伺服器会自动清理掉，预设的 Session 时限为 20 分钟。Session ID 的演算法是由 RNGCryptoServiceProvider（密码编译乱数产生器提供者）产生，并编码成一个 Session ID 字串（例如 anf4vuup3xiq0arjlqla2l55 这样的字串）储存在伺服器中，用以识别不同的 Session 个体。
为因应不同的用户端，ASP.NET 设计了不同的 Session ID 存放机制，像是旧式的浏览器或是行动用户端这种不支援本地储存cookie的装置时，ASP.NET 可以直接在 URL 中加上 Session ID 的识别，像是 http://www.example.org/(anf4vuup3xiq0arjlqla2l55)/profile.aspx 这样的 URL，可以由开发人员自行设定，或是使用 AutoDetect 设定来让 ASP.NET 自行判断要使用的 Session ID 存放方式。
Session ID 的产生方法可以由程式开发人员自订，借由覆写 SessionIDManager 的 CreateSessionID() 方法来自订。
using System;
using System.Configuration;
using System.Web.Configuration;
using System.Web;
using System.Web.SessionState;
namespace Samples.AspNet.Session
{
public class GuidSessionIDManager : SessionIDManager
{
public override string CreateSessionID(HttpContext context)
{
return Guid.NewGuid().ToString();
}
public override bool Validate(string id)
{
try
{
Guid testGuid = new Guid(id);
if (id == testGuid.ToString())
return true;
}
catch
{
}
return false;
}
}
}
状态管理在单一伺服器上，可以储存在伺服器的记忆体中，但若是在大型网站中，使用许多的 Web 伺服器来实行负载平衡（Load Balancing）处理时，会有状态储存在哪个位置的问题，因此需要有一个可以在每个 Web 伺服器之间做状态储存的媒介，像是独立的伺服器或是资料库等等。在 ASP.NET 中支援了四种状态储存的媒介[5]：
- InProc：储存与 ASP.NET 相同的执行行程中 (in-procedure state)，适合单一伺服器的状态储存。
- StateServer：储存在 ASP.NET 状态伺服器 (state server) 中，适合跨伺服器的状态储存，但因为它使用的通讯埠，因此在使用上需要注意防火墙的问题。
- SQLServer：储存在独立的 SQL Server 资料库中，适合跨伺服器的状态储存。
- Custom：以自行实作的状态提供者 (state provider)。
ASP.NET 是开发 Web 应用程式的基础架构 (framework)，除了它内部的运作方法外，对外也显露了许多的开发支援，让开发人员可以利用它来发展出许多强大的 Web 应用程式解决方案。
ASP.NET 最基础的底层为网页 (Page)，网页由 System.Web.UI.Page 类别来提供基础支援，包含了页面的事件以及物件绘制的引发点（Page 类别本身是一个 HTTP Handler 的实作品）。ASP.NET 网页在微软的官方名称中，称为 Web Form，除了是要和Windows Forms作分别以外，同时也明白的刻划出了它的主要功能：“让开发人员能够像开发 Windows Forms 一样的方法来发展 Web 网页”。因此 ASP.NET Page 所要提供的功能就需要类似 Windows Forms 的表单，每个 Web Form 都要有一个 <form runat="server"></form> 区块，所有的 ASP.NET 伺服器控制项都要放在这个区域中，这样才可以让 ViewState 等伺服器控制能够顺畅的运作。
在网页中也可以使用程式码，以类似于ASP时代的撰写方式来开发，此种开发方式称为 inline code，在 ASP.NET 的程式开发模式中，inline code ，要放在 <script runat="server"></script> 区域中，如下列的范例程式：
<%@ Page Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<script runat="server">
protected void Page_Load(object sender, EventArgs e)
{
Label1.Text = DateTime.Now.ToLongDateString();
}
</script>
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>Sample page</title>
</head>
<body>
<form id="form1" runat="server">
<div>
The current time is: <asp:Label runat="server" id="Label1" />
</div>
</form>
</body>
</html>
另一种模式则是将程式码和网页分离，这种模式称为程式码后置 (Code-Behind)，这个方法可以将程式码独立到一个档案中，网页可以保持较干净的状态，让维护网页程式的复杂度降低很多，在网页的提示指令 (directive) 中，可以设定程式码后置的参数，像是 Inherit、CodeFile、Class 等参数。
<%@ Page Language="C#" CodeFile="SampleCodeBehind.aspx.cs" Inherits="Website.SampleCodeBehind"
AutoEventWireup="true" %>
而一个典型的程式码后置例子为：
using System;
namespace Website
{
public partial class SampleCodeBehind : System.Web.UI.Page
{
protected override void Page_Load(EventArgs e)
{
base.OnLoad(e);
}
}
}
使用程式码后置模式的设定时，可以让 ASP.NET 执行引擎在载入网页时，由程式码后置参数取得对应的类别资讯，藉以使用 Reflection 的方式来执行后置的程式码。
ASP.NET 可以支援HTML和XHTML两种网页内容，但在Visual Studio.NET中，预设是使用 HTML，但在Visual Studio 2005以后的版本，则一律都改用XHTML格式。
ASP.NET 的内建控制项分为两种：
- HTML 控制项 (HTML control)：直接在 HTML 标记中加上 runat="server"，即可对应到 ASP.NET 指定的 HTML 伺服器控制项类别，像是：
- HtmlAnchor：表示 HTML 的 <a>。
- HtmlButton：表示 HTML 的 <input type="button">。
- HtmlImage：表示 HTML 的 <img>。
- HtmlGenericControl：表示没有对应到伺服器控制项的物件，都会被对应到这个类别。
- Web 控制项 (Web control)：由 ASP.NET 提供，比 HTML 控制项提供更多的功能，但操作与设定会比 HTML 控制项要复杂许多，像是：
- LinkButton：一种外型为连结 (<a>) 的按钮。
- CheckBoxList：建立 CheckBox 的清单的控制项。
- GridView：将资料系结并产生 HTML 表格的控制项。
- RequiredFieldValidator：检查栏位是否有输入资料的控制项。
除了内建的控制项之外，ASP.NET 也提供了可以自订的控制项架构，并且支援两种控制项开发方法：
- 使用者控制项 (User control)，以 .ascx 为副档名，可以让开发人员用最轻松的方式来开发控制项，优点是开发速度很快，但缺点是无法转散布，且无法加入参考。
- 自订控制项 (Custom control)，可转散布型的控制项，是经过编译后的程式码 (DLL)，可单独转散布，并且可在其他的专案加入参考取用，自订控制项有三种开发模式：
- 基础控制项 (General Control)：由 System.Web.UI.Control 类别继承而来，或是由现有的 Web 控制项继承而来，像是由 Button 控制项继承。
- 复合控制项 (Composite Control)：由 System.Web.UI.WebControls.CompositeControl 继承而来，可以用复合的方式来开发控制项。
- 样板控制项 (Template Control)：可以在控制项中使用样板 (template)，并套用资料到样板中，支援资料系结的运算式。
ASP.NET 的 Web 控制项有时会包装一些用户端指令码 (client-side scripting)，在控制项被绘制时输出到用户端，这些指令码多数被包装在 DLL 的资源档中，并由 ScriptResource.axd 处理常式来输出，开发人员也可以利用 ClientScriptManager（Page.ClientScript 属性）中的方法来添加指令码到网页程式中，常用的方法有：
- ClientScriptManager.RegisterClientScriptBlock()：注册用户端指令码区块 (script block)。
- ClientScriptManager.RegisterStartupScript()：注册在起始时执行的指令码。
- ClientScriptManager.RegisterOnSubmitStatement()：注册在处理表单发送时要执行的指令码。
- ClientScriptManager.RegisterClientScriptInclude()：注册由外部档案 (.js) 提供的指令码来源。
以往在 ASP 中常被使用的五大基本物件，在 ASP.NET 中仍然持续被支援，但它们都换了一个身份来提供：
- Application：包装了 HttpApplication 物件，在程式中使用 Application 指令取得的物件，都是来自于 HttpContext.Current.Application 属性回传而得。
- Request：包装了 HttpRequest 物件，在程式中使用 Request 指令取得的物件，都是来自于 HttpContext.Current.Request 属性回传而得。
- Response：包装了 HttpResponse 物件，在程式中使用 Response 指令取得的物件，都是来自于 HttpContext.Current.Response 属性回传而得。
- Session：包装了 HttpSessionState 物件，在程式中使用 Session 指令取得的物件，都是来自于 HttpContext.Current.Session 属性回传而得。
- Server：包装了 HttpServerUtility 物件，在程式中使用 Server 指令取得的物件，都是来自于 HttpContext.Current.Server 属性回传而得。
导览部件 (navigation controls)[6] 是在 ASP.NET 2.0 中才出现的功能，包含：
- 选单 (Menu)：提供内建的滑鼠侦测方式，实作阶层式的选单功能。
- 网站地图 (Sitemap)：提供可层次化目前浏览位置的功能，可支援由 Web.sitemap 中的资料，或是来自资料库或 XML 资料档中的资料来源。
- 树状检视 (TreeView)：提供阶层化的资料浏览，类似于档案总管的介面。
应用程式服务 (application services) 是在 ASP.NET 2.0 中才开始提供，它以 Provider-based Pattern 为主，实作出数个网站的常用服务，包含会员服务 (Membership Service)[7]、角色服务 (role service)[8]与设定档服务 (profile service)[9] 等。
会员服务由 Membership 以及其资料提供者 MembershipProvider 构成，应用程式使用 Membership 所显露的方法来操作，它会将要求转送给指定的 MembershipProvider 实作来处理，ASP.NET 目前支援来自于资料库的 SqlMembershipProvider（支援 SQL Server）以及来自于Active Directory的 ActiveDirectoryMembershipProvider，开发人员也可以自行由 MembershipProvider 继承来实作自订的会员服务资料提供者。
角色服务与会员服务类似，由 Role 以及其资料提供者 RoleProvider 构成，应用程式使用 Role 所显露的方法操作，由 RoleProvider 实作提供资料服务，目前内建的 RoleProvider 有来自 Active Directory 或 XML 档案的 AuthorizationStoreRoleProvider，由 SQL Server 供应资料的 SqlRoleProvider，以及支援 Windows 角色的 WindowsTokenRoleProvider 三种，开发人员可自行实作 RoleProvider 的方法以发展出自订的角色服务提供者。
设定档服务是一个特殊的服务，它结合了 .NET Framework 的 CodeDOM 开发模式，以及 System.Web.Profile 命名空间的 ProfileBase、ProfileInfo 与 ProfileManager 等类别，组合出完整的设定档支援，其资料来源也是以 Provider-based Pattern 为主，由 ProfileProvider 提供，ASP.NET 内建由 SQL Server 资料库建立的 SqlProfileProvider，其栏位系由开发人员在 ASP.NET 组态档中自行定义，再由 ASP.NET 动态产生强型别的栏位属性。
设定档服务也是作为 ASP.NET 2.0 的网页组件 (Web Part Framework) 所需要的设定档储存支援[10]，Web Part Framework 可以让开发人员可以开发出具备个人化能力 (Personalization) 的网页配置方案，让使用者可以用自行新增与拖放的方式来设计自己的网页布置，所需要的设定储存即由设定档服务处理。
另一个需要和应用程式服务配合使用的功能为 Web 事件架构 (Web Event Framework)[11]，它需要由应用程式服务提供资料结构，它也有 Provider-based Pattern，并可以支援数种的事件资料提供者。
除了 ASP.NET 网页以外，.NET Framework 还提供了两种可以由开发人员自行发展处理模型的模组，一种是HTTP Handler，另一种则是HTTP Module[12]。
HTTP Handler（副档名为 .ashx）由 System.Web.IHttpHandler 介面定义了必要的方法（可支援非同步的 HTTP Handler 称为 HTTP Async Handler，由 System.Web.IHttpAsyncHandler 介面定义），其中最重要的方法是 ProcessRequest() 方法，开发人员必须要实作这个方法，才能够让 HTTP Handler 有作用，它也可以透过 ASP.NET 的组态设定，让 HTTP Handler 可以处理特定的副档名，它可以被视为 .NET Framework 中的 ISAPI Extensions 实作方法。
HTTP Module 则是由 System.Web.IHttpModule 介面定义，它可以在整个网页生命周期中被呼叫多次，并实际处理由 HttpApplication 所引发的事件，开发人员需要实作 IHttpModule.Init() 方法，以及处理 HttpApplication 事件需要的程式码。它可被视为 .NET Framework 中的 ISAPI Filter 实作方法。
ASP.NET 在一开始的时候是缺乏范本引擎 (template engine) 的，其主因是.NET Framework本身是物件导向，且需要用继承的方式才能够延伸功能，大多数的开发人员都是由 System.Web.UI.Page 继承并定义出新的基础类别，并撰写要绘制 HTML 的方法，以及在他们的应用程式中修改以继承该类别，然而这个方法可能会被用在网站的很多地方，因而会大大的提升混合程式码与标记的复杂度，这个方法也只能在执行期才能够以视觉化的方式测试，无法在设计时期视觉化，其他的开发人员总是使用原有的 ASP 方法（即<!-- #include --> 指令）来把每个网页需要的部份包到网页中，防止在每个网页中都要撰写相同的导览程式码。
在 ASP.NET 2.0 中，推出了母板页面 (master page)的概念[13]，它可以让开发人员先行定义外观版型 (*.master)，再使用它来套用实际执行的网页，网页与主版页面之间以 ContentPlaceHolder 的 ID 做连结，以套用正确的内容到保留区（即由 ContentPlaceHolder 包住的区域）中，开发人员也可以定义在保留区没有套用时需要显示的预设内容。在 ASP.NET 3.5 中更进一步的支援设计时期的巢状主版页面 (nested master pages)，以及把网页的 HEAD 区块纳入 ContentPlaceHolder 的范围。
与主版页面相关的，还有主题(Theme)以及面板(skin)技术[14]，这两个技术允许开发人员或设计人员自行定义网页的样式设定以及套用的样式支援，每个主题中可以包含数个面板档，这些面板档决定了控制项要输出时套用的样式，开发人员则可以利用主题来决定不同的外观要使用的样式。
ASP.NET 也允许在应用程式中动态的变更主版页面与主题，但必须要在页面的 PreInit 事件常式设定。
void Page_PreInit(Object sender, EventArgs e)
{
Page.MasterPageFile = "~/NewMaster.master";
Page.Theme = "MyTheme";
}
ASP.NET 在 1.x 时，使用的是组件为主的编译方式，一个网页只会产生一个组件，这个方式最大的优点，就是可以自由定义命名空间，且在部署应用程式时会比较方便，但由于 ASP.NET 1.x 所处的时代，如果网站是有许多程式码的情况下（即 DLL 档很大），载入的速度会变慢，且占用记忆体的量会很多，当时的记忆体价格也尚未降到现在的水准。因此在 ASP.NET 2.0 开始，另外提供了一个预先编译(Pre-compilation) 的编译模型，这个编译方法会将每个网页都各自编译成一个组件，其档案名称会是 App_[乱数字串].dll 命名，在编译时期由 ASP.NET Pre-compilation 工具（aspnet_compiler.exe）给定，优点是可以不必载入过量的程式码到记忆体中，但缺点则是无法自订命名空间，而且在更新时必须要更新所有的 DLL 档以及网页等，否则会造成名称不一致，让 DLL 无法被载入的问题。
早期 ASP.NET 2.0 仅提供预先编译模式，让它的缺点很快的被暴露出来，因此微软也为 ASP.NET 2.0 开发了沿用 ASP.NET 1.x 的编译模型的工具：Web Application Project，在 Visual Studio 2008 中开始内建，至此，ASP.NET 支援两种编译模式的架构抵定。
ASP.NET 的安全性支援分为验证 (Authentication)与授权 (Authorization)两个部份。
ASP.NET 的验证方式有三种[15]：
- Windows 验证：由 IIS 目前执行的帐户，或者是使用者模拟 (user impersonate) 帐户的方式进行验证。
- 表单验证：由表单的资料提供验证，开发人员自订验证逻辑，并交由 ASP.NET 表单验证工具写入验证凭证，以进行授权。
- Passport 验证：在 ASP.NET 1.x 中，连接Windows Live ID（当时的旧称为Microsoft Passport）服务以进行验证。
ASP.NET 的授权方式有两种[16]：
- 档案授权：由 ASP.NET 检查档案的 存取控制表 (ACL) 来授权存取权限。
- URL授权：由开发人员设定的 URL 来给予权限。
一个 URL 授权的设定范例如下：
<authorization>
<allow users="Kim"/>
<allow roles="Admins"/>
<deny users="John"/>
<deny users="?"/>
</authorization>
ASP.NET 1.0 开始支援 Web Service 的开发，是微软在原生平台上支援 Web Service 发展的第一个实作品，但它却不是微软的第一个 Web Service 开发工具实作品[17]，.NET Framework 中提供了一个 WSDL.exe，可以连接 Web Service 下载WSDL定义档，并产生一个 Proxy Class 的原始码，供用户端应用程式使用，若是使用 Visual Studio 开发的话，这个动作会由“加入 Web 参考”的动作在背后处理掉。
ASP.NET Web Service 的发展只是平台的基础，微软在 Web Service 的开发上提供持续的支援，尤其是在 WS-I (Web Service Interoperability) 组织成立后，为符合 WS-I 的 Web Service 标准，微软开发了强化 Web Service 的增强套件 Web Service Enhancement (WSE)，最新版本为 3.0 版（搭配 ASP.NET 2.0），可支援许多 WS-I 的标准。
由于 Windows Communication Foundation 的推出，微软将 Web Service 的发展重心移到 WCF 上，原有的 ASP.NET Web Service 即给定了一个名称：ASMX Web Service。
ASP.NET 在 2.0 版时，功能已大致底定，成为 Web 应用程式的基础架构，微软开始在 ASP.NET 2.0 上开发扩充的功能，包括 AJAX 的支援、MVC架构的支援以及更容易开发出资料库应用的架构。
ASP.NET AJAX 是微软发展的 AJAX Framework，让 ASP.NET 的开发人员得以用很简单的方式就可以开发出支援 AJAX (AJAX-enabled) 的应用程式，包含用户端指令码的支援，以及伺服器端的连结等等。
ASP.NET MVC Framework 是微软基于 MVC (Model-View-Controller) 架构所开发的架构，让应用程式各个模型可以在 MVC 架构下运行。
- View：负责显示资料以及使用者介面，在 ASP.NET MVC 架构下，View 可以支援 REST 样式的 URL。
- Model：负责定义资料的储存，此部份可以由 LINQ to SQL 与 ADO.NET Entity Framework 来代替。
- Controller：负责处理 View 和 Model 之间的联系。
ASP.NET MVC Framework 也支援以测试驱动的开发模式 (Test-Driven Development)。
ASP.NET Dynamic Data Framework 是微软在 ASP.NET 3.5 中开发的一组类别库，封装在 System.Web.DynamicData 命名空间中，并且配合 ASP.NET Routing Model（网页绕送功能）让开发人员可以很简单的开发出基于 LINQ to SQL 或是 ADO.NET Entity Framework 资料模型的资料库应用程式。
ASP.NET Routing Model（官方译名为 ASP.NET 路由）是一个基于REST规格下的 URL 对应机制，开发人员可以在伺服器端设定 URL 的格式，使用者可以用由开发人员定义的 URL 格式浏览网页，ASP.NET 会自动将 URL 转换成为内部的 URL 格式，虽然它和 URL Rewriting 很像，但微软认为 ASP.NET Routing 不是 URL Rewriting[18]。
Silverlight 是微软的新一代RIA技术，ASP.NET 3.5 Service Pack 1 (SP1) 中加入了对 Silverlight 2.0 的 ASP.NET 伺服器端支援，包含：
- Silverlight控制项：让伺服器端可以产生支援 Silverlight 的物件标记，以及自订参数等。
- Media控制项：让伺服器端输出以 Silverlight 为主的串流影音 (streaming media) 播放器。
目前已有数个工具可支援 ASP.NET 应用程式的开发。
- Visual Web Developer 2008 Express Edition（免费）或 Visual Studio 2008 (ASP.NET 2.0/3.5)[19]
- Visual Web Developer 2005 Express Edition（免费）或 Visual Studio 2005 (ASP.NET 2.0)
- Visual Studio .NET (ASP.NET 1.x)
- Delphi 2006
- Macromedia HomeSite 5.5 (For ASP Tags)
- Microsoft Expression Web，Microsoft Expression Studio 工具集的一部份
- Microsoft SharePoint Designer
- MonoDevelop（免费／开放原始码）
- SharpDevelop（免费／开放原始码）
- Eiffel for ASP.NET （免费）
- WebMatrix 3（免费）
- Adobe Dreamweaver CC。
在一台计算机上，查看Windows注册表的
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full
其Version节点显示的就是所安装的ASP.NET的版本号。
| 日期 | 版本 | 说明 | 新功能 |
|---|---|---|---|
| 2002年1月16日 | 1.0 | 与Visual Studio .NET一起发行的第一个版本 | |
| 2003年4月24日 | 1.1 | 与Windows Server 2003和Visual Studio .NET 2003一起发表。 |
|
| 2005年11月7日 | 2.0 |
研发代号为Whidbey，和Visual Studio 2005、Visual Web Developer Express与SQL Server 2005一起发表。 |
|
| 2007年11月19日 | 3.5 | 与Visual Studio 2008和Windows Server 2008一起发表 |
|
| 2008年8月11日 | 3.5 Service Pack 1[20] | 于 Visual Studio 2008 Service Pack 1 发表 |
|
| 2010年4月12日 | 4.0 | 与Visual Studio 2010一起发表 |
|
| 2012年8月15日 | 4.5 | 与Visual Studio 2012一起发表 | |
| 2013年10月17日 | 4.5.1 | Visual Studio 2013[21]发布用于Windows Server 2012 R2与Windows 8.1 | |
| 2014年5月5日[22] | 4.5.2 |
| |
| 2015年7月29日[22] | 4.6 | 发布于[23]Visual Studio 2015[24]与EF 7预览版用于Windows Server 2016与Windows 10 |
|
| 2015年11月30日[22] | 4.6.1 | ||
| 2016年8月2日[22] | 4.6.2 |
| |
| 2017年4月11日[22] | 4.7 | 包含在Windows 10 Creators Update[25] |
|
| 2017年10月17日[22] | 4.7.1 | 包含在Windows 10 Fall Creators Update.[26] |
|
| 2018年5月1日[27] | 4.7.2 | ||
| 2019年4月18日[28] | 4.8 | 包含在 Windows 10 May 2019 Update | 修复了ASP.NET的10个bugs |
| 2015年11月18日 | 5 RC1 | 这一版本后来从ASP.NET分开，改称ASP.NET Core 1.0.[29] | 一个全新项目有不同的开发原则与目标。 |
格式： 旧版本 旧版本，仍被支援 当前版本 最新的预览版 未来版本 | |||
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
