What Great .NET Developers Ought To Know (Part Four ASP.NET (UI) Developers)

This is getting longer and longer. Some questions are rather like a small insight reseach than a simple Q&A. I will re-org some of them later to be a stand alone post.

Part Four ASP.NET (UI) Developers (I)

Describe how a browser-based Form POST becomes a Server-Side event like Button1_OnClick.
In Web server controls, certain events, typically click events, cause the form to be posted back to the server. An event is a message, "Button1_Click". The binding between the event message and a specific method — that is, an event handler — is done using an event delegate. In the following code snippet, an (object of) event delegate EventHandler is instantiated, it binds the event handler - btnNext_Click method to the event btnNext.Click (message).

// the binding
private void InitializeComponent(){
//
this.Load += new System.EventHandler(this.Page_Load);
this.btnNext.Click += new System.EventHandler(this.btnNext_Click);
}
// an event handler
private void btnNext_Click(object sender, System.EventArgs e){}

What is a PostBack?
Postback means a web page (contains web request) is submitted to itself on the web server. ASP.NET page object model uses PostBack on event handling.

What is ViewState? How is it encoded? Is it encrypted? Who uses ViewState?
VIEWSTATE is a set or string of encoded data stored in a hidden form field to to preserve data between round trips to and from the server. ViewState automatically preserves property values of the page, and the values of all controls on the page, between round trips. Data stored in VIEWSTATE is base-64 encoded.
Pointers: Understanding ASP.NET View State

What is the <machinekey>element and what two ASP.NET technologies is it used for?
Machine Authentication Check(MAC): Machine authentication checks are designed to ensure that the data received by a computer is the same data that it transmitted out. This can be done by using <machinekey>.
<machinekey>configures key to use for encryption and decryption of forms authentication cookie data and view state data, and for verification of out-of-process session state identification. This section can be declared at the machine (machine.config), site, and application levels (web.config), but not at the subdirectory level.

<configuration><system.web></a><machinekey validation="SHA1\\MD53\\DES" decryptionkey="AutoGeneratevalue[,IsolateApps]" validationkey="AutoGeneratevalue[,IsolateApps]">

What three Session State providers are available in ASP.NET 1.1? What are the pros and cons of each?

<sessionState mode="InProc StateServer SQLServer />

InProc Session values are kept as live objects in the memory of the ASP.NET worker process (aspnet_wp.exe or w3wp.exe in Microsoft® Windows Server™ 2003). This is the default option.
Pros: Fastest. Cons: Not scalable (web garden/farm); performance hit as memory required, state lives short, less robust.

Pros on out-of-proc: fully scalable; state lives longer; protected against IIS and ASP.Net failure; Cons: Slower than InProc due to serialization and de-serialization to/from storage medium. StateServer add at least 15%, SQLServer add at least 25% performance drop compares to InProc).

StateServer Session values are serialized and stored in the memory of a separate process (aspnet_state.exe). The process can also run on another machine.
Pros: fastest Out-of-Proc solution; easy administration. Cons: not as fast as InProc; not as robust as SQLServer.

SQLServer Session values are serialized and stored in a Microsoft® SQL Server™ table. The instance of SQL Server can run either locally or remotely.
Pros: more robust than StateServer.
Cons: Slowest.
Pointers: Underpinnings of the Session State Implementation in ASP.NET

What is Web Gardening? How would using it affect a design?
The ASP.NET process model helps enable scalability on multiprocessor computers by distributing work to several processes, one per CPU, each with processor affinity set to its CPU. This technique is called Web Gardening. This technique is particularly useful for applications that rely extensively on external resources, for example: slow database server or calls COM objects that have external dependencies.

Web gardening is not suitable for heavy stateful applications. Web gardening enables multiple worker processes (one per CPU participating in the web garden) to run at the same time. All processes will have their own copy of application state, in-process session state, ASP.NET cache, static data etc, and all that is needed to run applications. The more stateful applications are, the more they risk to pay in terms of real performance of web gardening.

Beyond the questions:
The Web garden model is configurable through the <processmodel>section of the machine.config file.

Notice that the <processmodel> section is the only configuration section that cannot be placed in an application-specific web.config file. This means that the Web garden mode applies to all applications running on the machine.

However, by using the &l;tlocation> node in the machine.config source, you can adapt machine-wide settings on a per-application basis.

<processmodel webgarden="[truefalse]" cpumask="[bit mask]">

Pointer: The ASP.NET HTTP Runtime
Given one ASP.NET application, how many application objects does it have on a single proc box? A dual? A dual with Web Gardening enabled? How would this affect a design?
The term ‘Application object’ is vague here. If we are talking about ASP.NET worker process (aspnet_wp.exe or w3wp.exe) it is one per CPU. On a Dual CPU box without enabling web gardening, it is still one worker process. If web gardening is enabled for all CPUs, one worker process is created per CPU.

If we are talking about HttpApplication object here, it has nothing to do with number of the CPUs in a box. ASP.NET worker process creates a number of AppDomains, isolated by the virtual directory or web application. Each AppDomain has an HttpApplication object pool. An individual HttpApplication object is created to handle each simultaneous HTTP request. However number of the objects in the HttpApplication pool is not configurable. Neither number of AppDomains (sure too many active web apps on a box will slow it down).

Pointer Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication

Are threads reused in ASP.NET between reqeusts? Does every HttpRequest get its own thread? Should you use Thread Local storage with ASP.NET?
Aha, just partly answered this question above. Each HTTP request is served by an HttpApplication object, which is pooled. Threads are reused.
Thread Local storage(TLS) provides a mechanism to store data that is unique to a thread and whose value is determined at run time. This type of storage can be very helpful when dealing with an existing multithreaded application whose interfaces or original design are too inflexible for passing these values another way.
Using TLS in a thread pooling environment can be very tricky. One should not use TLS on ASP.NET application. You never know on what thread you might be called (inside an ISAPI DLL), so using TLS for anything other than tracking resources that are explicitly bound to a particular thread is a bad idea.

Is the [ThreadStatic] attribute useful in ASP.NET? Are there side effects? Good or bad?
The conext: how to share static fields on per thread scope in opposite to per AppDomain scope?
The question itself doesn't make sense. The value that needs to be shared should be tied to a specific request, not a specific thread. To do this you can use the System.Web.HttpContext.Current.Items collection.
[ThreadStatic] is the managed equivalent of TLS in ASP.NET. It should be used when you can control the threadpool and the lifecycle of a thread (but you can’t achieve this easily, can you?) ThreadStatic gives you thread local storage, not HttpContext local storage!
It needs to be very careful on using [ThreadStatic] . Static fields marked with ThreadStaticAttribute are not shared between threads. Each executing thread has a separate instance of the field, and independently sets and gets values for that field. If the field is accessed on a different thread, it will contain a different value. And this is deemed to happen due to thread agile in ASP.NET. ASP.NET not only uses a thread pool, but may switch threads during request processing. It makes thread local storage unreliable.
Pointers Storing things on Threads, A tale of two techniques: The [ThreadStatic] Attribute and System.Web.HttpContext.Current.Items, ThreadStatic FUD