Impossibile valutare l'espressione perché il codice è ottimizzato o un frame nativo si trova in cima allo stack di chiamate

Ricevo l'errore:

Impossibile valutare l'espressione perché il codice è ottimizzato o un frame nativo si trova in cima allo stack di chiamate.

Ho reindirizzato a una nuova pagina nell'evento itemcommand del ripetitore. L'errore si verifica sulla riga:

string url = "~/Galleries/AlbumImageList.aspx?UId=" + this.UserId.ToString() + "&AlbumId=" + e.CommandArgument.ToString();
Response.Redirect(url);

Qualcuno può aiutarmi per favore? C'è qualcosa che non va lì? Lo _COMPlusExceptionCodeè - 532459699.

Request.Redirect(url,false);

false indica se l'esecuzione della pagina corrente deve essere terminata.

Fai il secondo argomento di Response falso come mostrato di seguito.

Response.Redirect(url,false);

Risoluzione

Per aggirare questo problema, utilizzare uno dei seguenti metodi:

• Per Response.End , chiamare il metodo HttpContext.Current.ApplicationInstance.CompleteRequest () invece di Response.End per ignorare l'esecuzione del codice all'evento Application_EndRequest .

• Per Response.Redirect , utilizzare un overload, Response.Redirect (URL stringa, bool endResponse) che passa false per il parametro endResponse per sopprimere la chiamata interna a Response.End . Ad esempio: Response.Redirect ("nextpage.aspx", false);se si utilizza questa soluzione alternativa, viene eseguito il codice che segue Response.Redirect.

• Per Server.Transfer , utilizzare invece il metodo Server.Execute .

Sintomi

Se si utilizza il metodo Response.End, Response.Redirect o Server.Transfer, si verifica un'eccezione ThreadAbortException. È possibile utilizzare un'istruzione try-catch per rilevare questa eccezione.

Causa

Il metodo Response.End termina l'esecuzione della pagina e sposta l'esecuzione sull'evento Application_EndRequest nella pipeline degli eventi dell'applicazione. La riga di codice che segue Response.End non viene eseguita.

Questo problema si verifica nei metodi Response.Redirect e Server.Transfer perché entrambi i metodi chiamano Response.End internamente.

Stato

Questo comportamento è in base alla progettazione.

Proprietà

Numero articolo: 312629 - Ultima revisione: 30 agosto 2012 - Revisione: 4.0

Si applica a

• Microsoft ASP.NET 4.5
• Microsoft ASP.NET 4
• Microsoft ASP.NET 3.5
• Microsoft ASP.NET 2.0
• Microsoft ASP.NET 1.1
• Microsoft ASP.NET 1.0

Parole chiave: kbexcepthandling kbprb KB312629

Origine: PRB: ThreadAbortException si verifica se si utilizza Response.End, Response.Redirect o Server.Transfer

In un bug che stavo investigando c'era un Response.Redirect () ed era in esecuzione in una posizione inaspettata ( leggi: posizione inappropriata - all'interno di un metodo getter di proprietà membro ).

Se stai eseguendo il debug di un problema e riscontri l' eccezione " Impossibile valutare l'espressione ... ":

1. Eseguire una ricerca Response.Redirect()e rendere il secondo parametro endResponse = false , oppure
2. Disabilita temporaneamente la chiamata di reindirizzamento .

Ciò è stato frustrante in quanto sembrerebbe eseguire la chiamata di reindirizzamento prima che il "passaggio" sul debugger avesse raggiunto quella posizione.

Controllare questo collegamento per il motivo alla base di questo problema e la soluzione per l'errore:

http://support.microsoft.com/kb/312629/EN-US/

Articolo di supporto Microsoft:

PRB: ThreadAbortException si verifica se si utilizza Response.End, Response.Redirect o Server.Transfer Stampa Stampa Email Email

Per aggirare questo problema, utilizzare uno dei seguenti metodi: Per Response.End, chiamare il metodo HttpContext.Current.ApplicationInstance.CompleteRequest invece di Response.End per ignorare l'esecuzione del codice all'evento Application_EndRequest.

Per Response.Redirect, utilizzare un overload, Response.Redirect (String url, bool endResponse) che passa false per il parametro endResponse per sopprimere la chiamata interna a Response.End.

Ad esempio: Response.Redirect ("nextpage.aspx", false);

