tag ASP.NET網站或ASP.NET Web應用程序?




tag helper (20)

MSDN中有一篇文章描述了這些差異:

比較網站項目和Web應用程序項目

順便說一句:有關於該主題的一些類似問題,例如:

當我在Visual Studio中啟動一個新的ASP.NET項目時,我可以創建一個ASP.NET Web應用程序,或者我可以創建一個ASP.NET Web站點。

ASP.NET Web應用程序和ASP.NET網站有什麼區別? 為什麼我會選擇其中一個呢?

答案根據我使用的是哪個版本的Visual Studio而不同?


其中一個主要區別是網站動態編譯並創建即時組件。 網絡應用程序編譯成一個大型程序集。

兩者之間的區別已經在Visual Studio 2008中取消了。


我建議您在ASP.NET網站上觀看視頻Web應用程序項目和Web部署項目 ,這些內容詳細解釋了這些差異,這對我非常有幫助。

順便說一下,不要被標題弄糊塗,視頻的很大一部分解釋了網站項目和Web應用程序項目之間的區別,以及為什麼Microsoft在Visual Studio 2005中重新引入了Web應用程序項目(正如您可能已經知道的那樣)最初僅附帶網站項目,然後在SP1中添加了Web應用程序項目)。 一個偉大的視頻,我強烈建議誰想知道的區別。


這總是取決於你的客戶的要求。 ASP.NET僅包含用戶需要的靈活功能,以確保應用程序的安全性和輕鬆維護。

您可以將Web應用程序視為在ASP.NET框架內運行的二進製文件。 將網站作為靜態網頁,您可以查看並輕鬆部署源代碼。

但是這兩種ASP.NET技術的優點和缺點都是很好的。


Web應用程序需要更多的內存,可能是因為你別無選擇,只能編譯成一個程序集。 我只是將一個大的遺留站點轉換為一個Web應用程序,並且在編譯時使用

Unexpected error writing metadata to file '' -- 
Not enough storage is available to complete this operation. 

錯誤,並在運行時出現此錯誤:

Exception information: 
    Exception type: HttpException 
    Exception message: Exception of type 'System.OutOfMemoryException' was thrown.
   at System.Web.Compilation.BuildManager.ReportTopLevelCompilationException()

我關於在內存受限的傳統硬件上轉換大型網站的建議是讓您自己選擇恢復到網站模式。 即使在最初的成功之後,問題可能會在稍後蔓延。


網站:

網站項目是即時編譯的。 你最終得到更多的DLL文件,這可能是一個痛苦。 當一個目錄中的頁面或控件需要引用另一個目錄中的頁面和控件時,它也會出現問題,因為其他目錄可能尚未編譯到代碼中。 另一個問題可能在出版。

如果不告訴Visual Studio不斷重複使用相同的名稱,它將為由頁面生成的DLL文件始終提供新的名稱。 這可能會導致幾個包含相同類名的DLL文件的密切副本,這會產生大量錯誤。 網站項目是在Visual Studio 2005中引入的,但它並不是非常受歡迎。

Web應用程序:

Web應用程序項目是作為加載項創建的,現在作為Visual Studio 2005 SP 1的一部分存在。主要區別在於Web應用程序項目的設計工作類似於Visual Studio 2003附帶的Web項目。它將在構建時將應用程序編譯為單個DLL文件。 為了更新項目,必須重新編譯並發布DLL文件以進行更改。

Web應用程序項目的另一個很好的功能是從項目視圖中排除文件更加容易。 在網站項目中,您排除的每個文件都使用文件名中的排除關鍵字進行重命名。 在Web應用程序項目中,項目只是跟踪哪些文件包含/從項目視圖中排除,而無需重命名它們,使整理更加整潔。

Reference

文章ASP.NET 2.0 - 網站vs Web應用程序項目也給出了為什麼要使用一個而不是另一個的理由。 這是它的摘錄:

  • 您需要將大型Visual Studio .NET 2003應用程序遷移到VS 2005? 使用Web應用程序項目。
  • 您想要打開並編輯任何目錄作為Web項目而不創建項目文件? 使用網站項目。
  • 您需要在編譯期間添加預構建和後構建步驟? 使用Web應用程序項目。
  • 您需要使用多個Web項目來構建Web應用程序? 使用Web應用程序項目。
  • 你想為每個頁面生成一個程序集? 使用網站項目。
  • 您更喜歡動態編譯和在頁面上工作而不在每個頁面視圖上構建整個站點? 使用網站項目。
  • 你更喜歡單頁面的代碼模型來代碼隱藏模型? 使用網站項目。

