aspnetwebform版本

Ⅰ ASP.NET Web Page應用深入探討

一 伺服器腳本基礎介紹

首先 我們先復習一下Web伺服器頁面的基本執行方式

客戶端通過在瀏覽器的地址欄敲入地址來發送請求到伺服器端

伺服器接收到請求之後 發給相應的伺服器端頁面（也就是腳本）來執行 腳本產生客戶端的響應 發送回客戶端

客戶端瀏覽器接收到伺服器傳回的響應 對Html進行解析 將圖形化的網頁呈現在用戶面前

對於伺服器和客戶端的交互 通常通過下面幾種主要方式

Form 這是最主要的方式 標准化的控制項來獲取用戶的輸入 Form的提交將數據發送給伺服器端處理

QueryString 通過在Url後面帶參數達到將參數傳送給伺服器 這種方式其實跟Get方式的Form是一樣的

Cookies 這是一種比較特殊的方式 通常用於用戶身份的確認

二 ASP Net簡介

傳統的伺服器腳本語言 如ASP JSP等 編寫伺服器腳本的方式大同小異 都是在Html中嵌入解釋或編譯執行的代碼 由伺服器平台執行這些代碼來生成Html 對於這類似的腳本 頁面的生存周期實際上很簡單 就是從開頭至末尾 執行完所有的代碼 當然用Java編寫的Servlet可以編寫更復雜的代碼 但是從結構上看 和JSP沒什麼區別

ASP Net的出現 打破了這種傳統 ASP Net採用了CodeBehind技術和伺服器端控制項 加入了伺服器端的事件的概念 改變了腳本語言編寫的模式 更加貼近Window編程 使Web編程更加簡單 直觀 但是我們要看到 ASP Net本身並沒有改變Web編程的基本模式 只是封裝了一些細節 提供了一些易用的功能 使代碼更容易編寫和維護 從某種程度上來說 將伺服器端執行的方式復雜化了 這就是我們今天要討論的主體 ASP Net Web Page的生存周期

三 ASP Net請求處理模式

我們說 ASP Net的Web Page並沒有脫離Web編程的模式 所以它仍然是以 請求 >接收請求 >處理請求 >發送響應 這樣的模式在工作 每一次與客戶端的交互都會引發一次新的請求 所以一個Web Page的生命周期是以一次請求為基礎的

當IIS收到客戶端的請求的時候 會將請求交給aspnet_wp這個進程來處理 這個進程會查看請求的應用程序域是否存在 如果不存在則會創建一個 然後會創建一個Http運行時（HttpRuntime）來處理請求 這個運行時 為當前應用程序提供一組 ASP NET 運行時服務 （摘自MSDN）

HttpRuntime在處理請求的時候 會維護一系列的應用程序實例 也就是應用程序的Global類（global asax）的實例 這些實例在沒有請求的時候 會存放在一個應用程序池中（實際上應用程序池由另一個類來維護 HttpRuntime只是簡單的調用） 每接收到一個請求 HttpRuntime都會獲取一個閑置的實例來處理請求 這個實例在請求結束前不會處理其他的請求 處理完畢之後 它又會回到池中 一個實例在其生存期內被用於處理多個請求 但它一次只能處理一個請求 （摘自MSDN）

當應用程序實例處理請求的時候 它會創建請求頁面類的實例 執行它的ProcessRequest方法來處理請求 這個方法也就是Web Page生命周期的開始

四 Aspx頁面與CodeBehind

在深入了解頁面的生命周期之前 我們先來探討一些Aspx與CodeBehind之間的關系

<%@ Page language= c# Codebehind= WebForm aspx cs Inherits= MyNamespace WebForm %>

相信使用過CodeBehind技術的朋友 對ASPX頂部的這句話應該是非常熟悉了 我們來一項一項的分析它

Page language= c# 這個就不用多說了吧

Codebehind= WebForm aspx cs 這一句表示綁定的代碼文件

Inherits= MyNamespace WebForm 這句非常重要 它表示頁面繼承的類名稱 也就是CodeBehind的代碼文件中的類 這個類必須從System Web WebControls Page派生

