使用Visual Studio.NET 2003的開發者接觸Visual Studio 2005後,會發現ASP.NET 1.1專案被自動轉換成全新的專案格式(Web Site Project),有別於以往,操作開發起來更為簡便,例如:

  1. 專案檔(.csproj、.vbproj)不見了,直接開啟Web所在的資料夾就可以編輯專案,不需要先掛在IIS上,也不需要安裝FPSE(FrontPage Server Extension)。
  2.  .cs/.vb檔修改儲存後就直接生效,不需建置(Build)就可執行看結果。
  3.  引用Partial Class觀念,Server-Side程式不再有OnInit、InitializeComponent等IDE自動產生的WebControl物件宣告指令碼。
  4. 同一Web專案中可以C#與VB.NET並存(雖然這不像是個好主意)。

方便之餘,我們也開始注意到一些略為不便的差異,例如: 與頁面無關的獨立Class .cs/.vb檔必須集中放在App_Code目錄下、無法將特定的目錄及檔案排除在專案之外…等等。但最嚴重的問題,卻要到專案部署階段才會現身。

如果不想讓原始碼在正式機上露臉,VS 2005提供了Publish Web Site功能可預先建置DLL檔後再部署。但每次編譯(Compile)的DLL檔名會夾帶隨機產生的雜湊碼,ASPX<@Page>宣告則會配合隨機檔名修改而每次不同;系統上線後持續性的修Bug、加功能的工作是少不了的,每次建置出來的檔案不同讓這類小幅更新工作頓時變得棘手。當部署與維護的不便逐漸蓋過開發測試時的便利性,開發社群的不滿漸漸壓過原先的喜悅,微軟面對這波聲浪,採取的策略是亡羊補牢,迅速地提供了配套解決方案以及新的專案選擇。

我在RUN!PC 157/158期發表了兩篇文章,簡介了Web Site Project的特性,探討部署時會遭遇的問題,也提供解決方案建議。由於這個部署問題,幾乎所有ASP.NET 2.0開發者都必須面對,因此我一併將文章公佈在Blog上,大家可以到這裡下載。


Comments

Be the first to post a comment

Post a comment


6 + 6 =