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 http://www.vikramlakhotia.com/Deleting_Directory_in_ASPnet_20.aspx . 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 vb.net 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.

Dim p As System.Reflection.PropertyInfo
Dim o As Object
Dim m As System.Reflection.MethodInfo
p = GetType(System.Web.HttpRuntime).GetProperty(“FileChangesMonitor”, System.Reflection.BindingFlags.NonPublic Or System.Reflection.BindingFlags.Public Or System.Reflection.BindingFlags.Static)
o = p.GetValue(Nothing, Nothing)
m = o.GetType().GetMethod(“Stop”, System.Reflection.BindingFlags.Instance Or System.Reflection.BindingFlags.NonPublic)
m.Invoke(o, New Object() {})

All I had to do was add the above 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.