我非常喜歡的Ext JS Framework在2010年六月改名為Sencha，意思是日本的煎茶。
整合了JQTouch與Raphaël技術後，網址、CIS識別都換了，網址從原先的http://www.extjs.com變為http://www.sencha.com囉，未來將致力發展HTML5以及Mobile相關的web app技術。
透過Ext JS，可將網站的UI做的很類似Standalone軟體一般具有良好的操作性以及強大的功能性。尤其對於一些功能導向的網站，或MIS、後台管理系統CMS等等，都是非常適用的。Ext JS以Javascript為基礎，搭配CSS在視覺描述以及JSON等資料結構的備合，再透過ajax非同步技術與伺服器程式端做溝通，讓web app擁有非常即時性與易用性的特性。不過在台灣幾乎沒有任何技術作家撰寫Ext JS的書藉，大陸倒是有不少本，而且還有一本轉譯成正體中正版在台出版出售。
老實說，VS提供這種懶人用的方便控制項，對我而言一點吸引力也沒有，一來彈性小，限制多，二來能夠達到一樣效果而且強太多的3rd party UI元件庫實在太多了(我個人覺得最棒的是Ext JS)，實在沒必要使用VS提供的陽春元件。但秉持著學習的精神，而且當然 這是VS內建的控制項，整合上當然會比起使用外部元件庫來的方便許多。
首先，先在網站專案中新增一個新的項目：「網站導覽」，檔名叫web.sitemap，是個不折不扣的xml檔。
其xml的結構簡單說一下，以<siteMap></siteMap>為root，裡面包著<siteMapNode></siteMapNode>，然後裡面再繼續一層包一層<siteMapNode></siteMapNode>，就看你的網站架構怎麼樣，就怎麼做。
而<siteMapNode>有幾個屬性，最重要的是url，有填入後，在待會兒應用的巡覽控制項中就會有超連結可以點選，但注意，整份xml中在不同的siteMapNode中的url值不可以重覆！這我覺得實在不太合理，也太死板，不過既然以此為key，那我們也就照著做。
再來是title，這個就是show出來的文字。而description就是到時滑鼠移上去停留後的提示字。
Master Page的概念，對沒接觸過ASP.Net的人而言是很陌生的東西，其實說穿了就有點像PHP用include或require將某些固定不更動的網頁做統一的設定，不用將那些不變的設計部份重覆散落在每一份網頁裡面。類似表頭，或頁尾一些公司資訊等等。
而Master Page是將不變的部份先做成一個MasterPage.master檔，在需要變動的部份置入ContentPlaceHolder元件，待產生新網頁時先與這個MasterPage做關聯後，再編輯可變動的部份。但這篇重點也不是在講解這些概念，只是在講如何從Content Page裡去修改到原本不會變動的Master Page資訊。
將Master Page看成是公共場所，而Content Page就像是在其中的私有領域空間。若是在Master Page中還是置入了一些ASP.Net元件，例如一個Label好了，在Content Page中去觸發某個動作(比如按了Button)，想要去改到這個屬於公共場所的Label Text內容，作法如下。
在Content Page的Button_Click中，先使用Master.FindControl(string ctrlid)方法去找到該元件。回傳型別是Control類別，要做明確的轉型(當然你要明白知道自己在做什麼，該轉成何種類別，錯了編譯器也不會幫你debug)，例如明確轉回Label類別。
例如：
當VS提供給你的一些驗證項目不符合你使用時，CustomValidator就可以派的上用場了。
在CustomValidator使用上，可做client端與server端的兩種驗證，先來講client端的驗證。
首先，假設我們有一個TextBox物件，並新增一個CustomValidator，將其ControlToValidate綁定好。
然後在ClientValidationFunction的地方，填上等會兒要在client端做驗證的javascript function名稱。
若依照原先自行設定的網頁移轉邏輯，希望A.aspx網頁經過一些處理後，希望跑到B.aspx網頁去。
有幾種作法：
透過程式端的寫法，可利用Server.Transfer("B.aspx")，直接在server端導向B.aspx去，此方法網址列不會改變。(還是A.aspx)
另一種程式端的寫法是用Response.Redirect("B.aspx")，這種作法是在client端執行(就如同使用javascript來轉址般)，網址會改變。(變成B.aspx)
若是透過Button上的設定，可透過PostBackUrl的屬性設定為"~/B.aspx"，則觸發按鈕後會轉址到B.aspx去。
首先建立好ASP.Net網站後，若要最乾淨的，就新增一個空的網站。
建立完後，什麼都沒有，只有一個web.config檔。接著使用新增項目，新增一個Web Form，預設會將Code-Seperation功能開啟，也就是將視覺的.aspx檔和邏輯的.cs程式碼分開，用到的是class中的partial方法(反應在@page中的CodeFile屬性中)，很多人會將Code-Seperation說成Code-Behind，這樣稱呼是有點問題的，因為Code-Behind是.Net 1.1之前的舊技術，後來改經改名叫Code-Seperation了，但大家很常會「混用」，但明白什麼意思就好了，細節在這就不多提了。
在Default.aspx中的第一行@page設定：
<%@ Page Language="C#" AutoEventWireup="false" CodeFile="Default.aspx.cs" Inherits="_Default" %>
其中，有個AutoEventWireup="true"的屬性，不知是做什麼用的，感覺挺讓人不安的呢！？
真正開始使用Visual Studio大約是2005的版本，.Net 2.0。
之前在約9、10年前時，從.Net 1.0開始其實就趕著流行接觸了當初的軟體開發新寵，不過也都僅止於「有碰過」而已。老實說，我對於網頁開發的部份，實在很不愛這樣把visual design的部份，硬是拉到非網站視覺設計專業的VS來用，我覺得自訂的ASP.Net元件來強行介入html元件中，是很醜陋的開發方式。因為我喜愛使用Dreamweaver來設計網頁的視覺部份，但要再放入VS中去「改裝」，實在不是一種我喜愛的方式。因此我個人對PHP或Java的網頁開發方式一直有著莫明的偏好。當然我知道要將Dreamweaver設計的畫面整合到VS中，當然還是有方法，只是我覺得ASP.NET開發網頁的方式實在改變太多原本的習慣，讓VS插手太多東西，雖然最後VS還是會幫程式設計師將所有新開發模式的程式碼一個一個轉成最終browser能看的懂的html，但這種主控權被軟體搶走的感覺，讓我實在難以接受。VS .Net的出現，將網頁程式設計整個改變了，美其名讓程式設計師用另一種軟體開發的模式來開發網站，但我覺得他改變太多原本不在標準內的方式，讓完全沒開發過最原本網頁程式設計的新手來說，隱藏了太多他們原本該懂的事，而且也不需要讓他們懂，這樣會讓ASP.Net的新手開發人員習慣後，很難有能力去開發較為標準的設計方式。
因此在往後幾年，投入了Java的懷抱，配合Spring Framework來做MVC，開發出來的網站每一個部份都讓我有完全掌控的感覺，中心有著很踏實的感覺，該client端的，就用JS配合JQuery等等好好的來開發，該Server端的，就運用MVC架構將邏輯運算和視覺呈現切的清清楚楚的。這是我一直以來喜歡也習慣的方式。
但自從再度接觸了Visual Studio 2005後，發現雖然我有我的堅持，而且VS一樣有讓我不喜愛的方式，但不可否認的，VS的開發時間，真的是比Java依照著規範來走的方式快的太多了。隨後不斷的進化，在VS上要寫Web Service，真的是非常的「無痛」呀，比起Java的Web Service開發，真的是簡單直覺快上太多了(但當然壞處就是程式設計師有可能會寫Web Service，但對原理卻一知半解)。要寫Ajax，拉個Ajax的作用範圍框進來後，就有Ajax的效能了，這對於Java還要去找個DWR之類的，再順著他的規定來做，開發速度和進入障礙真的是天壤之別。再來是以往要花不少時間做的資料表、分頁等呈現方式，在VS中只要輕易拉個Grid設定一下，就很方便的開發出想要的功能，真的把傳統設計方式打趴在地上！但由於這種快速產生方式的視覺格式都很制式，要客製化成原本在Dreamweaver畫自己想要的表格的那種彈性，所要花的功夫卻也相對的多而且要懂的比較深入才有辦法隨心所欲控制。若是設計給一些實是「功能性」導向的網站使用者(比如後台管理、或者以資料內容為主的公司內部網站)那倒是很快，但若是要設計很重視視覺客製化的客戶，這種急就章就會很快了，因為若不能完全掌控VS內部的設定與呈現流程，要對任何一個VS原本快速幫你產生好的元件做視覺上的細修，真的不容易。原本可能很簡單在DW可以改好的東西，在VS卻會發生「很簡單，也想這樣改，但就是不知道從何處著手去改」的冏境！
Microsoft .Net (1)