As is suggested elsewhere, I am using redirectMode = ResponseRewrite in my custom error configuration so my custom error page can access the exception info. This has worked like a charm for some time.
In adding some more “help the user recover from an error” type functionality, we need a piece of info that has been previously stored in Session. When implementing this, I found that the various avenues to Session end in null when redirectMode=ResponseRewrite, but they are all populated when redirectMode=ResponseRedirect (or isn’t defined).
Anyone know why? It seems odd that we’d have to choose between having exception info (ResponseRewrite) or having Session (ResponseRedirect).
The MSDN article on Rich Custom Error handling tells me that Session is only available when the control passing method is Server.Transfer, which is what I assumed ResponseRewrite used under the hood. Evidently that isn’t the case.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
I don’t know the answer to the question yet, but to get past it, I took the redirectMode attribute out of my web config and put custom logic in the Global.asax Application_Error handler to do what I wanted. I am replacing the exception with a “user friendly” message exception, but essentially the transfer logic is:
if(Context.IsCustomErrorEnabled)
{
Server.Transfer("~/Error.aspx");
}
Then the Error.aspx page has Page_Load code to pull the error out of context and display the message.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0