在网站发布并部署到生产服务器后，如果我们需要对服务器端按钮进行一些更改，则单击事件。我们可以在aspx页面本身中使用new关键字来覆盖现有的click事件。

例子

代码背后方法

 Protected void button_click(sender object, e System.EventArgs) 
  {
     Response.Write("Look Ma', I Am code behind code!")  
  }

覆盖方法:

<script runat="server">   
   Protected void new button_click(sender object, e System.EventArgs) 
  {
     Response.Write("Look Ma', I am overrided method!")  
  }

</script

通过这种方式，我们可以轻松地修复生产服务器错误，而无需重新部署。

这是最好的一个。把它加到你的网里。配置更快的编译。这是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.

通过在这里:

If you use web services instead WCF services, you can still use standard .Net membership to enforce authentication and login session behaviour on a set web services similarly to a how you would secure web site with membership forms authentication & without the need for a special session and/or soap headers implementations by simply calling System.Web.Security.FormsAuthentication.SetAuthCookie(userName, false) [after calling Membership.ValidateUser(userName, password) of course] to create cookie in the response as if the user has logged in via a web form. Then you can retrieve this authentication cookie with Response.Cookies[].Value and return it as a string to the user which can be used to authenticate the user in subsequent calls by re-creating the cookie in the Application_BeginRequest by extracting the cookie method call param from the Request.InputStream and re-creating the auth cookie before the membership authenticates the request this way the membership provider gets tricked and will know the request is authenticated and enforce all its rules.

将此cookie返回给用户的示例web方法签名如下: 字符串登录(用户名、密码)

后续web方法调用示例如下: 字符串DoSomething(字符串authcookie，字符串methodParam1,int methodParam2等，等)，你需要提取authcookie(这是从登录方法获得的值)参数从请求。InputStreamis

这也模拟了一个登录会话并调用FormsAuthentication。签出在web方法，如注销(authcookie)将 使用户需要再次登录。

我曾经开发过一个asp.net应用程序，它通过了一家领先的安全公司的安全审计，我学会了这个简单的技巧来防止一个不太为人所知但很重要的安全漏洞。

以下解释来自: http://www.guidanceshare.com/wiki/ASP.NET_2.0_Security_Guidelines_-_Parameter_Manipulation#Consider_Using_Page.ViewStateUserKey_to_Counter_One-Click_Attacks

考虑使用Page。ViewStateUserKey用于对抗一键式攻击。如果您对调用者进行身份验证并使用ViewState，请设置Page。Page_Init事件处理程序中的ViewStateUserKey属性，以防止一键式攻击。

void Page_Init (object sender, EventArgs e) {
  ViewStateUserKey = Session.SessionID;
}

将属性设置为您知道对每个用户都是唯一的值，例如会话ID、用户名或用户标识符。

A one-click attack occurs when an attacker creates a Web page (.htm or .aspx) that contains a hidden form field named __VIEWSTATE that is already filled with ViewState data. The ViewState can be generated from a page that the attacker had previously created, such as a shopping cart page with 100 items. The attacker lures an unsuspecting user into browsing to the page, and then the attacker causes the page to be sent to the server where the ViewState is valid. The server has no way of knowing that the ViewState originated from the attacker. ViewState validation and HMACs do not counter this attack because the ViewState is valid and the page is executed under the security context of the user.

通过设置ViewStateUserKey属性，当攻击者浏览到一个页面以创建ViewState时，该属性将初始化为攻击者的名字。当合法用户向服务器提交页面时，将使用攻击者的名称对页面进行初始化。结果，ViewState HMAC检查失败并生成异常。

应用程序变量可以与web应用程序一起使用，以便在整个应用程序中进行通信。它在全局中初始化。Asax文件，并在该web应用程序的页面上使用的所有用户独立于他们创建的会话。

throw new HttpException(404, "Article not found");

这将被ASP捕获。NET，它将返回customErrors页面。在最近的.NET每日小贴士中了解了这一点