從上面我們可以分析出 實際上CodeBehind中的類就是頁面（ASPX）的基類 到這里 可能有些朋友要問了 在編寫ASPX的時候 完全是按照ASP的方式 在Html中嵌入代碼或者嵌入伺服器控制項 沒有看到所謂 類 的影子啊？

這個問題實際上並不復雜 各位使用ASP Net編程的朋友可以到你們的系統盤 WINDOWSMicrosoft NETFramework<版本號>Temporary ASP NET Files這個目錄下 這個下面就放了所有本機上存在的ASP Net應用程序的臨時文件 子目錄的名稱就是應用程序的名稱 然後再下去兩層（為了保證唯一 ASP Net自動產生了兩層子目錄 並且子目錄名稱是隨機的） 然後我們會發現有很多類似 yfy gjhc dll xeunj u dll 這樣的鏈接庫以及 komee bp cs falckav cs 這樣的源文件 實際上這就是ASPX被ASP Net動態編譯後的結果 打開這些源文件我們可以發現

public class WebForm_aspx MyNamespace WebForm System Web SessionState IRequiresSessionState

這就印證了我們前面的說法 ASPX是代碼綁定類的子類 它的名稱是ASPX文件名加上 _aspx 後綴 通過研究這些代碼我們可以發現 實際上所有aspx中定義的伺服器控制項都是在這些代碼中生成的 然後動態產生這些代碼的時候 把原來在ASPX中嵌入的代碼寫在了相應的位置

當某個頁面第一次被訪問的時候 Http運行時就會使用一個代碼生成器去解析ASPX文件並生成源代碼並編譯 然後以後的訪問就直接調用編譯後的dll 這也是為什麼ASPX第一次訪問的時候非常慢的原因

解釋了這個問題 我們再來看另一個問題 我們在使用代碼綁定的時候 在設計頁面拖一個控制項 然後切換到代碼視圖 就可以直接在Page_Load中使用這個控制項了 既然控制項是在子類中產生的 那為什麼在父類中可以直接使用呢？

實際上我們可以發現 每當用VS Net拖一個控制項到頁面上 代碼綁定文件中總是會類似這樣的添加一個聲明

protected System Web WebControls Button Button

我們可以發現這個欄位被聲明成protected 而且名字與ASPX中控制項的ID一致 仔細想一想 這個問題就迎刃而解了 我們前面提到ASPX的源代碼是被生成器動態生成和編譯的 生成器會產生動態生成每一個伺服器控制項的代碼 在生成的時候 它會檢查父類有沒有聲明這個控制項 如果聲明了 它會添加類似下面的一句代碼

this DataGrid = __ctrl

這個__ctrl就是生成該控制項的變數 這時候它就把控制項的引用賦給了父類中相應的變數 這也是為什麼父類中的聲明必須為protected（實際上也可以為public） 因為要保證子類能夠調用

然後在執行Page_Load的時候 因為這時候父類的聲明已經被子類中的初始化代碼賦了值 所以我們就可以使用這個欄位來訪問對應的控制項 了解了這些 我們就不會犯在代碼綁定文件中的構造器里使用控制項 造成空引用的異常的錯誤了 因為構造器是最先執行的 這時候子類的初始化還沒有開始 所以父類中的欄位是空值 至於子類是什麼時候初始化我們放到後面討論

五 頁面生存周期

現在回到第三個標題中講到的內容 我們講到了HttpApplication的實例接收請求 並創建頁面類的實例 實際上這個實例也就是動態編譯的ASPX的類的一個實例 上一個標題中我們了解到ASPX實際上是代碼綁定中類的子類 所以它繼承了所有的protected方法

現在我們來看看VS Net自動生成的CodeBehind類的代碼 以此來開始我們對頁面生命周期的探討

#region Web Form Designer generated code

override protected void OnInit（EventArgs e）

