推薦：采用Native 引導方式的.Net加密保護
這類加密保護方式屬于整體程序集的加密保護.這個方法首要解決的問題就是 native code 和 .Net Code如何交互.這里介紹三種實現方式.1. C /CLI 實現.這個比較簡單了,會C /CLI一下子就能完成

前幾天，在程序使用Respoonse.Redirect("a.aspx?f=9#12")的時候，發現在IE里面，跳轉之后的頁面忽略了#之后的內容，奇怪的是在同一頁面向自己Redirect的時候，這個問題就不會存在，百思不得其解，有病亂投醫吧，上網狂搜了一把，有人說設置頁面Buffer為false可能解決這個問題，于是將a頁面的buffer設置了false，經過驗證，這個與上述問題不相干，但是一時疏忽，忘記了沒有將buffer修改過來，昨天項目發布，放到服務器上發祥a頁面的執行時間大的驚人，頁面內容稍微大一點，頁面往往會超時，而實現同一功能的b頁面執行時間基本為0－16，而a頁面數據庫查詢次數為3,b頁面為7，這就更讓人納悶了，在本地試了下，b頁面基本上和服務器沒什么區別，a頁面在90-300ms之間，而明顯的b頁面要表現的數據和查詢的次數都要比a多，兩者從頁面結構上來說，基本一樣，因為二者共同使用了相同的UserControl，只有中間部分表現形式稍微不同而已，同在一個屋檐下的人，差距怎么這么大呢？納悶之余，一個個刪除頁面元素，發現根本不起本質作用，b頁面就是出奇的快，a頁面跟中風一樣，慢的可以，于是找亞找，基本說是將a改了個遍，就差說鬧鬼了得時候，突然發現a頁面的buffer設置了false，而b赫然是true, 豁然開朗，鐵釘就是這里問題，馬上更正過來，good!a頁面馬上快了起來。

一次不小心，造成如此的麻煩，不過總結了一下規律，在buffer設置為false得時候，與設置true，頁面在處理時間上基本相差10－20倍的關系，如果以后發現同樣功能的頁面，速度相差不少，排除了數據處理等因素，應該考慮一下是否存在上述問題。

分享：ASP.NET2.0服務器控件之創建復雜屬性
本文詳細講解了一個利用ASP.NET 2.0技術創建復雜屬性的示例。1、示例應用本文所實現的示例很簡單，其核心是通過實現自定義服務器控件的連字符形式復雜屬性來說明復雜屬性的實現方法，其中