1. What are the advantages and  disadvantages of viewstate?

The primary advantages of the ViewState feature in ASP.NET are:

1. Simplicity. There is no need to write possibly complex code to store form data between page submissions.
2. Flexibility. It is possible to enable, configure, and disable ViewState on a control-by-control basis, choosing to persist the values of some fields but not others.

There are, however a few disadvantages that are worth pointing out:

1. Does not track across pages. ViewState information does not automatically transfer from page to page. With the session
approach, values can be stored in the session and accessed from other pages. This is not possible with ViewState, so storing
data into the session must be done explicitly.

2. ViewState is not suitable for transferring data for back-end systems. That is, data still has to be transferred to the back
end using some form of data object.

2. What is the difference between Server.Transfer and Response.Redirect? Why would I choose one over the other?

Server.Transfer() : client is shown as it is on the requesting page only, but the all the content is of the requested page. Data can be persist accros the pages using Context.Item collection, which is one of the best way to transfer data from one page to another keeping the page state alive.

Response.Dedirect() : client know the physical location (page name and query string as well). Context.Items loses the persisitance when nevigate to destination page. In earlier versions of IIS, if we wanted to send a user to a new Web page, the only option we had was Response.Redirect. While this method does accomplish our goal, it has several important drawbacks. The biggest problem is that this method causes each page to be treated as a separate transaction. Besides making it difficult to maintain your transactional integrity, Response.Redirect introduces some additional headaches. First, it prevents good encapsulation of code. Second, you lose access to all of the properties in the Request object. Sure, there are workarounds, but they're difficult. Finally, Response.Redirect necessitates a round trip to the client, which, on high-volume sites, causes scalability problems. As you might suspect, Server.Transfer fixes all of these problems. It does this by performing the transfer on the server without requiring a roundtrip to the client.

3. Is it necessary to lock application state before accessing it?

Only if you're performing a multistep update and want the update to be treated as an atomic     operation. Here's an example:

                Application.Lock ();
                Application["ItemsSold"] = (int) Application["ItemsSold"] + 1;
                Application["ItemsLeft"] = (int) Application["ItemsLeft"] - 1;
                Application.UnLock ();

By locking application state before updating it and unlocking it afterwards, you ensure  that another request being processed on another thread doesn't read application state   at exactly the wrong time and see an inconsistent view of it. If I update session state, should I lock it, too? Are concurrent accesses by multiple requests executing on multiple threads a concern with session state? Concurrent accesses aren't an issue with session state, for two reasons. One, it's unlikely that two requests from the same user will overlap. Two, if they do overlap, ASP.NET locks down session state during request processing so that two threads can't touch it at once. Session state is locked down when the HttpApplication instance that's processing the request fires an AcquireRequestState event and unlocked when it fires a ReleaseRequestState event.

4. Do ASP.NET forms authentication cookies provide any protection against replay attacks? Do they, for example, include the client's IP  address or anything else that would distinguish the real client from an attacker?

No. If an authentication cookie is stolen, it can be used by an attacker. It's up to you to     prevent this from happening by using an encrypted communications channel (HTTPS). Authentication cookies issued as session cookies, do, however,include a time-out valid that     limits their lifetime. So a stolen session cookie can only be used in replay attacks as long as the ticket inside the cookie is valid. The default time-out interval is 30 minutes.You can change that by modifying the timeout attribute accompanying the <forms> element in Machine.config or a local Web.config file. Persistent authentication cookies do not  time-out and therefore are a more serious security threat if stolen.

5. What does the "EnableViewState" property do? Why would I want it on or off?

Enable ViewState turns on the automatic state management feature that enables server controls to re-populate their values on a round trip without requiring you to write any code. This feature is not free however, since the state of a control is passed to and from the server in a hidden form field. You should be aware of when ViewState is helping you and when it is not. For example, if you are binding a control to data on every round trip, then you do not need the control to maintain it's view state, since you will wipe out any re-populated data in any case. ViewState is enabled for all server controls by default. To disable it, set the EnableViewState property of the control to false.

6. Can you give an example of what might be best suited to place in the Application_Start and Session_Start subroutines?

The Application_Start event is guaranteed to occur only once throughout the lifetime of the application. It's a good place to initialize global variables. For example, you might want to retrieve a list of products from a database table and place the list in application state or the Cache object. SessionStateModule exposes both Session_Start and Session_End events.

7. What does aspnet_regiis -i do ?

Aspnet_regiis.exe is The ASP.NET IIS Registration tool allows an administrator or installation program to easily update the script maps for an ASP.NET application to point to the ASP.NET ISAPI version associated with the tool. The tool can also be used to display the status of all installed versions of ASP. NET, register the ASP.NET version coupled with the tool, create client-script directories, and perform other configuration operations.
When multiple versions of the .NET Framework are executing side-by-side on a single computer, the ASP.NET ISAPI version mapped to an ASP.NET application determines which version of the common language runtime is used for the application.

The tool can be launched with a set of optional parameters. Option "i" Installs the version of ASP.NET associated with Aspnet_regiis.exe and updates the script maps at the IIS metabase root and below. Note that only applications that are currently mapped to an earlier version of ASP.NET are affected.

8. What is validationsummary server control? where it is used?.

The ValidationSummary control allows you to summarize the error messages from all validation controls on a Web page in a single location. The summary can be displayed as a list, a bulleted list, or a single paragraph, based on the value of the DisplayMode property. The error message displayed in the ValidationSummary control for each validation control on the page is specified by the ErrorMessage property of each validation control. If the ErrorMessage property of the validation control is not set, no error message is displayed in the ValidationSummary control for that validation control. You can also specify a custom title in the heading section of the ValidationSummary control by setting the HeaderText property. You can control whether the ValidationSummary control is displayed or hidden by setting the ShowSummary property. The summary can also be displayed in a message box by setting the ShowMessageBox property to true.

9. Can you create an app domain?

Yes, We can create user app domain by calling on of the following overload static methods of the System.AppDomain class
1. Public static AppDomain CreateDomain(String friendlyName)
2. Public static AppDomain CreateDomain(String friendlyName, Evidence securityInfo)
3. Public static AppDomain CreateDomain(String friendlyName, Evidence securityInfo, AppDomainSetup info)
4. Public static AppDomain CreateDomain(String friendlyName, Evidence securityInfo, String appBasePath, String appRelativeSearchPath, bool shadowCopyFiles)

10. What is the difference between Server.Transfer and Response.Redirect? Why would I choose one over the other?

In earlier versions of IIS, if we wanted to send a user to a new Web page, the only option we had was Response.Redirect. While this method does accomplish our goal, it has several important drawbacks. The biggest problem is that this method causes each page to be treated as a separate transaction. Besides making it difficult to maintain your transactional   integrity, Response.Redirect introduces some additional headaches. First, it prevents good encapsulation of code. Second, you lose access to all of the properties in the Request  object. Sure, there are workarounds, but they're difficult. Finally, Response.Redirect  necessitates a round trip to the client, which, on high-volume sites, causes scalability problems.
As you might suspect, Server.Transfer fixes all of these problems. It does this by performing the transfer on the server without requiring a roundtrip to the client.