Web應用程序項目與網站項目 (MSDN)解釋了網站和Web應用程序項目之間的差異。 另外,它還討論了在Visual Studio中進行的配置。


絕對的Web應用程序,單個DLL文件,易於維護。 但一個網站更加靈活; 你可以隨時編輯aspx文件。


這裡的Web Supportive Application是網站的一個例子。 網站和Web應用程序都可以是動態/靜態的,它取決於需求,這裡是了解網站和Web應用程序工作的一個例子。


從MCTS自我節奏培訓套件考試70-515書:

借助Web應用程序(項目),

  1. 你可以創建一個MVC應用程序。
  2. Visual Studio將文件列表存儲在項目文件(.csproj或.vbproj)中,而不是依賴文件夾結構。
  3. 您不能混合使用Visual Basic和C#。
  4. 如果不停止調試會話,則無法編輯代碼。
  5. 您可以在多個Web項目之間建立依賴關係。
  6. 您必須在部署之前編譯應用程序,這會阻止您在另一個頁面無法編譯時測試頁面。
  7. 您不必將源代碼存儲在服務器上。
  8. 您可以控製程序集名稱和版本。
  9. 部署後無法編輯單個文件而無需重新編譯。

網站 =當網站由平面設計師創建並且程序員只編輯一兩頁時使用

Web應用程序 =在程序員創建應用程序時使用,圖形設計師只編輯一個或兩個分頁/圖像。

Web站點可以使用任何HTML工具進行工作,而無需開發人員工作室,因為項目文件不需要更新等。當團隊主要使用developer studio並且代碼量很大時,Web應用程序是最好的。

(在編譯時在Web應用程序中發現一些編碼錯誤,這些錯誤直到運行時才在網站中找到。)

警告: 我多年前寫了這個答案,並沒有使用過Asp.net。 我預計現在事情已經轉移。


Compilation首先Compilation有差異。 網站不在服務器上預編譯,它在文件上編譯。 這可能是一個優勢,因為當你想在你的網站上改變一些東西時,你可以從服務器上下載一個特定的文件,改變它並上傳這個文件回服務器,一切都會正常工作。 在Web應用程序中,你不能這樣做,因為everthing是預編譯的,你最終只有一個DLL。 當您在項目的一個文件中更改某些內容時,必須重新編譯所有內容。 所以如果你想有可能改變服務器上的一些文件網站是更好的解決方案。 它還允許許多開發人員在一個Web站點上工作。 另一方面,如果您不希望代碼在服務器上可用,則應該選擇Web應用程序。 由於在發佈網站後創建了一個DLL文件,因此該選項對單元測試也更好。

Project structure也有所不同。 在Web應用程序中,您有一個項目文件,就像您在正常的應用程序中一樣。 在網站上沒有傳統的項目文件,只有解決方案文件。 所有的參考和設置都存儲在web.config文件中。 @Page directive對於包含與此頁面關聯的類的文件,@Page @Page directive有一個不同的屬性。 在Web應用程序中,它是標準的“CodeBehind”,在您使用“CodeFile”的網站中。 你可以在下面的例子中看到這個:

Web Application:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs"  
Inherits="WebApplication._Default" %>  

網站:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %> 

命名空間 - 在上面的例子中,你可以看到另一個區別 - 命名空間是如何創建的。 在Web應用程序中,命名空間只是項目的名稱。 在網站中有動態編譯頁面的默認命名空間ASP。

編輯並繼續 - 在Web應用程序編輯並繼續選項可用(打開它你必須去工具菜單,單擊選項,然後找到編輯並繼續調試)。 此功能在Web Site.ASP.NET MVCIf中不起作用,您希望使用它開發Web應用程序

ASP.NET MVC(模型視圖控制器)最好的和默認的選擇是Web應用程序。 雖然可以在網站中使用MVC,但不推薦。

總結 - ASP.NET Web應用程序和網站之間最重要的區別是編譯。 所以如果你在一個更大的項目上工作,那裡有幾個人可以修改它,最好使用網站。 但是如果你正在做一個更小的項目,你也可以使用Web應用程序。


在Web應用程序中,您可以創建項目功能的各個層次,並可以通過將它們分成許多項目來創建它們之間的相互依賴關係,但是您絕對不能在網站上執行此操作。


