Response.Redirect is Losing Session Variables

24 Apr, 2009 VB.NET

..or so I thought. I spent several hours today researching a problem where after submitting my edit.aspx page I would be forced to log in to my admin site again. I was clearly losing my session variable that stored my log in status. Since this was only happening during a delete data function I thought I had tracked it down to the response.redirect statement. I found several threads and blogs that indicated that I was correct in assuming that it was the response.redirect problem. They all had a simply solution – to simply use the overloaded version of Redirect:

Response.Redirect(”~/default.aspx”, false);

Of course this simple solution did not work for me. I spent a very frustrating hour researching and testing code changes before coming to the conclusion that it was not the Response.Redirect statement. So I starting researching other possible causes. After looking at my code again I noticed that the biggest difference between the edit function and the delete function was that in the delete I was doing a Directory.Delete statement to delete uploaded documents. So after a little more research I came across this article . Apparently in ASP.Net 2.0 when you delete a directory that is in your root web directory the File Change Notifications (FCN) will cause the AppDomain to restart thus losing all your session variables.

Great I had another possible cause but now I needed a solution. I didn’t like the solution presented in the article which was to just delete the files. Another posting I found suggested marking the directory in some way and then run a scheduled job to deleted the flagged directories – but that wouldn’t work for me either. Another suggestion was to move the directory outside of the web root – again not a possibilty in my situation. So my search continued until I found this code that would turn off the FCN monitoring from the root website directory, but monitoring of Bin, App_Themes and other folders will still be operational, so updated DLLs will still auto deploy.

All I had to do was add the below code into the Global.asax in the Application_Start section. Simple as that and had I not been so sure that it was a response.redirect issue I wouldn’t have spent a whole morning researching the wrong problem.

Comments are closed.