Anonymous Methods.

An anonymous method is a method without a name - which is why it is called anonymous. You don't declare anonymous methods like regular methods. Instead they get hooked up directly to events.

>> Because you can hook an anonymous method up to an event directly, a couple of the steps of working with delegates can be removed.

>> An anonymous method uses the keyword, delegate, instead of a method name. This is followed by the body of the method. Typical usage of an anonymous method is to assign it to an event.

By using anonymous methods, you reduce the coding overhead in instantiating delegates because you do not have to create a separate method.

Example:

       Button btnHello = new Button();
        btnHello.Text = "Hello";

        btnHello.Click +=
            delegate
            {
                MessageBox.Show("Hello");
            };

        Controls.Add(btnHello);

Using Parameters with Anonymous Methods:

        Button btnHello = new Button();
        btnHello.Text = "Hello";

        btnHello.Click +=
            delegate
            {
                MessageBox.Show("Hello");
            };

        Button btnGoodBye = new Button();
        btnGoodBye.Text = "Goodbye";
        btnGoodBye.Left = btnHello.Width + 5;
        btnGoodBye.Click +=
            delegate(object sender, EventArgs e)
            {
                string message = (sender as Button).Text;
                MessageBox.Show(message);
            };

        Controls.Add(btnHello);
        Controls.Add(btnGoodBye);

What is impersonation?

Impersonation is commonly used in applications that rely on Microsoft Internet Information Services (IIS) to authenticate the user.   


you must include an tag in the Web.config file of this application and set the impersonate attribute to true. For example:

configuration
  system.web
    identity impersonate="true"
  system.web
configuration

When impersonation is enabled, only your application code runs under the context of the impersonated user. Applications are compiled and configuration information is loaded using the identity of the ASP.NET process.

You can also add support for specific names to run an application as a configurable identity, as shown in the following example:

  
identity impersonate="true"   userName="contoso\Jane"   password="********" 

What is Jagged Arrays?

A jagged array is an array whose elements are arrays. The elements of a jagged array can be of different dimensions and sizes. A jagged array is sometimes called an "array of arrays." The following examples show how to declare, initialize, and access jagged arrays.

int[][] jaggedArray = new int[3][];

Before you can use jaggedArray, its elements must be initialized.

You can initialize the elements like this: 

jaggedArray[0] = new int[5];
jaggedArray[1] = new int[4];
jaggedArray[2] = new int[2];

Each of the elements is a single-dimensional array of integers. The first element is an array of 5 integers, the second is an array of 4 integers, and the third is an array of 2 integers.
It is also possible to use initializers to fill the array elements with values, in which case you do not need the array size. For example:

jaggedArray[0] = new int[] { 1, 3, 5, 7, 9 };
jaggedArray[1] = new int[] { 0, 2, 4, 6 };
jaggedArray[2] = new int[] { 11, 22 };

What is difference between constants and read-only?

Constant variables are declared and initialized at compile time. The value can’t be changed after wards.

Read-only variables will be initialized only from the Static constructor of the class. Read only is used only when we want to assign the value at run time.

What are generics in C#.NET?

1. Generics are used to make reusable code classes to decrease the code redundancy,

2. Increase type safety and performance.

3. Using generics, we can create collection classes.

4. To create generic collection, System.Collections.Generic namespace should be used instead of classes such as ArrayList in the System.Collections namespace. Generics promotes the usage of parameterized types.

Difference between Throw and Throw ex in c#?

Exception bubbling means that even though you are catching the exception and doing something with it, you want that exception to "bubble" up from your code to the calling code so it has a chance to do something with that exception. This is a fairly common scenario, but it has the potential to cause some major problems when you are debugging.


Throw Ex: (Stack trace information lost)

 The original stack trace info gets overwritten. So you loose original exceptions's stack trace as only the last point from which the exception was thrown is available.

   1: try

   2: {

   3:     // do some operation that can fail

   4: }

   5: catch (Exception ex)

   6: {

   7:     // do some local cleanup

   8:     throw ex;

   9: }

In this case, the stack trace is truncated below the method that failed. What this means is that when you look at the stack trace, it will look as if the exception originated in your code. This isn't always the case, particularly if you are bubbling up a CLR generated exception (like a SqlException). This is a problem known as "breaking the stack", because you no longer have the full stack trace information. 
  
Throw: (Stack trace information preserved)

   1: try

   2: {

   3:     // do some operation that can fail

   4: }

   5: catch (Exception ex)

   6: {

   7:     // do some local cleanup

   8:     throw;

   9: }

 Throw, on the other hand retains the stack trace with the original point of exception available.


It is always advised to use “throw” because it provides more accurate error information.

Recommendations for Abstract Classes vs. Interfaces

1. If you anticipate creating multiple versions of your component, create an abstract class. Abstract classes provide a simple and easy way to version your components. By updating the base class, all inheriting classes are automatically updated with the change. 
2. Interfaces, on the other hand, cannot be changed once created. If a new version of an interface is required, you must create a whole new interface.
3. If you are designing small, concise bits of functionality, use interfaces.
4. If you are designing large functional units, use an abstract class.

When to prefer an interface ( Interfaces are more used to set standards.)

Back when I wrote about the importance of composition, I mentioned that it is extremely useful when you don’t want a massive hierarchical type framework. The same applies to interfaces. This isn’t my example, but its the best one Ive come across. Lets say you have an interface for a Director and another interface for a Actor.

public interface Actor{
   Performance say(Line l);
}

public interface Director{
   Movie direct(boolean goodmovie);
}

In reality, there are Actors who are also Directors. If we are using interfaces rather than abstract classes, we can implement both Actor and Director. We could even define an ActorDirector interface that extends both like this:

public interface ActorDirector extends Actor, Director{
...
}

We could achieve the same thing using abstract classes. Unfortunately the alternative would require up to 2^n (where n is the number of attributes) possible combinations in order to support all possibilities.

When to prefer an Abstract class

Abstract classes allow you to provide default functionality for the subclasses. Common knowledge at this point. Why is this extremely important though? If you plan on updating this base class throughout the life of your program, it is best to allow that base class to be an abstract class. Why? Because you can make a change to it and all of the inheriting classes will now have this new functionality.

If the base class will be changing often and an interface was used instead of an abstract class, we are going to run into problems. Once an interface is changed, any class that implements that will be broken.