FAQS on .net ::::::::::::::::::::::
1. http://www.aspnetfaq.com/default.aspx
2. http://www.techinterviews.com/

Server transfer :::::::::::: reduces 1 round trip

usually there will be object context which will be in bw client and server. Whenever a client requests for a page, it actually hits a object context which displays a blank page and internally client hits server which actually serves the page. But whenever server transfer is used, client context is totally removed hence, u can see the same page title @ the top but page will actually be redirected. Basically used to transfer to error pages

Case scenario::::::::::::::::::::::::::: whenever u wanna call a page which is outside ur website, never use server.transfer.

Request: humbly asking
Response: expecting a reply
Server.Transfer : we are sure its there and asking ;)

State management

basically 2 types
1. Client state management --------- Cookies, Cache, Request
2. server side state management ------- Cache, Session, Application

NOTE:
Basic Differeneces bw cookies and cache is that Cache can be used to save the whole page or part of the page. But, cookies used to hold only few values

Application vs Session level variables

Session is for single user state management Applicaton is for multiple users state management
Best example for application variable is stock exchange value maintained and simple one is for hit rate

All about IIS 5 vs IIS 6.0

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/webapp/iis/iis6perf.mspx

pretty simple one 2 explain the differences:

http://msdn2.microsoft.com/en-us/library/ms524539.aspx

add 2 column values of a datatable 2 datavaluefield of a dropdown list

DVU_eventsTableAdapter _events = _new _DVU_eventsTableAdapter();

_DataTable _dt = _events._GetData();
_for (_int _i = _0; _i < _dt._Rows._Count; _i++)
{
_DateTime _eventdate = _new _DateTime();
_eventdate = _Convert._ToDateTime(_dt._Rows[i]["event_date"]._ToString());
_string _formatted_date = _String._Format("{0:d}", eventdate);
_ddlEvent._Items._Add(_new _ListItem(_dt._Rows[i]["loc_city"]._ToString() + ", " + _dt._Rows[i]["loc_state"]._ToString() + " (" + _formatted_date + ")", _dt._Rows[i]["event_id"]._ToString()));
}

Reference::::: http://forums.asp.net/p/1088821/1627029.aspx#1627029

All about Design Patterns in .net

http://www.dofactory.com/Patterns/Patterns.aspx

Wannna have radio button inside grid view:::::::::::::::::: shud use name instead of id for a html radio button type

refernce: http://www.gridviewguy.com/ArticleDetails.aspx?articleID=149

To have check all option (alernate method) using javascript

<_pre _lang="_jscript"><_script _language="_javascript">_function _SelectAllCheckboxes(_spanChk){ _// Added as ASPX uses SPAN for checkbox _var oItem = spanChk.children; _var _theBox= _(spanChk.type=="checkbox") ?spanChk : spanChk.children.item[0]; _xState=_theBox.checked; _elm=_theBox.form.elements; _for(_i=0;_i<_elm._length;_i++_) _type="=" checked="_xState;">

reference: http://www.codeproject.com/aspnet/SelChkboxesDataGridView.asp

NOTE on Enabling visibility of a row in Gridview using javascript

If u make any rows invisible in grid view, u cant read the same rows in javascript, so instead of making it invisible, just use the following attribute

row.Attributes.Add("Style","display:none")

GridView Vs DataGrid

As long as control builders properly partition their state into behavioral state (to maintain core
functionality) and UI state (to retain contents), this statement should be followed religiously. I
would like to tell you to start following this recommendation now with all work done in ASP.NET 2.0, but the DataGrid has not been refactored to keep its behavioral state in control state. Fortunately, the new GridView is the logical successor to the DataGrid and it uses control state properly, as do the new versions of the TextBox and DropDownList controls.

Control State vs View State

When you are deciding what should go into control state and what should go into view state, remember that it should be a separation of behavioral state from content or UI state. Things like properties and collections of data should generally stay in view state and not migrate to control state. State that triggers a server-side event is the most typical type to store in control state.
Declarative Data Sources and View State
In simple case, if we have not disabled view state on the GridView, you may think that we are again just wasting view state on storing data that is never used. Fortunately, the ASP.NET 2.0 engine makes the extra effort to do the right thing here, and it will not bother going back to the database when view state is enabled on a control.

Similarly, if you disable view state on the GridView, the data binding to the data source will occur on each request including POST back requests.
This functionality is built into the DataBoundControl base class from which the AdRotator, BulletedList, CheckBoxList, DropDownList, ListBox, RadioButtonList, GridView, DetailsView, and FormView controls inherit. All of these controls exhibit this intelligent use of view state when bound to declarative data sources.

Reference : http://msdn.microsoft.com/msdnmag/issues/04/10/ViewState/

All about Control State

I mentioned earlier that one of the most frustrating aspects of working with server-side controls in ASP.NET 1.x is the all-or-nothing mentality with respect to view state. Behavioral aspects of controls like pagination in the DataGrid or selection change notifications in textboxes require view state to be enabled to function properly. I'm sure all of you are sufficiently daunted by the prospect of leaving view state enabled in any of your DataGrids at this point.
In ASP.NET 2.0, Microsoft addresses this particular problem by partitioning the view state into two separate and distinct categories: view state and control state.

Control state is another type of hidden state reserved exclusively for controls to maintain their core behavioral functionality, whereas view state only contains state to maintain the control's contents (UI). Technically, control state is stored in the same hidden field as view state (being just another leaf node at the end of the view state hierarchy), but if you disable view state on a particular control, or on an entire page, the control state is still propagated. The nice aspect of this implementation is that we can now amend our original principle on optimizing view state for ASP.NET 2.0 to be much stronger: if you populate the contents of a control every time a page is requested, you should disable view state for that control.

NOTE for Control State Users

For those of you building controls, the usage model for control state is not quite as convenient as view state. Instead of providing a state-bag with an indexer to insert and remove items, you must override the virtual LoadControlState and SaveControlState methods and manually manage your portion of the object collection that is mapped into control state. The one other thing you must do is call the Page.RegisterRequiresControlState method during initialization so that the page knows to ask for control state at the right time.
It is probably a good thing that storing items in control state is more difficult than view state since there is no way for users to disable it (there are also performance advantages to having an opt-in model for control state). Developers should think carefully before storing any state there as it will always be added to the rendering of a page.

View State improvements, pros and cons ;)

