Home
ASP.Net
Interview FAQs

The major practical difference is that if you call Session.Abandon(), Session_End will be fired (for InProc mode), and in the next request, Session_Start will be fired. Session.Clear( ) just clears the session data without killing it.
This may happen if your application has never stored anything in the session state. In this case, a new session state (with a new ID) is created in every request, but is never saved because it contains nothing.

However, there are two exceptions to this same session ID behavior:
1. If the user has used the same browser instance to request another page that uses the session state, you will get the same session ID every time.
2. If the Session_OnStart event is used, ASP.NET will save the session state even when it is empty.

This is one of the most frequently asked question.
1. Remember Session_End event is supported only in InProc mode.
2. Session_End will not be fired if you close your browser. HTTP is a stateless protocol, and the server has no way to know if your browser has closed or not.
3. Session_End will be fired only (i) after n minutes of inactivity (n = timeout value), or (ii) if someone calls Session.Abandon().
4.Session_End will be run by a background thread, which implies:
     a. Your code in Session_End is running using the worker process account. You may have permission problem if you are accessing resource such as database.
     b. If an error happens in Session_End, it will fail silently.
5. please note that in order for Session_End to be fired, your session state has to exist first. That means you have to store some data in the session state and has completed at least one request.
6. Session_End will be called only if the abandoned session is actually found. As a result, if you create and abandon a session inside the same request, because the session has not been saved and thus can not be found, Session_End will not be called.
It depends on which mode you are using:

- If you are using InProc mode, objects stored in session state are actually live objects, and so you can store whatever object you have created.

- If you are using State Server or SQL Server mode, objects in the session state will be serialized and deserialized when a request is processed. So make sure your objects are serializable and their classes must be marked as so. If not, the session state will not be saved successfully.

If you are using State Server or SQL Server mode, objects in the session state will be serialized and deserialized when a request is processed. So make sure your objects are serializable and their classes must be marked as so. If not, the session state will not be saved successfully.
Session_End is fired internally by the server, based on an internal timer. And thus there is no HttpRequest associted when that happens. That is why Response.Redirect or Server.Transferdoes not make sense and will not work.
You will have the HttpSessionState object available. Just use Session to access it. For HttpContext, it is not available because this event is not associated with any request.
The ASP.Net Web.config file is used to define the configuration settings for an ASP.Net application. It is an XML file. It contains configuration sections for Web Applications which we can configure manually either by using Web Site Administration Tool or by inline in the Web.config. We can also store static application settings or connection strings in this XML file. Root web.config file is in the location

C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\.

This is the common configuration file and we can also include configuration file to our application folders or Sub folders so that we can override the settings from Parent to Child.

Generally we store database connections, Session States, Error Handling, Security configurations in ASP.Net web.Config file.

PreviousDisplaying 29 of 46Next
Need Help? Contact Us.

Log in

*
*

Forgot password?

*

New User

*
*
*
*