ASP.NET 2.0支持兩種編譯模型（Compilation Model）：一為動態編譯 （Dynamic Compilation），另一個為先行編譯（Precompilation）。
這讓程序設計師可以有更寬廣的選擇以決定不同網站何時該用何種編譯模型 ，不但彈性大大提升，且若采用先行編譯網站執行效能還可以更高，分述如下：
（一）ASP.NET網站動態編譯（Dynamic Compilation）
在ASP.NET 1.0時就已經支持網站動態編譯，也就是使用者第一次請求網站網 頁時，ASP.NET會先將網站程式編譯成一個.dll組件檔，而後續的請求就會以此 來回應，而編譯過後的網站執行效能明顯較未編譯網站快上許多。
然而，雖說ASP.NET 1.0具有動態編譯的特性，但它只支持如.aspx、.ascx、 web.config或global.asax這幾種檔案類型，只要它們有異動就會觸發系統進行 動態編譯，但這個模式有個很明顯的問題存在，就是像bin目錄下的組件、資源 檔、Web Services等等在程式設計階段也常進行修改，但這些檔案即使用異動也 不會觸發系統重新進行編譯，因此每每VS.NET 2003的專案有修改異動，必須手 動重新編譯整個專案，如此使用浏覽器執行網頁才會顯示最新修改的程序頁面。
但是可能不少人嫌煩或者是初學者根本不知道修改後要手動重新編譯，因此 微軟針對動態編譯又再進行了更人性化的改良，現在針對類別、Web Service、 具型別的DataSet、Master Page、Themes也支援異動時的動態編譯，各位只要針 對IE浏覽器重新Refresh就會自動觸發系統進行重新編譯，看到的也當然是最新 的畫面，省去程序員必須手動進行編譯，算是一個貼心的改良。
ASP.NET 2.0動態編譯和ASP.NET 1.0很像，但是更完美了，且當您建造 （Build）整個Web網站後，在bin目錄並不會產生.dll的專案程式，許多ASP.NET 1.0的程序員開始驚慌、疑惑與不安，為什麼找不到專案.dll？沒有.dll檔要如 何部署網站？等等的疑惑，其實沒什麼好疑惑的，各位之所以會疑惑是因為你把 ASP.NET 1.0當作是通用的標准，凡是違反它的作法皆為異類，進而ASP.NET 2.0 的動態編譯就成為您眼中的“異類”，但那是人的執著心與本位主義 作崇的關系，事實上ASP.NET 2.0的動態編譯才是更完美，完美到根本不再需 要.dll，只要有使用者進行請求時（Request），系統會自動進行動態編譯（仍 然看不見.dll檔），所以若您要部署網站時，利用復制網站工具 將.aspx、.aspx.cs、Web.config、類別檔全部復制一份到新網站就行了（唯獨 沒有.dll檔），剩下的事情動態編譯會替您全部打理好。
（二）ASP.NET網站先行編譯（Precompilation）
除了上面所講的動態編譯外，ASP.NET 2.0尚提供先行編譯（Precompilation ）網站的功能，它透過“ASPNET_ Compiler.exe”這個指令來預先編 譯整個網站，我們用通俗觀點來說明這樣的做法有幾個好處：
(1)節省網頁第一次編譯的時間。以往在ASP.NET 1.0這個編譯的機制雖然有 效加速ASP.NET網站整體性能，但許多使用者或不明究裡的初學者卻抱怨第一次 執行感覺好慢，而預先編譯整個網站是連第一次都省掉了，大概也不會有人再抱 怨這個問題了。
(2)保護網頁源代碼的智慧財產。在ASP.NET 1.0時可以將Code Behind編譯進 dll之中，但是若是以In-Line Code開發或HTML標識開發的程式則是一點保護作 用也沒有；此外即便您用Code Behind模式開發Web應用程式，仍然會有許多標識 會產生在.aspx之中，這種情況尤以ASP.NET 2.0更甚，如SqlDataSource連SQL命 令都會顯示在HTML之中；故透過預先編譯不但連源代碼都可以編譯進去，甚至連 .aspx網頁中的HTML標識也可以一起編譯進去，對於源代碼的保護可以說多了一 層保障與選擇。
然而，我們來看看微軟對於先行編譯好處的官方說法：
(1)由於頁面和程式碼檔不需在第一次要求時編譯，因此使用者可得到更快的 響應時間，這對於經常更
新的大型網站特別有用。
(2)使用者浏覽網頁之前，識別編譯時間錯誤的方法。
(3)不需原始代碼，即可建立可部署到實際執行服務器已編譯網站版本的能力 。