Advantage of ViewState:
There is one important place where view state is used, and that is in controls that issue server-side change events. If the user changes the value in a textbox or switches the selected element in a dropdown list, you can register an event handler and have code execute when the event is raised. These controls compare the current value of the control with its previous value, which is stored implicitly in view state if any process has subscribed to the change event. If you disable view state on a control whose change notification event you are handling, it won't fire correctly since it must always assume that the previous value was the same as the default value in the form.

View State Problems in 1.1:
As described earlier, the dropdown list and the textbox controls use view state to store the previous value to properly issue a change notification event on the server.
Similarly, the DataGrid class uses view state to issue pagination, edit, and sorting events.
Unfortunately, if you want to use features like sorting, paging, or editing in the DataGrid, you
cannot disable its view state. This all-or-nothing mentality of server-side controls with respect to view state is one of the most frustrating aspects of the server-side control model in ASP.NET 1.x for developers who are trying to build fast, efficient sites.

View State Improvements in ASP.NET 2.0

The first one is the overall size of view state when it is serialized. In ASP.NET 1.x the
serialization of two strings into the view state buffer looks like this:
<_p<_l<_string1;>;_l<_string2;>>;>; [Plz ignore _]

The serialization format used in ASP.NET 1.x for view state is a tuple format consisting of a
hierarchical collection of triplets and pairs serialized using less-than and greater-than
characters. The letter preceding the greater-than symbol indicates the type of the object stored (t=triplet, p=pair, i=integer, l=ArrayList, and so on). Each subelement within the less-than and
greater-than characters is separated with a semicolon. It's an interesting serialization format,
sort of like a compressed XML. If you're concerned with space, however, it is not the most efficient serialization format (only marginally better than XML).

ASP.NET 2.0 changes this serialization format. The serialization of the same two strings into the view state buffer in ASP.NET 2.0 is shown in the following line of code:

[][]string1[]string2

At least that's what it looks like when rendered to a browser. The square boxes are actually
nonprintable characters which, if we rewrite using Unicode character references, turn into the code shown here:
string1string2

Instead of using a collection of printable characters to delineate objects in the view state stream ('<', '>', ';', 'l', 'i', 'p' and so on), ASP.NET 2.0 uses a number of nonprintable characters to
mark the beginning of an object and to describe what type of object it is.

.net 2.0 viewstate advantages
Using nonprintable characters to delineate the objects stored in view state serves two purposes.
First, it improves the efficiency of the lexical analysis during the parsing of the view state
string since there is no longer any need to match characters or parse tokens.
Second, and more importantly, it reduces the number of characters used to encode the objects in view state. In my simple example of encoding two strings, the first encoding used 16 delineation characters versus 3 in the 2.0 format. This effect quickly compounds to make a significant impact.

aspnet worker process

http://msdn2.microsoft.com/en-us/library/ms225480(VS.80).aspx

All jingle bengle abt IE7 tabbing issues

After some searchs, i have found somebody else have this problem where he must maintain unique sessions between different Explorer tabs but have found the only way to do it is with cookieless sessions.

The reason this problem has come about is because the website is used to administer customer accounts. If I access CustomerA's account through the website then open a new tab and access CustomerB's account the session holding the customer ID updates to think I'm now working on CustomerB. Then if I click back to CustomerA's tab and start editing that page I am in fact editing the database record for CustomerB. This has happened and caused all sorts of problems so I need to find a fool proof way of stopping it. I don't want to put the customer ID in the URL as this will make it open to abuse.

So, what I did was to use cookieless sessions by putting sessionState mode="InProc"
cookieless="UseUri" in the web.config. That way each tab generates a new unique session ID in the URL with the format like this :http://www.domain.com/(S(kbusd155dhzflbur53vafs45))/default.aspx
I hope the above information will be helpful. If you have any issues or concerns, please let me
know. It's my pleasure to be of assistance It is ugly but works however I've now realised that search engines bots will not index pages with session id's in the URL which is bad news.

Reference: http://forums.asp.net/t/1121933.aspx

All about viewstate and control state(st. from microsoft)

http://msdn.microsoft.com/msdnmag/issues/04/10/ViewState/

NOTE: when u put a break point @ some line of code and stop debugging, still the page would have executed successfully..............!!!!!!!!!!!!!!!!!!!!!!!!!!!

.NET Interview Questions / FAQs'

http://www.andymcm.com/dotnetfaq.htm#1.1
http://www.dotnetinterviewfaqs.com/
http://www.techinterviews.com/?p=316#more-316