在Web應用程序項目中,Visual Studio需要額外的頁面和用戶控件的.designer文件。 網站項目不需要這種開銷。 標記本身被解釋為設計。


網站 - 將不會創建解決方案文件。 如果我們想創建網站,不需要Visual Studio。

Web應用程序 - 將創建解決方案文件。 如果我們想要創建Web應用程序,應該需要Visual Studio。 它會在bin文件夾中創建一個.dll文件。


網站是您部署到ASP.NET Web服務器(如IIS)的內容。 只是一堆文件和文件夾。 網站中沒有任何內容將您與Visual Studio聯繫在一起(沒有項目文件)。 代碼生成和編譯網頁(例如.aspx,.ascx,.master)是在運行時動態完成的,並且對這些文件的更改由框架檢測並自動重新編譯。 您可以將您想要在頁面之間共享的代碼放在特殊的App_Code文件夾中,或者您可以預編譯它並將程序集放入Bin文件夾中。

Web應用程序是一個特殊的Visual Studio項目。 與Web站點的主要區別在於,當您構建項目時,所有代碼文件都被編譯為一個程序集,該程序集位於bin目錄中。 您不要將代碼文件部署到Web服務器。 您可以將它們放在任何地方,而不必像共享代碼文件那樣使用特殊文件夾,就像您在類庫中所做的一樣。 由於Web應用程序包含不想部署的文件(如項目和代碼文件),Visual Studio中有一個Publish命令用於將Web站點輸出到指定的位置。

App_Code vs Bin

部署共享代碼文件通常是一個壞主意,但這並不意味著您必須選擇Web應用程序。 您可以擁有一個網站,該網站引用了包含網站所有代碼的類庫項目。 Web應用程序只是一個方便的方法。

代碼隱藏

本主題特定於.aspx和.ascx文件。 本主題在新的應用程序框架(如不使用代碼隱藏文件的ASP.NET MVC和ASP.NET Web頁面)中越來越相關。

通過將所有代碼文件編譯為單個程序集,包括.aspx頁面和.ascx控件的代碼codebehind文件,在Web應用程序中,您必須重新構建每個小改動,並且無法進行實時更改。 在開發過程中,這可能是一個真正的痛苦,因為您必須不斷重新構建才能看到更改,而使用網站更改會被運行時檢測到,並且頁面/控件會自動重新編譯。

使用運行時管理代碼隱藏程序集對於您而言不太方便,因為您無需擔心為頁/控件提供唯一名稱,或將它們組織到不同的名稱空間中。

我並不是說部署代碼文件總是一個好主意(特別是不是共享代碼文件),但代碼隱藏文件應該只包含執行特定於UI的任務的代碼,線程事件處理程序等。您的應用程序應該是因此重要代碼總是以Bin文件夾結尾。 如果是這種情況,那麼部署代碼隱藏文件不應被認為是有害的。

Web應用程序的另一個限制是您只能使用項目的語言。 在Web站點中,您可以在C#中使用一些頁面,在VB中使用一些頁面等。無需特殊的Visual Studio支持。 這是構建提供程序可擴展性的優點。

而且,在Web應用程序中,由於編譯器僅編譯代碼隱藏類,而不是編譯代碼(在MVC中,您可以使用MvcBuildViews選項修復此問題),因此編譯器在運行時編譯時不會在頁面/控件中檢測到錯誤。

視覺工作室

由於Web應用程序是Visual Studio項目,因此您可以使用某些在Web站點中不可用的功能。 例如,您可以使用構建事件來執行各種任務,例如縮小和/或組合JavaScript文件。

在Visual Studio 2010中引入的另一個不錯的功能是Web.config轉換 這在網站中也不可用。 現在適用於VS 2013中的網站。

構建Web應用程序比構建Web站點更快,特別適用於大型站點。 這主要是因為Web應用程序不編譯標記代碼。 在MVC中,如果您將MvcBuildViews設置為true,那麼它將編譯標記代碼,並獲得錯誤檢測,這非常有用。 不利的一面是,每次構建解決方案時,都會構建完整的網站,這可能會很慢且效率低下,特別是如果您未編輯網站。 我發現自己打開和關閉MvcBuildViews(這需要項目卸載)。 另一方面,對於網站,您可以選擇是否要將網站構建為解決方案的一部分。 如果您選擇不這樣做,那麼構建解決方案的速度非常快,並且您可以隨時單擊“網站”節點並選擇“構建”(如果已進行更改)。