{ // // CODEGEN 該調用是 ASP NET Web 窗體設計器所必需的

// InitializeComponent（） base OnInit（e） }

/// <summary> /// 設計器支持所需的方法 不要使用代碼編輯器修改/// 此方法的內容

/// </summary>

private void InitializeComponent（）

{ this DataGrid ItemDataBound += new System Web UI WebControls DataGridItemEventHandler（this DataGrid _ItemDataBound）

this Load += new System EventHandler（this Page_Load） }

#endregion

這個就是使用VS Net產生的Page的代碼 我們來看 這裡面有兩個方法 一個是OnInit 一個是InitializeComponent 後者被前者調用 實際上這就是頁面初始化的開始 在InitializeComponent中我們看到了控制項的事件聲明和Page的Load聲明

下面是從MSDN中摘錄的一段描述和一個頁面生命周期方法和事件觸發的順序表

每次請求 ASP NET 頁時 伺服器就會載入一個 ASP NET 頁 並在請求完成時卸載該頁 頁及其包含的伺服器控制項負責執行請求並將 HTML 呈現給客戶端 雖然客戶端和伺服器之間的通訊是無狀態的和斷續的 但是必須使客戶感覺到這是一個連續執行的過程

這種連續性假象是由 ASP NET 頁框架 頁及其控制項實現的 回發後 控制項的行為必須看起來是從上次 Web 請求結束的地方開始的 雖然 ASP NET 頁框架可使執行狀態管理相對容易一些 但是為了獲得連續性效果 控制項開發人員必須知道控制項的執行順序 控制項開發人員需要了解 在控制項生命周期的各個階段 控制項可使用哪些信息 保持哪些數據 控制項呈現時處於哪種狀態 例如 在填充頁上的控制項樹之前控制項不能調用其父級 下表提供了控制項生命周期中各階段的高級概述 有關詳細信息 請點擊表中的鏈接

階段 控制項需要執行的操作 要重寫的方法或事件初始化 初始化在傳入 Web 請求生命周期內所需的設置 請參閱處理繼承的事件 Init 事件（OnInit 方法）

載入視圖狀態 在此階段結束時 就會自動填充控制項的 ViewState 屬性 詳見維護控制項中的狀態中的介紹 控制項可以重寫 LoadViewState 方法的默認實現 以自定義狀態還原 LoadViewState 方法處理回發數據 處理傳入窗體數據 並相應地更新屬性 請參閱處理回發數據

注意 只有處理回發數據的控制項參與此階段 LoadPostData 方法 （如果已實現IPostBackDataHandler）

載入 執行所有請求共有的操作 如設置資料庫查詢 此時 樹中的伺服器控制項已創建並初始化 狀態已還原並且窗體控制項反映了客戶端的數據 請參閱處理繼承的事件 Load 事件（OnLoad 方法）

發送回發更改通知 引發更改事件以響應當前和以前回發之間的狀態更改 請參閱處理回發數據

注意 只有引發回發更改事件的控制項參與此階段 RaisePostDataChangedEvent 方法（如果已實現 IPostBackDataHandler）

處理回發事件 處理引起回發的客戶端事件 並在伺服器上引發相應的事件 請參閱捕獲回發事件

注意 只有處理回發事件的控制項參與此階段 RaisePostBackEvent 方法（如果已實現 IPostBackEventHandler）

預呈現 在呈現輸出之前執行任何更新 可以保存在預呈現階段對控制項狀態所做的更改 而在呈現階段所對的更改則會丟失 請參閱處理繼承的事件 PreRender 事件（OnPreRender 方法）

保存狀態 在此階段後 自動將控制項的 ViewState 屬性保持到字元串對象中 此字元串對象被發送到客戶端並作為隱藏變數發送回來 為了提高效率 控制項可以重寫 SaveViewState 方法以修改 ViewState 屬性 請參閱維護控制項中的狀態 SaveViewState 方法呈現 生成呈現給客戶端的輸出 請參閱呈現 ASP NET 伺服器控制項 Render 方法處置 執行銷毀控制項前的所有最終清理操作 在此階段必須釋放對昂貴資源的引用 如資料庫鏈接 請參閱 ASP NET 伺服器控制項中的方法

Dispose 方法卸載 執行銷毀控制項前的所有最終清理操作 控制項作者通常在 Dispose 中執行清除 而不處理此事件 UnLoad 事件（On UnLoad 方法）

從這個表裡面我們可以清楚的看到一個Page從裝載到卸載之間調用的方法和觸發的時間 接下來我們就深入的對其進行一些分析

看了上面的表 細心的朋友可能要問了 既然OnInit是頁面生命周期的開始 而我們在上一講中談到控制項在子類中被創建 那麼在這里實際上在InitializeComponent方法中我們已經可以使用父類中聲名的欄位了 那麼就意味著子類的初始化更在這之前？

在第三個標題中我們講到了頁面類的ProcessRequest才是真正意義上的頁面聲明周期的開始 這個方法是由HttpApplication調用的（其中調用的方式比較復雜 有機會單獨撰文來講解） 一個Page對請求的處理就是從這個方法開始 通過反編譯 Net類庫來查看源代碼 我們發現在System Web WebControls Page的基類 System Web WebControls TemplateControl（它是頁面和用戶控制項的基類）中定義了一個 FrameworkInitialize 虛擬方法 然後在Page的ProcessRequest中最先調用了這個方法 在生成器生成的ASPX的源代碼中我們發現了這個方法的蹤影 所有的控制項都在這個方法中被初始化 頁面的控制項樹就在這個時候產生

接下來的事情就簡單了 我們來逐步分析頁面生命周期的每一項

初始化

初始化對應Page的Init事件和OnInit方法

如果要重寫 MSDN推薦的方式是重載OnInti方法 而不是增加一個Init事件的代理 這兩者是有差別的 前者可以控制調用父類OnInit方法的順序 而後者只能在父類的OnInit後執行（實際上是在OnInit裡面被調用的）

載入視圖狀態

這是個比較重要的方法 我們知道 對於每次請求 實際上是由不同的頁面類實例來處理的 為了保證兩次請求間的狀態 ASP Net使用了ViewState

LoadViewState方法就是從ViewState中獲取上一次的狀態 並依照頁面的控制項樹的結構 用遞歸來遍歷整個樹 將對應的狀態恢復到每一個控制項上

處理回發數據

這個方法是用來檢查客戶端發回的控制項數據的狀態是否發生了改變 方法的原型

public virtual bool LoadPostData（string postDataKey NameValueCollection postCollection）

postDataKey是標識控制項的關鍵字（也就是postCollection中的Key） postCollection是包含回發數據的集合 我們可以重寫這個方法 然後檢查回發的數據是否發生了變化 如果是則返回一個True 如果控制項狀態因回發而更改 則 LoadPostData 返回 true 否則返回 false 頁框架跟蹤所有返回 true 的控制項並在這些控制項上調用 RaisePostDataChangedEvent （摘自MSDN）

這個方法是System Web WebControls Control中定義的 也是所有需要處理事件的自定義控制項需要處理的方法 對於我們今天討論的Page來說 可以不用管它

載入

載入對應Load事件和OnLoad方法 對於這個事件 相信大多數朋友都會比較熟悉 用VS Net生成的頁面中的Page_Load方法就是響應Load事件的方法 對於每一次請求 Load事件都會觸發 Page_Load方法也就會執行 相信這也是大多數人了解ASP Net的第一步

Page_Load方法響應了Load事件 這個事件是在System Web WebControl Control類中定義的（這個類是Page和所有伺服器控制項的祖宗） 並且在OnLoad方法中被觸發

很多人可能碰到過這樣的事情 寫了一個PageBase類 然後在Page_Load中來驗證用戶信息 結果發現不管驗證是否成功 子類頁面的Page_Load總是會先執行 這個時候很可能留下一些安全性的隱患 用戶可能在沒有得到驗證的情況下就執行了子類中的Page_Load方法

出現這個問題的原因很簡單 因為Page_Load方法是在OnInit中被添加到Load事件中的 而子類的OnInit方法中是先添加了Load事件 然後再調用base OnInit 這樣就造成了子類的Page_Load被先添加 那麼先執行了

要解決這個問題也很簡單 有兩種方法

） 在PageBase中重載OnLoad方法 然後在OnLoad中驗證用戶 然後調用base OnLoad 因為Load事件是在OnLoad中觸發 這樣我們就可以保證在觸發Load事件之前驗證用戶

） 在子類的OnInit方法中先調用base OnInit 這樣來保證父類先執行Page_Load

發送回發更改通知

這個方法對應第 步的處理回發數據 如果處理回發數據返回True 頁面框架就會調用此方法來觸發數據更改的事件 所以自定義控制項的回發數據更改事件需要在此方法中觸發

同樣這個方法對於Page來說 沒有太大的用處 當然你也可以在Page的基礎上自己定義數據更改的事件 這當然也是可以的

處理回發事件

這個方法是大多數伺服器控制項事件引發的地方 當請求中包含控制項事件觸發的信息時（伺服器控制項的事件是另一個論題 我會在不久將來另外撰文討論） 頁面控制項會調用相應控制項的RaisePostBackEvent方法來引發伺服器端的事件

這里又引出一個常見的問題

經常有網友問 為什麼修改提交後的數據並沒有更改

多數的情況都是他們沒有理解伺服器事件的觸發流程 我們可以看出 觸發伺服器事件是在Page的Load之後 也就是說頁面會先執行Page_Load 然後才會執行按鈕（這里以按鈕為例）的點擊事件 很多朋友都是在Page_Load中綁定數據 然後在按鈕事件中處理更改 這樣做有一個毛病 Page_Load永遠都是在按鈕事件之前執行 那麼意味著數據還沒來得及更改 Page_Load中的數據綁定的代碼就先執行了 原有的數據又賦給了控制項 那麼執行按鈕事件的時候 實際上獲得的是原有的數據 那麼更新當然就沒有效果了

更改這個問題也非常簡單 比較合理的做法是把數據綁定的代碼寫成一個方法 我們假設為BindData

private void BindData（）

{ //綁定數據}

然後修改PageLoad

private void Page_Load（ object sender EventArgs e ）

{ if（ ！IsPostBack ）

{ BindData（） //在頁面第一次訪問的時候綁定數據}

最後在按鈕事件中

private Button _Click（ object sender EventArgs e ）

{ //更新數據BindData（） //重新綁定數據}

預呈現

最終請求的處理都會轉變為發回伺服器的響應 預呈現這個階段就是執行在最終呈現之前所作的狀態的更改 因為在呈現一個控制項之前 我們必須根據它的屬性來產生Html 比如Style屬性 這是最典型的例子 在預呈現之前 我們可以更改一個控制項的Style 當執行預呈現的時候 我們就可以把Style保存下來 作為呈現階段顯示Html的樣式信息

保存狀態

這個階段是針對載入狀態的 我們多次提到 請求之間是不同的實例在處理 所以我們需要把本次的頁面和控制項的狀態保存起來 這個階段就是把狀態寫入ViewState的階段

呈現

到這里 實際上頁面對請求的處理基本就告一段落了 在Render方法中 會遞歸整個頁面的控制項樹 依次調用Render方法 把對應的Html代碼寫入最終響應的流中

處置

實際上就是Dispose方法 在這個階段會釋放佔用的資源 例如資料庫連接

卸載

最後 頁面會執行OnUnLoad方法觸發UnLoad事件 處理在頁面對象被銷毀之前的最後處理 實際上ASP Net提供這個事件只是設計上的考慮 通常資源的釋放都會在Dispose方法中完成 所以這個方法也變成雞肋了

我們簡單的介紹了頁面的生存周期 對於伺服器端事件的處理做了不太深入的講解 今天主要是想大家了解頁面執行的周期 對於伺服器控制項的事件和生存期我會在後續在寫一些文章來探討

Ⅱ aspnet webform中，用到Process.Start(Server.MapPath())打開一個文件，在本地運行可以,伺服器上不行、、

Process.Start(Server.MapPath())
==
這個Process是當前計算機的進程（實際上是web伺服器所在計算機的進程），當你在本機運行的時候客戶端就是伺服器，所以可以看到效果。

當你把網站發布到伺服器後，伺服器上打開一個文件，客戶端又怎麼能看到呢？

Ⅲ asp.net頁面讀取word文檔內容顯示

操作WORD配置說明
引入：Word的對象庫文件「MSWORD.OLB」(word 2000為MSWORD9.OLB)
1.運行Dcomcnfg.exe
2.組件服務――計算機――我的電腦――DCOM配置――找到microsoft word 文檔
3.點擊屬性
4.選擇「安全性」
5.選定「使用自定義訪問許可權」和「使用自定義啟動許可權」
6.分別編輯許可權，添加Everyone（ASPNET,VS Developers,Debugger User）
7.選擇「身份標識」，在選定「互動式用戶」 即可
8.在Web.config里加 identity impersonate="true"/
C#:
ASP.NET操作Word文檔一直是一個大家比較關心的話題，其實在ASP.NET里操作Word文檔一點也不難，大家只需按本文提示，就能輕輕鬆鬆操作Word文檔！
一、准備工作
首先請確認服務端已經安裝了Office Word(以下將以Office XP為例)，操作系統為win2000或XP，並且已配置好.NET的運行環境及安裝VS.NET C#開發環境後，我們就可以打開VS.NET，並新建一個Visual C#項目ASP.NET Web應用程序，位置為「」。(如圖一)
二、引用Word對象庫文件
要操作Word，我們就需要Word的對象庫文件「MSWORD.OLB」(word 2000為MSWORD9.OLB)，通常安裝了Office Word後，你就可以在office安裝目錄的Office10文件夾下面找到這個文件，當我們將這個文件引入到項目後，我們就可以在源碼中使用各種操作函數來操作Word。具體做法是打開菜單欄中的項目添加引用瀏覽，在打開的「選擇組件」對話框中找到MSWORD.OLB後按確定即可引入此對象庫文件，vs.net將會自動將庫文件轉化為DLL組件，這樣我們只要在源碼中創建該組件對象即可達到操作Word的目的！
答案補充
三、Webform1.aspx.cs代碼
完成添加引用後，MSWORD.OLB已經轉化為相關DLL文件並放置於項目的BIN目錄下了，這樣我們只需在源碼中創建該對象，並使用word庫文件內置的操作函數即可輕松實現操作Word，Webform1.aspx.cs源碼請參見
五、web.config設置
web.config文件還需添加一句 identity impersonate="true"/以啟用模擬身份，因為默認ASPNET這個用戶是沒有許可權訪問Word.ApplicationClass()，當啟用模擬身份後所有頁面將會使用匿名Internet用戶帳戶(IUSR_machinename)這個用戶名的許可權執行，這樣我們就能成功訪問Word.ApplicationClass()並在ASP.NET中操作Word！

//傳文檔所在路徑 返迴文檔內容
public string Doc2Text(string docFileName)
{
//實例化COM
Microsoft.Office.Interop.Word.ApplicationClass wordApp = new Microsoft.Office.Interop.Word.ApplicationClass();
object fileobj = docFileName;
object nullobj = System.Reflection.Missing.Value;
//打開指定文件（不同版本的COM參數個數有差異，一般而言除第一個外都用nullobj就行了）
Microsoft.Office.Interop.Word.Document doc = wordApp.Documents.Open(ref fileobj, ref nullobj, ref nullobj,
ref nullobj, ref nullobj, ref nullobj,
ref nullobj, ref nullobj, ref nullobj,
ref nullobj, ref nullobj, ref nullobj, ref nullobj, ref nullobj, ref nullobj, ref nullobj
);
//取得doc文件中的文本
string outText = doc.Content.Text;
//關閉文件
doc.Close(ref nullobj, ref nullobj, ref nullobj);
//關閉COM
wordApp.Quit(ref nullobj, ref nullobj, ref nullobj);
//返回
return outText;
}
當然 在讀取的時候會有損壞的文件 和被加密的文件等問題 總之C#和office的兼容性不太好
別忘了要引用word的dll
引用文件夾 右鍵添加引用 在組件里找Microsoft.Office.Interop.Word

Ⅳ asp.net運行錯誤!在別人電腦就行!

根據你所說,在別人處能運行,就可以肯定你的程序大體上是沒問題的,我估計問題可能是在你的機器上運行時連接資料庫不成功,所以導致conn沒open(或者某些原因根本就沒有new出來),如果conn不是open狀態的話,調用它的close()方法是會出錯的,連接資料庫失敗的原因通常是用戶名密碼不對,你再檢查一下連接資料庫字元串看是否正確

Ⅳ 如何讓webapi的版本降為.net4.0

vs中，打開 工具 => nuget程序包管理器 => 程序包管理器控制台，然後其中一行一行地輸入以下的更新指令。
Update-Package Microsoft.AspNet.WebApi -Version 5.2.2

漢化包
Update-Package Microsoft.AspNet.WebApi.Client.zh-Hans -Version 5.2.2
Update-Package Microsoft.AspNet.WebApi.Core.zh-Hans -Version 5.2.2
Update-Package Microsoft.AspNet.WebApi.WebHost.zh-Hans -Version 5.2.2

Update-Package EntityFramework -Version 6.0.1
Update-Package EntityFramework.zh-Hans -Version 6.0.1

Update-Package Microsoft.AspNet.Mvc -Version 5.2.2
Update-Package Microsoft.AspNet.Mvc.zh-Hans -Version 5.2.2

Update-Package Microsoft.AspNet.WebApi.HelpPage -Version 5.2.2

Update-Package Microsoft.AspNet.WebApi.OData -Version 5.2.2

Update-Package Microsoft.AspNet.WebApi.Tracing -Version 5.2.2

上面package的版本號參考了vs2013中的webapi項目模板中的版本號。引入這些包的過程中，vs有可能提示要重啟vs，請重啟vs。
錯誤：「未能找到元數據文件」
更新完package之後，重新編譯，有可能出現「未能找到元數據文件」。
解決的方法是找到出錯的項目，然後去掉報錯的引用項，然後再重新引用。
錯誤：預定義的類型"Microsoft.CSharp.RuntimeBinder.Binder"未定義或未導入 錯誤
再次編譯，有可能出現錯誤提示「預定義的類型"Microsoft.CSharp.RuntimeBinder.Binder"未定義或未導入」 ，解決的方法是：
（1）用記事本打開項目文件（後綴名為 .csproj )，找到<ItemGroup>項，可能會找到多個，選擇其中一個，在裡面加入
<Reference Include="Microsoft.CSharp" />
<Reference Include="System.Core" />

（2）保存項目文件，然後重新載入項目項目文件。

Ⅵ asp.net是什麼

ASP.NET又稱為ASP+，不僅僅是ASP的簡單升級，而是微軟公司推出的新一代腳本語言。ASP.NET基於.NET Framework的Web開發平台，不但吸收了ASP以前版本的最大優點並參照Java、VB語言的開發優勢加入了許多新的特色，同時也修正了以前的ASP版本的運行錯誤。

ASP.NET就是屬於WebForm，也就是平時說的B/S模式的開發。而WinForm就是屬於C/S模式。

.NET有很多種語言組成，比如C#、 VB.NET、J#、Jsript、Managed C++，但是都是運行在.NET FrameWork Run Time底下的。

Asp.NET可以用C#或VB.NET來開發。編譯後形成CLR，通過伺服器的IIS+.NET FrameWork再次編譯來運行。

(6)aspnetwebform版本擴展閱讀

ASP.NET和ASP的區別：

ASP.NET和ASP的最大區別在於編程思維的轉換以及功能的增強。

一、ASP使用VB/JS這樣的弱類型、面向結構的腳本語言混合html來編程，而非面向對象，這就明顯產生以下幾個問題：

1、代碼邏輯混亂，難於管理。

2、代碼的可重用性差：由於是面向結構的編程方式，並且混合html，所以可能頁面原型修改一點，整個程序都需要修改,代碼重用性差。

3、弱類型造成潛在的出錯可能。

因此在功能方面ASP同樣存在問題：

1、功能太弱，一些底層操作只能通過組件來完成。

2、缺乏完善的糾錯/調試功能。

二、ASP.NET理論上可以使用任何編程語言包括C#、VB.NET、JS、、J#、Managed C++等等，最合適的編程語言還是MS為.NET Frmaework專門推出的C#。

優點如下：

1、是面向對象的編程語言，簡單易學。

2、具有面向對象編程語言的一切特性，比如封裝性、繼承性、多態性等等,封裝性使得代碼邏輯清晰，並且應用到ASP.NET上就可以使業務邏輯和Html頁面分離；繼承性和多態性使得代碼的可重用性大大提高