Non-Generic Vs. Generic Type

Non-Generic	Similar Generic Type
ArrayList	List<T>
Hashtable	Dictionary<TKey,TValue>
SortedList	SortedList<TKey,TValue>
Queue	Queue<T>
Stack	Stack<T>
Ienumerable	IEnumerable<T>
ICollection	N/A (use IEnumerable<T>anything that extends it)
N/A	ICollection<T>
Ilist	IList<T>
CollectionBase	Collection<T>
ReadOnlyCollectionBase	ReadOnlyCollection<T>
DictionaryBase	N/A (just implement IDictionary<TKey,TValue>
N/A	SortedDictionary<TKey,TValue>
N/A	KeyedCollection<TKey,TItem>
N/A	LinkedList<T>

ASP.NET Impersonation

It is an important security feature which have ability to control the identity under which code is executed. Impersonation is when ASP.NET executes code in the context of an authenticated and authorized client. By default, ASP.NET does not use impersonation and instead executes all code using the same user account as the ASP.NET process, which is typically the ASPNET account. This is contrary to the default behavior of ASP, which uses impersonation by default. In Internet Information Services (IIS) 6, the default identity is the NetworkService account.
Impersonation is disabled. This is the default setting. <identity impersonate="false">
Impersonation enabled. In this instance, ASP.NET impersonates the token passed to it by IIS, which is either an authenticated user or the anonymous Internet user account (IUSR_machinename). <identity impersonate="true">
Impersonation enabled for a specific identity. In this instance, ASP.NET impersonates the token generated using an identity specified in the Web.config file. <identity  password="password" impersonate="true" username="domain\user">

Different Type of Reports in SSRS (2008)

• Ad hoc reports
• Cached reports
• Clickthrough reports
• Drilldown reports
• Drillthrough reports
• Linked reports
• Parameterized reports
• Snapshot reports
• Subreports

Implementation of two interface having the same method signature in the same class

If the signature of the methods in two different interfaces are same and both the interfaces are going be implemented in the same class. Following is the two interfaces:
public interface Interface1 { string PrintName(); }
public interface Interface2 { string PrintName(); }
From the above code we can infer that we have two interface with names Interface1 and Interface2 and both have a single method named “PrintName”. The signatures of both the methods are same and we need to implement the interfaces in our class “myClass”. One way of implementing the interface is as shown below (just having a “public” implementation of the interface method only once).
public class myClass : Interface1, Interface2
{
public myClass() { }
public string PrintName() { return this.GetType().Name; }
}
The above implementation has got a limitation i.e the method “PrintName” is considered to be a common method for all i.e common method for the class, and for the interfaces Interface1 and Interface2. If you are writing a code shown below
myClass myclass = new myClass ();
Interface1 i1 = new myClass ();
Interface2 i2 = new myClass ();
Console.WriteLine(myclass.PrintName());
Console.WriteLine(i1.PrintName());
Console.WriteLine(i2.PrintName());
All the calls to method “PrintName” will give you the same result, the name of the class i.e. “myClass”. This is because all call to the method goes to the same definition. Now if you want to give different implementation to the methods in interface Interface1 and Interface2; you have two implementations of the same method and prefix the method names with the interface name as shown below.
public class myClass : Interface1, Interface2
{
public myClass() { }
string Interface1.PrintName() { return “Interface1 PrintName Method”; }
string Interface2.PrintName() { return “Interface2 PrintName Method”; }
}
Now the below code will give you different output.
Interface1 i1 = new myClass();
Interface2 i2 = new myClass();
Console.WriteLine(i1.PrintName());// Will print " Interface1 PrintName Method"
Console.WriteLine(i2.PrintName());// Will print " Interface2 PrintName Method"
So this is how two interfaces having the same method signature can be given different implementation in the same class.

Life cycle of an object

1. When the object is created, memory is allocated for it, the constructor is run, and the object is considered live.
2. If the object, or any part of it, cannot be accessed by any possible continuation of execution, other than the running of destructors, the object is considered no longer in use and it becomes eligible for destruction.
3. The C# compiler and the garbage collector may choose to analyze code to determine which references to an object may be used in the future. For instance, if a local variable that is in scope is the only existing reference to an object, but that local variable is never referred to in any possible continuation of execution from the current execution point in the procedure, the garbage collector may (but is not required to) treat the object as no longer in use.
4. Once the object is eligible for destruction, at some unspecified later time the destructor (if any) for the object is run. Unless overridden by explicit calls, the destructor for the object is run once only.
5. Once the destructor for an object is run, if that object, or any part of it, cannot be accessed by any possible continuation of execution, including the running of destructors, the object is considered inaccessible and the object becomes eligible for collection.
6. Finally, at some time after the object becomes eligible for collection, the garbage collector frees the memory associated with that object.

The behavior of the garbage collector can be controlled, to some degree, via static methods on the class System.GC. This class can be used to request a collection to occur, destructors to be run (or not run), and so forth.
Note:
Destructors are not inherited. Thus, a class has no destructors other than the one that may be declared in that class.

Since a destructor is required to have no parameters, it cannot be overloaded, so a class can have, at most, one destructor.
Destructors are invoked automatically, and cannot be invoked explicitly. An instance becomes eligible for destruction when it is no longer possible for any code to use that instance. Execution of the destructor for the instance may occur at any time after the instance becomes eligible for destruction.  (http://www.devx.com/dotnet/Article/33167/1954)

Table Variable vs Temporary Table (#, ##)

As temporary tables (#, ##) and table variables. While the differences between ##table (global temporary table) and #table (local temporary table) are well understood, there is a fair amount of confusion between #table and table variable.
The scoping rules of the table variable are similar to any other programming variables. For example, if you define a variable inside a stored procedure, it can’t be accessed outside the stored procedure. Incidentally, #table is very similar. So why did we create table variables? Well, a table variable can be very powerful when used with stored procedures to pass it as input/output parameters (new functionality available starting with SQL Server 2008) or to store the result of a table valued function. Here are some similartities and differences between the two:

• First, the table variable is NOT necessarily memory resident. Under memory pressure, the pages belonging to a table variable can be pushed out to tempdb.
• Second, when you create a table variable, it is like a regular DDL operation and its metadata is stored in system catalog.
• Third, transactional and locking semantics. Table variables don’t participate in transactions or locking.
• Fourth, the operations done on table variable are not logged.
• Fifth, no DDL is allowed on table variables. So if you have a large rowset which needs to be queried often, you may want to use #table when possible so that you can create appropriate indexes. You can get around this by creating unique constraints when declaring table variable.
• Finally, no statistics is maintained on table variable which means that any changes in data impacting table variable will not cause recompilation of queries accessing table variable. 

These are some of the drawbacks of Table Variable as compared to temporary tables:

• Non-clustered indexes cannot be created on table variables, other than the system indexes that are created for a PRIMARY or UNIQUE constraint. That can influence the query performance when compared to a temporary table with non-clustered indexes.
• Table variables do not maintain statistics like temporary tables can. Statistics cannot be created on table variables through automatic creation or by using the CREATE STATISTICS statement. Therefore, for complex queries on large tables, the lack of statistics may deter the optimizer to determine the best plan for a query, thus affecting the performance of that query.
• The table definition cannot be changed after the initial DECLARE statement.
• Tables variables cannot be used in a INSERT EXEC or SELECT INTO statement.
• CHECK constraints, DEFAULT values, and computed columns in the table type declaration cannot call user-defined functions.
• You cannot use the EXEC statement or the sp_executesql stored procedure to run a dynamic SQL Server query that refers a table variable, if the table variable was created outside the EXEC statement or the sp_executesql stored procedure. Because table variables can be referenced in their local scope only, an EXEC statement and a sp_executesql stored procedure would be outside the scope of the table variable. However, you can create the table variable and perform all processing inside the EXEC statement or the sp_executesql stored procedure because then the table variables local scope is in the EXEC statement or the sp_executesql stored procedure.

Table variables have the following advantages over temporary tables:

• Table variables, such as local variables, have a well defined scope at the end of which they are automatically cleared.
• Table variables result in fewer recompilations of a stored procedure as compared to temporary tables.
• Transactions that involve table variables last only for the duration of an update on the table variable. Therefore, table variables require less locking and logging resources. Because table variables have limited scope and are not part of the persistent database, transaction rollbacks do not affect them.

ASP.NET 2.0 AJAX Extensions Update Panel - Nested Update Panel

The thumb rule with nested update panels is as follows:-
Parent Update Panel refreshes all the contents including Child Update Panel's contents even if the Child Update Panel's update mode is set to Conditional; Child Update Panel refreshes only its contents and doesnt refresh that of the Parent Update Panel unless, the update mode for the parent update panel is not set to Conditional;The HTML for the Nested Update Panel is as below:-

<form id="form1" runat="server">
<asp:ScriptManager ID="ScriptManager1" runat="server">
</asp:ScriptManager>
<div>
<table width="80%" border="3">
<tr>
<td>
Label outside all the Update Panels
<asp:Label ID="Label3" runat="Server" Font-Bold="true"></asp:Label>
<br />
<br />
<asp:Button ID="Button3" runat="Server" Text="Refresh" />
<br />
<br />
</td>
</tr>
<tr>
<td>
<table width="65%" border="2">
<tr>
<td>
<asp:UpdatePanel ID="UpdatePanel1" runat="server" UpdateMode="Conditional">
<ContentTemplate>
Label within the Parent Update Panel
<asp:Label ID="Label1" runat="server" Font-Bold="true"></asp:Label>
<br />
<br />
<asp:Button ID="Button1" runat="server" Text="Refresh" />
<table width="40%" border="1">
<tr>
<td>
<asp:UpdatePanel ID="UpdatePanel2" runat="server" UpdateMode="Conditional">
<ContentTemplate>
<br />
<br />
Label within the Child Update Panel
<asp:Label ID="Label2" runat="server" Font-Bold="True"></asp:Label>
<br />
<br />
<asp:Button ID="Button2" runat="server" Text="Refresh" />
</ContentTemplate>
</asp:UpdatePanel>
</td>
</tr>
</table>
</ContentTemplate>
</asp:UpdatePanel>
</td>
</tr>
</table>
</td>
</tr>
</table>
</div>
</form>

Code behind
protected void Page_Load(object sender, EventArgs e){
Label1.Text = System.DateTime.Now.ToString();
Label2.Text = System.DateTime.Now.ToString();
Label3.Text = System.DateTime.Now.ToString(); }
When you run the above page, you will notice that the label outside the Update Panels, the parent update panel contents and the child update panel contents.
When you click on the top most button, it refreshes the whole page and subsequently, all the labels get refreshed with the new date time.
However, when you click on the second refresh button which is marked inside the Parent Update Panel you will notice that the top most label doesnt get refreshed but both the Label 2 and Label 3 gets refreshed, although I have marked UpdateMode as conditional for the Child UpdatePanel. The reason being, the parent updates all the child update panels nested within.
Finally, when you click on the last Refresh button which is marked inside the Child Update Panel, you will notice that only the respective label gets refreshed.
Note that, if I remove the property UpdateMode=Conditional for the UpdatePanel1 (parent), both the labels will get refreshed.