Question

I have a situation:

I upload user controls in a webapp and then load them when needed. Sometimes I dont want some of them. So I would want to DELETE them from my web application.

Here is the hierarchy where the controls are found.

/controls
/controls/uc/
/controls/uc/ctrl1/ctrl1.ascx (with ctrl.ascx.cs)
/controls/uc/ctrl2/ctrl2.ascx (with ctrl.ascx.cs)

Now from a delete.aspx, I have this code from where I pick the directory structure. and pick up the control directory “ctrl1(n)” and delete the directory with delete recursive.

When the deletion is over, I redirect the page using asp.net’s redirect function. But as soon as the web page is redirected, the session is over and it asks me to login (as the only logged in users can delete the controls)

Why is that strange behaviour?

Remember, none of the code is found in app_code, all controls are put under website root as shown in the above.

Edit: Of course its not PRECOMPILED!

Any help?

Answer 1

Ok, I spent some time on solving this issue… It sounds like it may not be a solution but so far what I wanted has been achieved.

What I did was that I defined session state as "StateServer" and when I deleted the folders it restarts the application pool but the session remains alive. Since the application pool recycling is dependent upon several factors including the deletion of website’s subfolders so you cant happen to stop it but can actually retain the session. If you delete folders, it wont cause loss of session but of course application will be restarted that you have to accept at any cost!

Anyway,

I used following config node in my web.config on my hosting:

<system.web>
    <sessionState mode="StateServer"  cookieless="false" timeout="20" />
</system.web>

And of course did this on my localhost:

<system.web>
    <sessionState mode="StateServer"  stateConnectionString="tcpip=127.0.0.1:42424" cookieless="false" timeout="20" />
</system.web>

Note: On localhost you must start your ASP.NET State Management Service

Summary:

1. You must define SessionState as StateServer or SqlServer in order to retain sessions. That is least you can do.

2. When developing such applications you MUST give them a way out to cope with the application restart cycles.

3. You must keep session variables as simple as possibles, do not put large objects or objects that depend upon many other objects. Serialization and deserialization takes lot of time to get them back and fro.