ViewState - Dynamic Controls

The first fact that you should know about dynamic controls is that they should be added to the page at each and every page execution. Never wrap the code that initializes and adds the dynamic control to the page inside a “!IsPostback” condition. The reason is that since the control is dynamic, it is not included in the compiled class generated for the page. So, the control should be added at every page execution for it to be available in the final control tree. The second fact is that dynamic controls play “catch-up” with the page life cycle once they are added. Say, you did the following:

Label lbl = new Label();
Page.Controls.Add(lbl);

Once the control is added to the “Controls” collection, it plays “catch-up” with the page life cycle, and all the events that it missed are fired. This leads to a very important conclusion: you can add dynamic controls at any time during the page life cycle until the “PreRender” event. Even when you add the dynamic control in the “PreRender” event, once the control is added to the “Controls” collection, the “Init”, “LoadViewState”, “LoadPostbackdata”, “Load”, and “SaveViewstate” are fired for this control. This is called “catch-up”. Note though that it is recommended that you add your dynamic controls during the “PreInit” or “Init” events. This is because it is best to add controls to the control tree before tracking of the Viewstate of other controls is enabled…

Finally, what is the best practice for adding dynamic controls regarding Viewstate? Let us say that you want to add a Label at runtime and assign a value to its “Text” property. What is the best practice to do so? If you are thinking the below, then you are mistaken:

Label lbl = new Label();
Page.Controls.Add(lbl);
lbl.Text = "bad idea";

You are mistaken because using the above technique you are actually storing the value of the “Text” property in the Vewstate. Why? Because, recall that once a dynamic control is added to the “Controls” collection, a “catch-up” happens and the tracking for the Viewstate starts. So, setting the value of the “Text” property will cause the value to be stored in the Viewstate.

However, if you do the below, then you are thinking the right way, because you are setting the “Text” property before adding the control to the “Controls” collection. In this case, the value of the “Text” property is added with the control to the control tree and not persisted in Viewstate.

Label lbl = new Label();
lbl.Text = "good idea";
Page.Controls.Add(lbl);

Reducing ViewState - Disabling ViewState

Disabling Viewstate would obviously reduce Viewstate size; but, it surely kills the functionality along the way. So, a little more planning is required…

Consider the case where you have a page with a drop down list that should display the countries of the world. On the “Page_Load” event handler, you bind the drop down list to a data source that contains the countries of the world; the code that does the binding is wrapped inside a “!IsPostback” condition. Finally, on the page, you have a button that when clicked should read the selected country from the drop down list. With the setup described above, you will end up with a large __VIEWSTATE field. This is due to the fact that data bound controls (like the drop down list) store their state inside the Viewstate. You want to reduce Viewstate; what options do you have?

1. Option 1: Simply disable the Viewstate on the drop down list
   
2. Option 2: Disable the Viewstate on the drop down list, and remove the “!IsPostback” condition
   
3. Option 3: Disable the Viewstate on the drop down list, and move the binding code without the “!IsPostback” condition to the “OnInit” or “OnPreInit” event handlers
   

If you implement Option 1, you will reduce the Viewstate alright, but with it, you will also lose the list of countries on the first postback of the page. When the page first loads, the code in the “Page_Load” event handler is executed and the list of countries is bound to the list. However, because Viewstate is disabled on the list, this change of state is not saved during the “SaveViewState” event. When the button on the page is clicked causing a postback, since the binding code is wrapped inside a “!IsPostback” condition, the “LoadViewState” event has nothing saved from the previous page visit and the drop down list is empty. If you implement Option 2, you will reduce the Viewstate size and you will not lose the list of countries on postback. However, another problem arises: because the binding code is now executed at each “Page_Load”, the postback data is lost upon postback, and every time, the first item of the list will be selected. This is true because in the page life cycle, the “LoadPostbackdata” event occurs before the “Load” event. Option 3 is the correct option. In this option, you have done the following:

• Disabled Viewstate on the drop down list
  
• Removed the “!IsPostback” condition from the binding code
  
• Moved the binding code to the “OnInit” event handler (or the “OnPreInit” event handler)
  

Since the “Init” event occurs before the “LoadPostbackdata” in the page life cycle, the postback data is preserved upon postbacks, and the selected item from the list is correctly preserved.

Now, remember that in Option 3, you have successfully reduced the Viewstate size and kept the functionality working; but, this actually comes at the cost of rebinding the drop down list at each postback. The performance hit of revisiting the data source at each postback is nothing when compared with the performance boost gained from saving a huge amount of bytes being rendered at the client’s __VIEWSTATE field. This is especially true with the fact that most clients are connected to the Internet via low speed dial up connections.