在MVC Web應用程序項目中,您有常見任務的額外命令和對話框,如“添加視圖”,“轉到視圖”,“添加控制器”等。這些在MVC網站中不可用。

如果使用IIS Express作為開發服務器,則可以在Web站點中添加虛擬目錄。 該選項在Web應用程序中不可用。

NuGet軟件包還原在網站上不起作用,您必須手動安裝packages.config中列出的軟件包 Package Restore現在可用於啟動NuGet 2.7的網站


是的Web應用程序比Web站點好得多,因為Web應用程序給了我們自由:

  1. 將多個項目放在一起,並建立項目之間的依賴關係。 例如,我們可以在Web應用程序中使用PCS,

    • 門戶網站
    • 通知控制器(用於發送電子郵件)
    • 業務層
    • 數據訪問層
    • 異常管理器
    • Server實用程序
    • WCF服務(適用於所有平台)
    • 項目清單
  2. 對與ASP.NET頁面關聯的類文件中的代碼運行單元測試

  3. 引用那些與獨立類的頁面和用戶控件相關的類
  4. 為整個站點創建單個程序集
  5. 控制為該站點生成的程序集名稱和版本號
  6. 避免將源代碼放在生產服務器上。 (您可以避免將源代碼部署到IIS服務器,在某些情況下,例如共享主機環境,您可能會擔心未經授權訪問IIS服務器上的源代碼(對於Web站點項目,您可以通過以下方式避免此風險:在開發計算機上預編譯並部署生成的程序集而不是源代碼,但在這種情況下,您將失去輕鬆進行網站更新的一些好處。)
  7. 與網站的性能問題(對網站的第一次請求可能需要編譯網站,這可能會導致延遲。如果網站運行在內存不足的IIS服務器上,包括整個網站單個程序集可能會使用比多個程序集所需更多的內存。)

除非您有特別需要動態編譯的項目, 否則請勿使用網站項目

為什麼? 因為在嘗試更改或理解您的項目時,網站項目會將您推上牆。 Visual Studio中的靜態類型查找功能(例如,查找用法,重構)將永遠在任何合理大小的項目上使用。 有關更多信息,請參閱Visual Studio中的“查找所有引用”緩慢的堆棧溢出問題。

我真的不明白為什麼他們放棄了Visual Studio 2005中的Web應用程序,因為它引發了令人痛苦的,完整的,高效的carb web網站項目類型。


這聽起來有點明顯,但我認為這是誤解,因為Visual Studio 2005最初只與網站一起提供。 如果您的項目涉及的網站相當有限,且沒有太多邏輯或物理上的分離,則該網站沒有問題。 但是,如果它真的是一個具有不同模塊的Web應用程序,並且許多用戶添加和更新數據,那麼最好使用Web應用程序。

網站模型最大的特點是app_code部分中的任何內容都是動態編譯的。 您可以在不進行完全重新部署的情況下製作C#文件更新。 然而,這是一個很大的犧牲。 很多事情發生在難以控制的封面之下。 由於一切都是動態編譯的,所以命名空間很難控制,並且默認情況下,特定的DLL使用情況會在app_code任何地方出現。

Web應用程序模型沒有動態編譯,但您可以控制我提到的事情。

如果您正在進行多層開發,我強烈建議使用Web應用程序模型。 如果您正在進行有限的網站或快速而骯髒的實施,則網站模型可能具有優勢。

更詳細的分析可以在下面找到:


應用程序通常在部署之前進行編譯,因為網站使用app_code目錄。 當應用程序代碼文件夾中的任何內容髮生變化時,服務器將重新編譯代碼。 這意味著您可以隨時在網站上添加/更改代碼。

應用程序的優點是不需要重新編譯,因此初始啟動時間會更快。


網站和項目>>網站是使用Visual Studio創建ASP.NET應用程序的兩種不同方法。 一個是無項目,另一個是項目環境。 差異是如此

  1. 解決方案文件與項目環境中的根目錄存儲在同一目錄中。
  2. 在項目環境中部署之前需要刪除解決方案和項目文件。
  3. 完整的根目錄部署在無項目環境中。

使用這兩種方法沒有太大的區別。 但是,如果您正在創建需要更長時間的網站,請選擇項目環境。





projects-and-solutions