Page对象上的ClientScript属性。

我使用的一件事是在多个版本的VB, VBScript和VB中工作。NET将记录集值转换为字符串，以消除对NULL或空白的多次测试。例如修剪(rsData(“字段名”)。值& " ") 在整数值的情况下，这将是:CLng("0" & Trim(rsData("FieldName")。值& " "))

类似于optimizeCompilations= " true "的解决方案，这里有另一个可以加快你在构建之间等待的时间(非常好，特别是如果你正在处理一个大型项目):创建一个基于ram的驱动器(即使用RamDisk)，并更改默认的“临时ASP。NET文件”到这个基于内存的驱动器。

关于如何做到这一点的完整细节在我的博客上:http://www.wagnerdanda.me/2009/11/speeding-up-build-times-in-asp-net-with-ramdisk/

基本上你首先配置一个RamDisk(同样，在我的博客中有一个免费RamDisk的链接)，然后你改变你的网络。按此配置:

 <system.web>
 ....
     <compilation debug="true" tempDirectory="R:\ASP_NET_TempFiles\">
     ....
     </compilation>
 ....
 </system.web>

它大大增加了我的开发时间，你只需要为你的电脑投资内存:)

编程的快乐!

瓦格纳·丹达

这是最好的一个。把它加到你的网里。配置更快的编译。这是3.5SP1后通过这个QFE。

<compilation optimizeCompilations="true">

Quick summary: we are introducing a new optimizeCompilations switch in ASP.NET that can greatly improve the compilation speed in some scenarios. There are some catches, so read on for more details. This switch is currently available as a QFE for 3.5SP1, and will be part of VS 2010. The ASP.NET compilation system takes a very conservative approach which causes it to wipe out any previous work that it has done any time a ‘top level’ file changes. ‘Top level’ files include anything in bin and App_Code, as well as global.asax. While this works fine for small apps, it becomes nearly unusable for very large apps. E.g. a customer was running into a case where it was taking 10 minutes to refresh a page after making any change to a ‘bin’ assembly. To ease the pain, we added an ‘optimized’ compilation mode which takes a much less conservative approach to recompilation.

通过在这里:

你可以使用:

 Request.Params[Control.UniqueId] 

在viewstate初始化之前获取控件的值。文本等将在此时为空)。

这对于Init中的代码很有用。

包含在ASP中。Net 3.5 sp1:

customErrors现在支持“redirectMode”属性，值为“ResponseRewrite”。显示错误页面而不改变URL。 表单标记现在识别操作属性。非常适合在使用URL重写时使用