推薦：采用Native 引導(dǎo)方式的.Net加密保護(hù)
這類(lèi)加密保護(hù)方式屬于整體程序集的加密保護(hù).這個(gè)方法首要解決的問(wèn)題就是 native code 和 .Net Code如何交互.這里介紹三種實(shí)現(xiàn)方式. 1. C /CLI 實(shí)現(xiàn). 這個(gè)比較簡(jiǎn)單了,會(huì)C /CLI一下子就能完成

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

一次不小心，造成如此的麻煩，不過(guò)總結(jié)了一下規(guī)律，在buffer設(shè)置為false得時(shí)候，與設(shè)置true，頁(yè)面在處理時(shí)間上基本相差10－20倍的關(guān)系，如果以后發(fā)現(xiàn)同樣功能的頁(yè)面，速度相差不少，排除了數(shù)據(jù)處理等因素，應(yīng)該考慮一下是否存在上述問(wèn)題。

分享：ASP.NET2.0服務(wù)器控件之創(chuàng)建復(fù)雜屬性
本文詳細(xì)講解了一個(gè)利用ASP.NET 2.0技術(shù)創(chuàng)建復(fù)雜屬性的示例。 1、示例應(yīng)用 本文所實(shí)現(xiàn)的示例很簡(jiǎn)單，其核心是通過(guò)實(shí)現(xiàn)自定義服務(wù)器控件的連字符形式復(fù)雜屬性來(lái)說(shuō)明復(fù)雜屬性的實(shí)現(xiàn)方法，其中