如何动态设置异步页面指令以使异步方法起作用

发布于 2024-07-26 15:00:34 字数 1413 浏览 4 评论 0原文

我正在编写一些实用程序代码来异步发送电子邮件。

var mailClient = new SmtpClient(smtpHost);
mailClient.SendCompleted += new SendCompletedEventHandler(mailClient_SendCompleted);

using (var mailMessage = new MailMessage())
{
    if (!((System.Web.UI.Page)HttpContext.Current.CurrentHandler).IsAsync)
    {
        // set to Async????
    }
    mailClient.SendAsync(mailMessage, new { EmailID });
}

但我收到错误，因为我的页面在页面指令中没有 Async="true"。

这是您得到的标准错误：

“在此上下文中不允许异步操作。页面启动 
  异步操作必须将 Async 属性设置为 true 并且 
  异步操作只能在之前的页面上启动 
  PreRenderComplete 事件。”

我读到了这个：（最后一段）

http://msdn.microsoft.com/ en-us/magazine/cc163725.aspx

最后一点要记住构建异步页面就是你不应该启动异步借用相同的操作 ASP.NET 使用的线程池。为了例如，调用 ThreadPool.QueueUserWorkItem 位于页面的异步点是因为这种方法适得其反从线程池中提取，结果净增益为零线程处理请求。相比之下，调用内置的异步方法进入框架，方法如 HttpWebRequest.BeginGetResponse 和 SqlCommand.BeginExecuteReader 是一般认为是安全的因为这些方法往往使用要实施的完成端口异步行为。

问题：

1) 如何在我的 C# 代码中将页面更新为异步？

2) 如果我不能，那么强制所有的缺点是什么？我的页面要 Async=true？

3) 有没有更好的方法来线程化我的任务而不“适得其反”？

原文

I am writing some Utility code to send off emails Async.

var mailClient = new SmtpClient(smtpHost);
mailClient.SendCompleted += new SendCompletedEventHandler(mailClient_SendCompleted);

using (var mailMessage = new MailMessage())
{
    if (!((System.Web.UI.Page)HttpContext.Current.CurrentHandler).IsAsync)
    {
        // set to Async????
    }
    mailClient.SendAsync(mailMessage, new { EmailID });
}

But I get errors because my Pages don't have Async="true" in the page directives.

here is the standard error that you get:

"Asynchronous operations are not allowed in this context. Page starting an
asynchronous operation has to have the Async attribute set to true and an
asynchronous operation can only be started on a page prior to
PreRenderComplete event."

I read this: (last paragraph )

http://msdn.microsoft.com/en-us/magazine/cc163725.aspx

A final point to keep in mind as you
build asynchronous pages is that you
should not launch asynchronous
operations that borrow from the same
thread pool that ASP.NET uses. For
example, calling
ThreadPool.QueueUserWorkItem at a
page's asynchronous point is
counterproductive because that method
draws from the thread pool, resulting
in a net gain of zero threads for
processing requests. By contrast,
calling asynchronous methods built
into the Framework, methods such as
HttpWebRequest.BeginGetResponse and
SqlCommand.BeginExecuteReader, is
generally considered to be safe
because those methods tend to use
completion ports to implement
asynchronous behavior.