1

I am working on an older ASP.Net Web Forms application. I am looking to introduce async code to help modernise it. However have encountered an impase.

The application make uses of Response.Redirect(true) in the Master Page to end a session when doing things like checking whether the user is logged in. This ends the response and redirects user back to the login page.

The trouble is when async code is used on the page. Eg:

 protected async void Page_Load(object sender, EventArgs e)
        {
            await _userService.GetUser();

            if (!IsPostBack)
            {
                ...
            }
        }

The page blows up when the redirect is hit in the master page with: System.Threading.ThreadAbortException: Thread was being aborted.

I understand why this happens from this question: Why Response.Redirect causes System.Threading.ThreadAbortException? but I am unsure how to get around this issue. I would like to use async code in the page and also allow the Response.Redirect to end the response without processing the rest of code.

I tried to use:

Response.Redirect(url, false);
Context.ApplicationInstance.CompleteRequest();

But then the page execution continues. Is there any way around this issue on WebForms? Or do I need to revert to non async code? There does not seem to be a way like in MVC to return RedirectToAction which stops page execution?

From my understanding it seems like async support is available for WebForms - how are other projects getting around this kind of issue? especially in scenarios where we need to stop page execution (for instance if user is logged out?)

Dean
  • 360
  • 1
  • 10
  • 27

1 Answers1

1

Well, since that code call is to run and go off and do its own thing?

Then of course that code can't update the page, since the page will render, and be send off and down to the client side.

Your code behind as a general rule can't wait.

So, start that process outside of the web form - after all, that async code has nothing really to do with the page, right? Since the page will have LONG been rendered and send down to the browser side while that code goes off and runs and does whatever it supposed to do, right? of course the code can't wait, and you can't hold up the page being sent down to the browser, since if you do that, then your code not async anymore, is it?????

so, do this:

{
Thread mypthread = new Thread(_userService.GetUser(););
mypthread.Start();
}

After all, that routine has nothing to do with the current page, and the current page can't wait, since if it waits, then the page will be held up until all that processing is done and THEN MAKE the trip down to the browser side.

So, you can't block or hold up the round trip.

Page post back - browser travels up to server.
Code behind runs, new page is rendered, maybe code behind changes things on that page.

Page travels down back to browser and is now just sitting there.

So, if you going to fire off some other routine that you don't want to wait for? Sure, just start it in a new thread OUT SIDE of that all important round trip. But you certainly can't fire off some async code, but THEN wait for it to complete, and THEN let the page continue being rendered. As noted, to do so would defeat the whole purpose of async code.

Albert D. Kallal
  • 42,205
  • 3
  • 34
  • 51
  • Hi Albert. Appreciate the insights here. My page calls various WCF methods which have an async version, my thinking was adding async/await into the Page_Load would allow for parallel calls to those WCF dependencies. Instead now taking approach to use RegisterAsyncTask as noted here: https://learn.microsoft.com/en-us/aspnet/web-forms/overview/performance-and-caching/using-asynchronous-methods-in-aspnet-45 – Dean Nov 12 '20 at 02:01
  • You can't block the code in the round trip. You can register a task, or just start another thread. Since the page and web code goes out of scope - it is stateless, then firing off a separate thread in this case is probably the best bet. – Albert D. Kallal Nov 12 '20 at 03:26