Cuando uso Response.Redirect (...) para redirigir mi formulario a una nueva página, aparece el error:

Se produjo
una excepción de primera oportunidad del tipo 'System.Threading.ThreadAbortException' en mscorlib.dll Una excepción del tipo 'System.Threading.ThreadAbortException' ocurrió en mscorlib.dll pero no se manejó en el código de usuario

Según tengo entendido, el servidor web abortó el resto de la página en la que se llamó a response.redirect.

Sé que puedo agregar un segundo parámetro Response.Redirectque se llama endResponse. Si configuro endResponse en True, sigo obteniendo el error, pero si lo configuro en False, no lo hago. Sin embargo, estoy bastante seguro de que eso significa que el servidor web está ejecutando el resto de la página desde la que redireccioné. Lo que parecería ser ineficiente por decir lo menos. ¿Hay una mejor manera de hacer esto? ¿ Response.RedirectHay algo diferente o hay alguna forma de obligar a la página anterior a dejar de cargarse donde no obtendré un ThreadAbortException?

El patrón correcto es llamar a la sobrecarga de redireccionamiento con endResponse = false y hacer una llamada para decirle a la canalización de IIS que debe avanzar directamente a la etapa EndRequest una vez que devuelva el control:

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

Esta publicación de blog de Thomas Marquardt proporciona detalles adicionales, incluido cómo manejar el caso especial de redireccionamiento dentro de un controlador Application_Error.

No hay una solución simple y elegante al Redirectproblema en ASP.Net WebForms. Puede elegir entre la solución sucia y la solución tediosa

Sucio : Response.Redirect(url)envía una redirección al navegador y luego lanza una ThreadAbortedExceptionpara terminar el hilo actual. Por lo tanto, no se ejecuta ningún código más allá de la llamada Redirect (). Desventajas: es una mala práctica y tiene implicaciones de rendimiento para matar hilos como este. Además, ThreadAbortedExceptionsaparecerá en el registro de excepciones.

Tedioso : la forma recomendada es llamar Response.Redirect(url, false)y, sin Context.ApplicationInstance.CompleteRequest()embargo, la ejecución del código continuará y el resto de los controladores de eventos en el ciclo de vida de la página aún se ejecutarán. (Por ejemplo, si realiza la redirección en Page_Load, no solo se ejecutará el resto del controlador, Page_PreRender, etc., sino que también se invocará: la página representada simplemente no se enviará al navegador. Puede evitar el procesamiento adicional al por ejemplo, establecer un indicador en la página y luego permitir que los controladores de eventos posteriores verifiquen este indicador antes de realizar cualquier procesamiento.

(La documentación CompleteRequestindica que "hace que ASP.NET omita todos los eventos y el filtrado en la cadena de ejecución de la canalización HTTP ". Esto puede ser fácilmente malinterpretado. Omite más filtros y módulos HTTP, pero no omite más eventos en el ciclo de vida actual de la página ).

El problema más profundo es que WebForms carece de un nivel de abstracción. Cuando está en un controlador de eventos, ya está en el proceso de crear una página para la salida. La redirección en un controlador de eventos es fea porque está finalizando una página parcialmente generada para generar una página diferente. MVC no tiene este problema, ya que el flujo de control es independiente de las vistas de representación, por lo que puede hacer una redirección limpia simplemente devolviendo un RedirectActionen el controlador, sin generar una vista.

Sé que llego tarde, pero solo he tenido este error si mi Response.Redirectestá en un Try...Catchbloque.

Nunca ponga una Response.Redirect en un bloque Try ... Catch. Es una mala practica

Editar

En respuesta al comentario de @ Kiquenet, esto es lo que haría como alternativa a poner el Response.Redirect en el bloque Try ... Catch.

Rompería el método / función en dos pasos.

El primer paso dentro del bloque Try ... Catch realiza las acciones solicitadas y establece un valor de "resultado" para indicar el éxito o el fracaso de las acciones.

Paso dos fuera del bloque Try ... Catch hace la redirección (o no) dependiendo de cuál sea el valor del "resultado".

Este código está lejos de ser perfecto y probablemente no debería copiarse ya que no lo he probado

public void btnLogin_Click(UserLoginViewModel model)
{
    bool ValidLogin = false; // this is our "result value"
    try
    {
        using (Context Db = new Context)
        {
            User User = new User();

            if (String.IsNullOrEmpty(model.EmailAddress))
                ValidLogin = false; // no email address was entered
            else
                User = Db.FirstOrDefault(x => x.EmailAddress == model.EmailAddress);

            if (User != null && User.PasswordHash == Hashing.CreateHash(model.Password))
                ValidLogin = true; // login succeeded
        }
    }
    catch (Exception ex)
    {
        throw ex; // something went wrong so throw an error
    }

    if (ValidLogin)
    {
        GenerateCookie(User);
        Response.Redirect("~/Members/Default.aspx");
    }
    else
    {
        // do something to indicate that the login failed.
    }
}

Response.Redirect() lanza una excepción para abortar la solicitud actual.

Este artículo de KB describe este comportamiento (también para los métodos Request.End()y Server.Transfer()).

Porque Response.Redirect()existe una sobrecarga:

Response.Redirect(String url, bool endResponse)

Si pasa endResponse = false , entonces no se genera la excepción (pero el tiempo de ejecución continuará procesando la solicitud actual).

Si endResponse = true (o si se usa la otra sobrecarga), se genera la excepción y la solicitud actual se terminará de inmediato.

Aquí está la línea oficial sobre el problema (no pude encontrar la última versión, pero no creo que la situación haya cambiado para versiones posteriores de .net)

Así es como Response.Redirect(url, true) funciona. Lanza el ThreadAbortExceptionpara abortar el hilo. Solo ignora esa excepción. (Supongo que es un controlador / registrador de errores global donde lo ves)

Una discusión relacionada interesante ¿Se Response.End()considera perjudicial? .

También probé otra solución, pero parte del código ejecutado después de la redirección.

public static void ResponseRedirect(HttpResponse iResponse, string iUrl)
    {
        ResponseRedirect(iResponse, iUrl, HttpContext.Current);
    }

    public static void ResponseRedirect(HttpResponse iResponse, string iUrl, HttpContext iContext)
    {
        iResponse.Redirect(iUrl, false);

        iContext.ApplicationInstance.CompleteRequest();

        iResponse.BufferOutput = true;
        iResponse.Flush();
        iResponse.Close();
    }

Entonces, si es necesario evitar la ejecución del código después de la redirección

try
{
   //other code
   Response.Redirect("")
  // code not to be executed
}
catch(ThreadAbortException){}//do there id nothing here
catch(Exception ex)
{
  //Logging
}

incluso intenté evitar esto, por si acaso haciendo el aborto en el hilo manualmente, pero prefiero dejarlo con "CompleteRequest" y continuar: mi código tiene comandos de retorno después de las redirecciones de todos modos. Entonces esto se puede hacer

public static void Redirect(string VPathRedirect, global::System.Web.UI.Page Sender)
{
    Sender.Response.Redirect(VPathRedirect, false);
    global::System.Web.UI.HttpContext.Current.ApplicationInstance.CompleteRequest();
}

Lo que hago es detectar esta excepción, junto con otras posibles excepciones. Espero que esto ayude a alguien.

 catch (ThreadAbortException ex1)
 {
    writeToLog(ex1.Message);
 }
 catch(Exception ex)
 {
     writeToLog(ex.Message);
 }

Yo también tuve ese problema.

Intenta usar en Server.Transferlugar deResponse.Redirect

Trabajó para mi.