2013-01-02 24 views
27

Ho scritto un controllo ASP.NET personalizzato e l'ho appena aggiornato per avere un gestore di eventi Load asincrono. Ora sto ottenendo questo errore:Quali eventi del ciclo di vita ASP.NET possono essere asincroni?

An asynchronous operation cannot be started at this time. Asynchronous operations may only be started within an asynchronous handler or module or during certain events in the Page lifecycle. If this exception occurred while executing a Page, ensure that the Page is marked <%@ Page Async="true" %>.

La pagina fa hanno già il tag <%@ Page Async="true" %>. Quindi suppongo che i controlli non possano avere gestori di eventi di caricamento asincrono.

Dove è possibile trovare un elenco completo di eventi nel ciclo di vita dei Webforms ASP.NET consentiti come asincroni?

+2

Questo articolo può essere d'aiuto: http://msdn.microsoft.com/en-us/magazine/gg598924.aspx – Aristos

+1

Grazie. Sicuramente una buona lettura, anche se non risponde alla mia domanda. –

+0

Questo spiega anche un po ', e dà molto più codice di esempio di quello msdn, ma continua a non rispondere alla tua domanda:/ http://www.asp.net/web-forms/tutorials/aspnet-45/ using-asynchronous-methods-in-aspnet-45 – mirichan

risposta

28

Damian Edwards dal team ASP.NET ha dato questa risposta:

Async void event handlers in web forms are only supported on certain events, as you've found, but are really only intended for simplistic tasks. We recommend using PageAsyncTask for any async work of any real complexity.

Levi Broderick dal team ASP.NET ha dato questa risposta:

Async events in web applications are inherently strange beasts. Async void is meant for a fire and forget programming model. This works in Windows UI applications since the application sticks around until the OS kills it, so whenever the async callback runs there is guaranteed to be a UI thread that it can interact with. In web applications, this model falls apart since requests are by definition transient. If the async callback happens to run after the request has finished, there is no guarantee that the data structures the callback needs to interact with are still in a good state. Thus why fire and forget (and async void) is inherently a bad idea in web applications.

That said, we do crazy gymnastics to try to make very simple things like Page_Load work, but the code to support this is extremely complicated and not well-tested for anything beyond basic scenarios. So if you need reliability I’d stick with RegisterAsyncTask.

Quindi penso che la risposta alla mia domanda è: "Questa è la domanda sbagliata."

La domanda giusta sarebbe "Come dovrei essere asincrono nella mia applicazione Web Form ASP.NET?" E la risposta è di inserire questo frammento all'interno del vostro file code-behind aspx:

this.RegisterAsyncTask(new PageAsyncTask(async cancellationToken => { 
    var result = await SomeOperationAsync(cancellationToken); 
    // do something with result. 
})); 

Questo stesso trucco funziona all'interno di controlli personalizzati ASP.NET, basta usare this.Page.RegisterAsyncTask invece.

1

Questa pagina spiega come ciclo di vita manipolazione in pagine asincrone evento si differenzia da quelli di pagine sincrone in ASP.NET 2.0 (figura 2 è particolarmente utile):

Wicked Code: Asynchronous Pages in ASP.NET 2.0

È inoltre possibile trovare questa domanda SO di utilizzo (si parla lo stesso messaggio di errore):

async keyword and choice of the TaskScheduler

+0

Grazie, @Lokerim. In particolare, il bit utile era 'Page.RegisterAsyncTask', che a quanto pare consente ai miei controlli personalizzati ASP.NET di eseguire qualsiasi operazione asincrona, anche se ASP.NET non mi consente di utilizzare" async void Page_Load "nel mio controllo personalizzato . Grazie! –

Problemi correlati