Implement Impersonation:

Impersonate the Microsoft IIS Authenticated Account or User:
To impersonate the IIS authenticating user on every request for every page in an ASP.NET application, we must include an tag in the Web.config file of this application and set the impersonate attribute to true.
<identity impersonate="true" />

Impersonate a Specific User:
To impersonate a specific user for all the requests on all pages of an ASP.NET application, you can specify the userName and password attributes in the tag of the Web.config file for that application.
<identity impersonate="true" userName="AccountNAME" password="Password" />

Impersonation

Impersonation is the process of executing code in the context of another user identity. By default, all ASP.NET code is executed using a fixed machine-specific account. To execute code using another identity we can use the built-in impersonation capabilities of ASP.NET. We can use a predefined user account or user's identity, if the user has already been authenticated using a windows account.

We can use the impersonation in this two scenarios:

1. To give each web application different permissions.
2. To use existing Windows user permission.

These two scenario are fundamentally different. In the first one, impersonation defines a single, specific account. In this case, no matter what user access the application, and no matter what type of user-level security you use, the code will run under the account you've set. In the second one, the user must be authenticated by IIS. The web-page code will then execute under the identity of the appropriate user.

Advantages of AppDomain

A single CLR operating system process can contain multiple application domains. There are advantages to having application domains within a single process.

1. Lower system cost - many application domains can be contained within a single system process.
2. Each application domain can have different security access levels assigned to them, all within a single process.
3. Code in one AppDomain cannot directly access code in another AppDomain.
4. The application in an AppDomain can be stopped without affecting the state of another AppDomain running in the same process.
5. An Exception in on AppDomain will not affect other AppDomains or crash the entire process that hosts the AppDomains.

Application Domain

Asp.Net introduces the concept of an Application Domain which is shortly known as AppDomain. It can be considered as a Lightweight process which is both a container and boundary. The .NET runtime uses an AppDomain as a container for code and data , just like the operating system uses a process as a container for code and data. As the operating system uses a process to isolate misbehaving code, the .NET runtime uses an AppDomain to isolate code inside of a secure boundary.

The CLR can allow the multiple .Net applications to be run in a single AppDomain.

The CLR isolates each application domain from all other application domains and prevents the configuration, security, or stability of a running .NET applications from affecting other applications.An AppDomain can be destroyed without effecting the other Appdomains in the process.

Mulitple Appdomains can exist in Win32 process. As we discussed the main aim of AppDomain is to isolate applications from each other and the process is same as the working of operating system process. This isolation is achieved by making sure than any given unique virtual address space runs exactly one application and scopes the resources for the process or application domain using that address space.

Win32 processes provide isolation by having distinct memory addresses. The .Net runtime enforces AppDomain isolation by keeping control over the use of memory. All memory in the App domain is managed by the run time so the runtime can ensure that AppDomains Do not access each others memory.

In what scenarios we go for session management in outproc?

Payment Gateway

How many ways the session state management can be done?

State Management is a process of maintaining the state of the control or variable after page postback from server or between pages. In Asp.Net we are having many ways to maintain the state management. Basically it is dividied into server side and client side state management. Depends on the resource that we have to plan. They are as follows....
1. Session state
2. Hidden Variables
3. Query String
4. Cookies
5. ViewState
6. Caching
Out of which session state and caching are server side state management. others are client side state management.

Compilation techniques in .net

• In-place compilation This option performs the same compilation that occurs during dynamic compilation. Use this option to compile a Web site that has already been deployed to a production server.
• Non-updateable full precompilation Use this to compile an application and then copy the compiled output to the production server. All application code, markup, and UI code is compiled into assemblies. Placeholder files such as .aspx pages still exist so that you can perform file-specific tasks such as configure permissions, but the files contain no updateable code. In order to update any page or any code you must precompile the Web site again and deploy it again.
• Updateable precompilation This is similar to non-updateable full precompilation, except that UI elements such as .aspx pages and .ascx controls retain all their markup, UI code, and inline code, if any. You can update code in the file after it has been deployed; ASP.NET will detect changes to the file and recompile it. Note that code in a code-behind file (.vb or .cs file) built into assemblies during precompilation, and you therefore cannot change it without going through the precompilation and deployment steps again.