Quando utilizzo Response.Redirect (...) per reindirizzare il mio modulo a una nuova pagina, visualizzo l'errore:

Si è verificata un'eccezione della prima possibilità di tipo "System.Threading.ThreadAbortException" in mscorlib.dll
Un'eccezione del tipo "System.Threading.ThreadAbortException" si è verificata in mscorlib.dll ma non è stata gestita nel codice utente

La mia comprensione di questo è che l'errore è stato causato dal server web che ha interrotto il resto della pagina su cui è stato chiamato response.redirect.

So di poter aggiungere un secondo parametro a Response.Redirectquello che si chiama endResponse. Se imposto endResponse su True ottengo ancora l'errore, ma se lo imposto su False non lo faccio. Sono abbastanza sicuro che ciò significhi che il server web sta eseguendo il resto della pagina da cui ho reindirizzato. Il che sembrerebbe inefficiente per non dire altro. C'è un modo migliore per farlo? Qualcos'altro oltre Response.Redirecto c'è un modo per forzare il caricamento della vecchia pagina in cui non otterrò un ThreadAbortException?

Il modello corretto è chiamare il sovraccarico di reindirizzamento con endResponse = false ed effettuare una chiamata per dire alla pipeline IIS che dovrebbe avanzare direttamente allo stadio EndRequest una volta restituito il controllo:

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

Questo post sul blog di Thomas Marquardt fornisce ulteriori dettagli, incluso come gestire il caso speciale di reindirizzamento all'interno di un gestore Application_Error.

Non esiste una soluzione semplice ed elegante al Redirectproblema in ASP.Net WebForms. Puoi scegliere tra la soluzione Dirty e la soluzione Tedious

Sporco : Response.Redirect(url)invia un reindirizzamento al browser, quindi lancia a ThreadAbortedExceptionper terminare il thread corrente. Quindi nessun codice viene eseguito oltre la chiamata Redirect (). Lati negativi: è una cattiva pratica e ha implicazioni sulle prestazioni nell'uccidere thread come questo. Inoltre, ThreadAbortedExceptionsverrà visualizzato nella registrazione delle eccezioni.

Tedious : il modo consigliato è chiamare, Response.Redirect(url, false)quindi l' Context.ApplicationInstance.CompleteRequest()esecuzione del codice continuerà e il resto dei gestori di eventi nel ciclo di vita della pagina verrà comunque eseguito. (Ad esempio, se esegui il reindirizzamento in Page_Load, non solo verrà eseguito il resto del gestore, Page_PreRender e così via verranno comunque chiamati - la pagina renderizzata non verrà semplicemente inviata al browser. Puoi evitare l'elaborazione aggiuntiva ad es. impostando un flag sulla pagina, quindi lasciare che i gestori di eventi successivi controllino questo flag prima di eseguire qualsiasi elaborazione.

(La documentazione CompleteRequestafferma che " Fa in modo che ASP.NET ignori tutti gli eventi e i filtri nella catena di esecuzione della pipeline HTTP ". Ciò può essere facilmente frainteso. Ignora ulteriori filtri e moduli HTTP, ma non ignora altri eventi nel ciclo di vita della pagina corrente .)

Il problema più profondo è che WebForms non ha un livello di astrazione. Quando ti trovi in ​​un gestore eventi, sei già in procinto di creare una pagina per l'output. Il reindirizzamento in un gestore eventi è brutto perché si sta terminando una pagina parzialmente generata per generare una pagina diversa. MVC non presenta questo problema poiché il flusso di controllo è separato dalle viste di rendering, quindi è possibile eseguire un reindirizzamento pulito semplicemente restituendo a RedirectActionnel controller, senza generare una vista.

So di essere in ritardo, ma ho mai avuto questo errore solo se il mio Response.Redirectè in un Try...Catchblocco.

Non inserire mai un Response.Redirect in un blocco Try ... Catch. È una cattiva pratica

modificare

In risposta al commento di @ Kiquenet, ecco cosa farei in alternativa a inserire Response.Redirect nel blocco Try ... Catch.

Suddividerei il metodo / funzione in due passaggi.

Il passaggio 1 all'interno del blocco Try ... Catch esegue le azioni richieste e imposta un valore "risultato" per indicare l'esito positivo o negativo delle azioni.

Passaggio 2 all'esterno del blocco Try ... Catch esegue il reindirizzamento (o non lo fa) in base al valore "risultato".

Questo codice è tutt'altro che perfetto e probabilmente non dovrebbe essere copiato poiché non l'ho provato

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() genera un'eccezione per interrompere la richiesta corrente.

Questo articolo della KB descrive questo comportamento (anche per i metodi Request.End()e Server.Transfer()).

Perché Response.Redirect()esiste un sovraccarico:

Response.Redirect(String url, bool endResponse)

Se si passa endResponse = false , l'eccezione non viene generata (ma il runtime continuerà a elaborare la richiesta corrente).

Se endResponse = true (o se viene utilizzato l'altro sovraccarico), viene generata l'eccezione e la richiesta corrente verrà immediatamente chiusa.

Ecco la linea ufficiale sul problema (non sono riuscito a trovare l'ultimo, ma non credo che la situazione sia cambiata per le versioni successive di .net)

Ecco come Response.Redirect(url, true) funziona. Lancia il ThreadAbortExceptionper interrompere il thread. Ignora quell'eccezione. (Suppongo che sia un gestore / logger di errori globale dove lo vedi?)

Un'interessante discussione correlata è Response.End()considerata dannosa? .

Inoltre ho provato un'altra soluzione, ma parte del codice eseguito dopo il reindirizzamento.

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();
    }

Quindi, se è necessario impedire l'esecuzione del codice dopo il reindirizzamento

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

ho anche cercato di evitarlo, nel caso in cui avessi interrotto manualmente il thread, ma preferisco lasciarlo con "CompleteRequest" e andare avanti - il mio codice ha comandi di ritorno comunque dopo i reindirizzamenti. Quindi questo può essere fatto

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();
}

Quello che faccio è catturare questa eccezione, insieme ad altre possibili eccezioni. Spero che questo aiuti qualcuno.

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

Ho avuto anche quel problema.

Prova a usare Server.Transferinvece diResponse.Redirect

Ha funzionato per me.