ASP.NET Page Life Cycle Demonstration

Let us take an example ASP.NET page with the following characteristics:

• It contains a single Label control (lbl) with its “Text” property set to “statictext”
  
• It contains a Button control (btnA) with code in its event handler that sets the “Text” property of “lbl” to “dynamictext”
  
• It contains a Button control (btnB) whose purpose is to cause a page postback
  

Now, let us examine what will happen during the page life cycle.

1. The page is first loaded
   
   
   
   1. The compiled class of the page is generated and “statictext” is assigned to “lbl.Text”
      
   2. Tracking for Viewstate is enabled in the “InitComplete” event
      
   3. “LoadViewState” is not fired because there is no postback
      
   4. “SaveViewstate” is fired, but nothing happens because no change of state is recorded
      
   5. The page is rendered with the value “statictext” inside “lbl”
      
   
   
2. btnA is clicked
   
   
   
   1. The previously generated compiled class is handed the request; “lbl.Text” is set to “statictext”
      
   2. Tracking for Viewstate is enabled
      
   3. “LoadViewState” is fired, but nothing happens because no change of state was recorded in the previous page visit
      
   4. “RaisePostbackEvent” event is executed and “btnA” click event handler is fired; “lbl.Text” is set to “dynamictext”; since tracking is enabled at this stage, this item is tracked (marked as “Dirty”).
      
   5. “SaveViewState” is fired; “dynamictext” is serialized and stored in the __VIEWSTATE field
      
   6. The page is rendered with the value “dynamictext” inside “lbl”
      
   
   
3. btnB is clicked
   
   
   
   1. The previously generated compiled class is handed the request; “lbl.Text” is set to “statictext”
      
   2. Tracking for Viewstate is enabled
      
   3. “LoadViewState” is fired; since a change of state was recorded from the previous page visit, __VIEWSTATE is loaded and the value “dynamictext” is extracted; this value is then assigned to “lbl”
      
   4. “RaisePostbackEvent” event is executed; nothing happens here because “btnB” has no event handler for its “Click” event
      
   5. “SaveViewState” is fired, but nothing happens because no change of state is recorded
      
   6. The page is rendered with the value “dynamictext” inside “lbl”
      
   
   

What is an Application Pool?

When you run IIS 6.0 in worker process isolation mode, you can separate different Web applications and Web sites into groups known as application pools. An application pool is a group of one or more URLs that are served by a worker process or set of worker processes. Any Web directory or virtual directory can be assigned to an application pool.

Every application within an application pool shares the same worker process. Because each worker process operates as a separate instance of the worker process executable, W3wp.exe, the worker process that services one application pool is separated from the worker process that services another. Each separate worker process provides a process boundary so that when an application is assigned to one application pool, problems in other application pools do not affect the application. This ensures that if a worker process fails, it does not affect the applications running in other application pools.

Use multiple application pools when you want to help ensure that applications and Web sites are confidential and secure. For example, an enterprise organization might place its human resources Web site and its finance Web site on the same server, but in different application pools. Likewise, an ISP that hosts Web sites and applications for competing companies might run each companys Web services on the same server, but in different application pools. Using different application pools to isolate applications helps prevent one customer from accessing, changing, or using confidential information from another customers site.

In HTTP.sys, an application pool is represented by a request queue, from which the user-mode worker processes that service an application pool collect the requests. Each pool can manage requests for one or more unique Web applications, which you assign to the application pool based on their URLs. Application pools, then, are essentially worker process configurations that service groups of namespaces.
Multiple application pools can operate at the same time. An application, as defined by its URL, can only be served by one application pool at any time. While one application pool is servicing a request, you cannot route the request to another application pool. However, you can assign applications to another application pool while the server is running.

what is difference between a website and a web application?

A website is typically available to the public and contains information, images, documents and links. A web application is interactive software that runs within the framework of the website. For example, Google is a website. Searching on Google however is a web application, or mapping on Google is a web application.

Web applications are often linked to databases to capture or display data via a webpage. The key is that the applications can run in a web browser, preferably without installing any other software, and preferably without having to modify firewall or security settings to run.

Difference between batchfiles and windows scripts

BatchFiles are scripts tooooooo. They let u script a series of tasks, run programs, etc.
1.The major limitation is that they only let us startup programs and dont provide a way to interact with objects.They work at the level of whole programs and files.
2.Scripting is a more and modern approach for windows automation.
3.Scripting languages have the advantages of using control stuctures like loops and decision structures, which the batch script lacks.