Hi,

Here is lot of Interview Tips and Tricks are available....

Learn with my posts and share your knowledge here.

How can I give them a better 404 message?

you can display the page they were trying to reach by accessing the querystring:

<%
b = Request.ServerVariables("QUERY_STRING")
msg = ""
if len(b) > 0 then
' Take out "404;" from querystring
msg = ", " & right(b,len(b)-4) & ","
end if
Response.Write "Sorry, the URL you were looking for" & msg & " is not available."
%>

How do I get screen resolution from ASP?
Screen Resolution has always been a tough egg to fry. In most browsers, you can't get a screen resolution. But if you can, what do you plan to do with it? If I have a screen resolution of 1600x1200, it doesn't mean that my browser is that size. So if you create a table that is 1550 pixels wide, just because you've detected my resolution, if my browser is not maximized I'm going to have to scroll all over the place to see the whole page.

In versions 4.0 and above of IE and Netscape, you can detect a much more meaningful variable: the width/height of the browser window. However, this data is obtained from the client, not from ASP. See the following examples:


IE 4+:

<script>

var w = document.body.clientWidth;
if (w >= 650)
{
window.location.href = "bigscreen.asp";
}
else
{
window.location.href = "smallscreen.asp";
}

</script>

Q: What isn't Session available in my event handler in global.asax?
A: It depends on which event you're handling. Session is available only after AcquireRequestState event.

Q: Does session state have a locking mechanism that serialize the access to state?
Session state implements a reader/writer locking mechanism:
- A page (or frame) that has session state write access (e.g. <%@ Page EnableSessionState="True" %>) will hold a writer lock on the session until the request finishes.
- A page (or frame) that has session state read access (e.g. <%@ Page EnableSessionState="ReadOnly" %>) will hold a reader lock on the session until the request finishes.
- Reader lock will block a writer lock; Reader lock will NOT block reader lock; Writer lock will block all reader and writer lock.
- That's why if two frames both have session state write access, one frame has to wait for the other to finish first.

Q: If using "cookieless", how can I redirect from a HTTP page to an HTTPS page?
A: Try this:
String originalUrl = "/fxtest3/sub/foo2.aspx";
String modifiedUrl = "https://localhost" + Response.ApplyAppPathModifier(originalUrl);
Response.Redirect(modifiedUrl);
NOTE: Fully qualified URLs in the response.redirect, server.transfer, and FORM action
tags cannot be used with cookiless sessions. Here is an example of a fully qualified
URL: http://www.eggheadcafe.com/default.asp

Q: How do I use session state with web services?
A: The extra trick needed is on the caller side. You have to save and store the cookies used by the web service.

Q: I am writing my own HttpHandler. Why is session state not working?
A: Your HttpHandler has to implement the "marker" interface IRequiresSessionState or IReadOnlySessionState in order to use session state.

Q: How come Response.Redirect and Server.Transfer is not working in Session_End?
A: Session_End is fired internally by the server, based on an internal timer. Thus, there is no HttpRequest associted when that happens. That is why Response.Redirect or Server.Transfer does not make sense and will not work.

Q: Session states works on some web servers but not on others.
A: Maybe machine name problem.

Q: Why are my Session variables lost frequently when using InProc mode?
A: Probably because of application recycle. See PRB: Session variables are lost intermittently in ASP.NET applications

Q: Can I share session state between ASP.NET and ASP pages?
A: Yes

Q: What kinds of object can I store in session state?
A: 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. In v1, there is a bug which makes the problem happen unnoticed.

Question: Can session variables be accessed from code-behind?
Answer: Yes. You can access the "Session" dictionary within a code-behind file just like you would if you were accessing it from within an line .aspx file.

For example: Session("Name") = "Scott"

Question: What is being passed back and forth in the _ViewState form control?
Answer: The __VIEWSTATE hidden field is used to transfer the differences in controls from what is declared in the page -- and the values they contain at the end of a request immediately prior to rendering. We can then use this information to re-construct the server controls to match that last rendered state during "postbacks" to a page.

The information within the __VIEWSTATE field is not really encrypted -- although the values are definitely "cyptic" to read (mainly because server controls try to store information in as compact a format as possible -- and because our serializer performs some limited compression).

You can see how much viewstate each control is saving by enabling tracing for the page. For example, by adding a trace attribute to the page directive:

<%@ Page Language="VB" Trace="True" %>

This will cause a table to be output at the bottom of the page. This won't show the exact values stored in viewstate -- but will give you a rough estimate of the size of each server control value.

Note that you can disable the viewstate feature -- either for the entire page or on specific server controls. This is done at the page level by setting the following page directive:

<%@ Page Language="VB" MaintainState="False" %>

or on an individual server control by setting a "maintainstate" attribute:

<asp:datagrid id="MyGrid1" maintainstate="false" runat=server/>

Question: What is being passed back and forth in the _ViewState form control?
Answer: The __VIEWSTATE hidden field is used to transfer the differences in controls from what is declared in the page -- and the values they contain at the end of a request immediately prior to rendering. We can then use this information to re-construct the server controls to match that last rendered state during "postbacks" to a page.

The information within the __VIEWSTATE field is not really encrypted -- although the values are definitely "cyptic" to read (mainly because server controls try to store information in as compact a format as possible -- and because our serializer performs some limited compression).

You can see how much viewstate each control is saving by enabling tracing for the page. For example, by adding a trace attribute to the page directive:

<%@ Page Language="VB" Trace="True" %>

This will cause a table to be output at the bottom of the page. This won't show the exact values stored in viewstate -- but will give you a rough estimate of the size of each server control value.

Note that you can disable the viewstate feature -- either for the entire page or on specific server controls. This is done at the page level by setting the following page directive:

<%@ Page Language="VB" MaintainState="False" %>

or on an individual server control by setting a "maintainstate" attribute:

<asp:datagrid id="MyGrid1" maintainstate="false" runat=server/>

Question: Is it ok to save a dataset in Page ViewState?
Answer: Scott Guthrie from Microsoft recommends that you avoid putting a DataSet
into Page ViewState. The downside with this is that doing so can drastically
increase the size of ViewState that is posted back and forth between round-trips.

This can end up making a big performance difference when connecting to the
application over slow network connections, since you end up having to transmit
a lot more data each way.

Instead, if you need to save the DataSet across requests, storing it
in Session state is better. ASP.NET now supports web farm session state
-- meaning you will no longer need to worry about being tied down to a
single machine in this scenario.

Question: Is it possible to share a cache object across servers in a cluster?
Answer: The Cache object is restricted to being used only within an application running on a single machine. Microsoft concluded that the performance hit to share the objects cross-process would be too great to share it across multiple machines in a cluster (because -- unlike session state -- there are no logical synchronization boundaries to lock across).

Question: Is there a way to directly query session data if a SQL Server StateStore is being used?
Answer: The session data is encrypted but the creation date, expiration date,
session id, and timeout are all directly available.

Question: How well does the ASPState perform when stored in SQL Server?
Answer: The target performance for the full release of ASP.Net will be 75-80% of the performance seen by using in-process state management.