Response.Redirect doesn't work in .Net 4.5

Question

I am calling response.redirect after verifying the login credentials this all works fine in .net framework 3.5 but when I upgrade to .net 4.5 nothing happens. It stays on the same page.

I have tried various permutations

System.Web.HttpContext.Current.Response.Redirect("/");
System.Web.HttpContext.Current.Response.Redirect("/", false);
System.Web.HttpContext.Current.ApplicationInstance.CompleteRequest();

nothing seems to work I have put a try catch around it and I don't get any exceptions when using false.

The code is being called off of an asp:button onClick event. during the click event I check to see if the credentials were correct if they are I perform the login setting session variables ... and redirect them to the appropriate landing page for their role.

More Info I have boiled my problem down to a basic scenario. In the following scenario both buttons call the same function btnTemp_Click which calls Response.redirect. In the case of the asp:button it works in the case of the HTML5 button it doesn't. In both cases the breakpoint on the response.redirect is executed.

<asp:Button ID="btnTemp" Text="Test Redirect" runat="server" OnClick="btnTemp_Click" />
<button id="btnTmp2" runat="server" onserverclick="btnTemp_Click" >button to Redirect</button>

protected void btnTemp_Click(object sender, EventArgs e)
{
        HttpContext.Current.Response.Redirect("http://www.google.com", false);
}

Something else that is weird after clicking the button the asp:button no longer works

If I create a brand new Web application and have nothing in it but these two buttons it works for both. So I must have some code that is doing something somewhere that the onserverclick hits but the onclick doesn't.

Answer 1

solved it using James Johnson's answer here

The problem is basically if you are inside an update panel and the control is not specifically registered as a postback trigger then you are trying to redirect an asynchronous postback.

so you have to explicitly register the control as a postback trigger

James Wrote:

Assuming that you're using an UpdatePanel, add the following ScriptModule to your web.config:

 <httpModules> <add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/> </httpModules> 

Your other option is to register the control doing the redirect as a postback control. With an UpdatePanel you can do this by adding a PostBackTrigger. You can also use the script manager:

 ScriptManager.GetCurrent(Page).RegisterPostBackControl(Button1); 

I couldn't get the first solution to work (at least in debug mode) The second solution worked great calling RegisterPostBackControl in the page load.

Answer 2

Don't know if this is the specific answer to your problem, but it might solve it in a roundabout way, and save somebody lots of time scratching their heads.

I had the issue of a NullReferenceException in an MS Ajax popup - specifically, clicking close on the popup was supposed to go back to the server, and the server-side code redirects to another page, however it was giving this error.

Looking at the stack trace, I could see that the exception itself was being thrown in the ScriptModule.HttpResponse_Redirecting method.

Nothing on google would help, and looking in DotPeek didn't really tell me the issue.

Then I saw that it was possible in in VS 2010 upwards to actually load the symbols for the .NET Framework code, so I did this (Tools->Options->Enable .NET Framework Source Stepping).

It turned out that the reason was that the button click was being treated as a callback (rather than a postback), Response.Reirect didn't like this (ie they don't think Response.Redirect should be called when Page.IsCallback is true), and threw an exception internally.

Although this was caught (or so it appeared), this was not before it lost its chance to populate internally the RedirectLocation property of the HttpResponse object.

The script module code then tried to parse this string, and blew on the fact that it was null.

The workaround which worked for me therefore was to explicitly set the RedirectLocation property of the HttpResponse object, immediately prior to calling Redirect. Admittedly it's not a particularly graceful solution, but, let's face it, neither is MS Ajax (nor is WebForms really for that matter! ;) )