Se si utilizza questa soluzione alternativa, viene eseguito il codice che segue Response.Redirect. Per Server.Transfer, utilizzare invece il metodo Server.Execute.

Ho avuto anche lo stesso problema ed è stato complicato. Per me, è stato perché sto usando la libreria javascript di Ext.Js. Se stai eseguendo un response.redirect nel codice lato server a cui hai effettuato l'accesso in una chiamata Ajax , ci sono problemi. Ext.js ha una soluzione alternativa con il metodo Ext.Redirect.

utilizzare questo codice per risolvere il problema:

string path = AppDomain.CurrentDomain.BaseDirectory.ToString() + "Uploadfile\\" + fileName;
System.IO.FileStream fs = new System.IO.FileStream(path, System.IO.FileMode.Open, System.IO.FileAccess.Read);
byte[] bt = new byte[fs.Length];
fs.Read(bt, 0, (int)fs.Length);
fs.Close();
Response.ContentType = "application/x-unknown/octet-stream";
Response.AppendHeader("Content-Disposition", "attachment; filename=\"" + fileName;+ "\"");
try
{
    if (bt != null)
    {
        System.IO.MemoryStream stream1 = new System.IO.MemoryStream(bt, true);
        stream1.Write(bt, 0, bt.Length);
        Response.BinaryWrite(bt);
        //Response.OutputStream.Write(bt, 0, (int)stream1.Length);
        Response.Flush();
        // Response.End();
    }
}
catch (Exception ex)
{
    Response.Write(ex.Message);
    throw ex;
}
finally
{
    Response.End();
}

Inoltre puoi usare Server.Execute

Basta che qualcun altro si sia imbattuto nei problemi che ho fatto mentre stavo usando Response.End () un pulsante di attivazione asincrono

<asp:AsyncPostBackTrigger ControlID="btn_login" />

in un pannello di aggiornamento. Sono tornato al post regolare non è il migliore ma ha funzionato.

<asp:PostBackTrigger ControlID="btn_login" />. 

Dato che stavo solo reindirizzando sulla pagina questa era una soluzione praticabile.

Se stai usando il pannello di aggiornamento e il pulsante di collegamento per scaricare Excel è all'interno del pannello di aggiungi trigger di postback

<asp:PostBackTrigger ControlID="lnkTemplate" /> 

e nel codice dietro l'evento click interno

string ServerPath = System.Configuration.ConfigurationManager.AppSettings["FilePath"] + "Template.xlsx";
System.IO.FileInfo file = new System.IO.FileInfo(Server.MapPath(ServerPath));

HttpContext.Current.Response.Clear();
HttpContext.Current.Response.AddHeader("Content-Disposition", "attachment; filename=" + file.Name);
HttpContext.Current.Response.AddHeader("Content-Length", file.Length.ToString());
            HttpContext.Current.Response.ContentType = "application/octet-stream";
 HttpContext.Current.Response.TransmitFile(file.FullName);
 HttpContext.Current.Response.Flush();
 HttpContext.Current.ApplicationInstance.CompleteRequest();

Usa questo, funziona sempre per me.

Response.Redirect(Request.RawUrl, false);

Qui, Response.Redirect (Request.RawUrl) reindirizza semplicemente all'URL del contesto corrente, mentre il secondo parametro "false" indica endResponse o no.

Questo problema può essere causato da una pagina di rasoio in mvc con un modello con alcune regole di convalida. Quando pubblichi un messaggio da un modulo e ti dimentichi di visualizzare errori di convalida in alcuni campi, questo messaggio potrebbe apparire. Speculazione: ciò potrebbe essere se il metodo su cui stai postando è diverso e utilizzato da altre fonti o risiede in una posizione diversa rispetto al metodo che serve la richiesta originale.

Quindi, poiché è diverso, non può tornare alla pagina originale per visualizzare o gestire gli errori perché l'istruzione e lo stato del modello non sono gli stessi (qualcosa del genere).

Può essere leggermente difficile da scoprire, ma facile errore da fare. Assicurati che il tuo metodo di ricezione convalidi effettivamente tutti i modi possibili per postare su di esso.

ad esempio, anche se si dispone di una convalida sul lato server che in realtà rende impossibile scrivere nel modulo una stringa più grande del massimo consentito dalla propria convalida, potrebbero esserci altri modi e fonti che inviano al metodo di ricezione.