Thread State Diagram

Thread State Diagram:

















Regards,
Arun..

Page Life Cycle and Control Loading

Page Life Cycle and Control Loading

Here in this article emphasis is on

§ How Page Loading along with the Control Hierarchy loading occurs hand in hand.

§ In which phase the controls are completely created & initialized with their Default values & Post back values.

§ How View state comes in picture.

· For this read the article ‘Myth regarding View State’

http://msdn2.microsoft.com/en-us/library/ms972976.aspx

For Digramatic View - http://arun-ts.blogspot.com/search/label/Diagrams

For View State Myth - http://arun-ts.blogspot.com/2007/04/myth-regarding-view-state_13.html

We’ll go thru below phases.

Stage 0 – Instantiation –

Creates The Page's Control Hierarchy & Assigns the decalrative properties to the Web Controls.

§ When the life cycle of the ASP.NET page begins, ASP.NET engine Instantiates an Auto-Generates Class that represents the requested ASP.NET Web page.

§ The purpose of this autogenerated class is to programmatically create the Page's Control Hierarchy. i.e Programmatically creating the Web controls specified in the page's HTML portion.

§ This is done by translating the HTML portion into a series of Programmatically-Created Web controls. i.e Translating—<asp:WebControlName Prop1="Value1" ... />—into the class's programming language.

§ In addition to the Web control syntax being converted into the appropriate code, the HTML markup present in the ASP.NET Web page's HTML portion is translated to Literal controls.

§ If you created your ASP.NET Web page using the code-behind technique, this autogenerated class is derived from the page's associated code-behind class [System.Web.Ui.Page].

§ In either case, this autogenerated class, along with a compiled instance of the class, is stored in the WINDOWS\Microsoft.NET\Framework\version\Temporary ASP.NET Files folder, in part so that it Doesn't Need To Be Recreated for each page request.

§ When the control hierarchy is constructed, the properties that are explicitly set in the declarative syntax of the Web control are assigned in the code.

Stage 1 – Initialization

§ After the control hierarchy has been built, in this the Page and its controls fire their Init events.

§ With regards to view state it is important for two reasons.

· First, server controls don't begin tracking view state changes until right at the end of the initialization stage.

· Second, when adding dynamic controls that need to utilize view state, these controls will need to be added during the Page's Init event as opposed to the Load event.

Stage 2 - Load View State

§ The load view state stage only happens when the page has been posted back.

§ During this stage, the view state data that had been saved from the previous page visit is loaded and recursively populated into the control hierarchy of the Page.

Stage 3 - Load Postback Data

§ The load postback data stage also only happens when the page has been posted back.

§ A server control can indicate that it is interested in examining the posted back data by implementing the IPostBackDataHandler interface

Stage 4 - Load

§ This is the stage with which all ASP.NET developers are familiar

Stage 5 - Raise Postback Event

§ There are two flavors of postback events.

· Changed event - DropDownLists SelectedIndexChanged event, or the TextBox's TextChanged event

· Raised event - Button Web control Click, Calendar control VisibleMonthChanged event

Stage 6 - Save View State

§ In the save view state stage, the Page class constructs the page's view state, which represents the state that must persist across postbacks.

Stage 7 - Render

§ In the render stage the HTML that is emitted to the client requesting the page is generated.

§ The Page class accomplishes this by recursively invoking the RenderControl() method of each of the controls in its hierarchy.

Thanks & Regards,

Arun Manglick || Tech Lead

Control Hierarchy

Below is the explanation of - How Control are loaded and initialized along with the Page life Cycle.

Note- This all happens before the 'Init' phase of the Page Life Cycle. i.e It happens in the 'Initialization' phase.

Imagine you have an ASP.NET Web page with the following HTML portion:













When this page is first visited, a class will be autogenerated that contains code to programmatically build up the control hierarchy. The control hierarchy for this example can be seen as below.














This control hierarchy is then converted to code that is similar to the following:






















When the control hierarchy is constructed, the properties that are explicitly set in the declarative syntax of the Web control are assigned in the code. (For example, the Button Web control has its Text property set to "Submit!" in the declarative syntax – Text="Submit!" – as well as in the autogenerated class—Button1.Text = "Submit!";.

Regards,
Arun Manglick

Attributes to consider while defining Web Method

Attributes to consider while defining Web Method

The 6 properties of the WebMethod attribute are as follows:

§ BufferResponse

§ CacheDuration

§ Description

§ EnableSession

§ MessageName

§ TransactionOption

BufferResponse

§ This property is used to determine if the Web Service Response will be buffered.

§ True -

· ASP.NET buffers the entire response after serializing and before sending it to the client.

· Very efficient and helps improve performance by minimizing communication.

· Use when small amounts of data is sent to the client.

§ False –

· Response to the XML Web service method is sent back to the client as it is serialized.

· Use when large amounts of data is sent to the client.

[WebMethod (BufferResponse=true)]

CacheDuration

§ This property allows caching a web service result for a specified period of time (mentioned as seconds).

§ There are two issues that can affect output caching in an ASP.NET 2.0 Web service application.

· In ASP.NET 2.0 the HTTP method of the test page has changed from GET to POST. However, POSTs are not normally cached. If you change the test page in an ASP.NET 2.0 Web service application to use GET, caching works properly.

· In addition, HTTP indicates that a user agent (the browser or calling application) should be able to override server caching by setting the "Cache-Control" to "no-cache". ASP.NET applications, therefore, ignore cached results when they find a "no-cache" header.

[WebMethod (CacheDuration=60)]

[WebMethod(CacheDuration=5)]

public string CreateContentURL(int mediaId, string userIP, int format, int provider, string type)

{

return DateTime.Now.Second.ToString() + ":" + DateTime.Now.Millisecond.ToString();

}

Description

§ This property provides a brief description to the web method.

[WebMethod (Description =”<Anything>”)]

EnableSession

§ HTTP is a stateless protocol. EnableSession property helps to maintain session state between server and the client.

§ In order for an XML Web service to maintain session state for a client, the client must persist the cookie. Clients can receive the HTTP cookie by creating a new instance of CookieContainer and assigning that to the CookieContainer property of the proxy class before calling the XML Web service method.

§ If you need to maintain session state beyond when the proxy class instance goes out of scope, the client must persist the HTTP cookie between calls to the XML Web service. For instance, a Web Forms client can persist the HTTP cookie by saving the CookieContainer in its own session state.

[WebMethod (EnableSession = true)]

void EnterBtn_Click(Object Src, EventArgs E)

{

ServerUsage su = new ServerUsage();

CookieContainer cookieJar;

// Check to see if the cookies have already been saved for this session.

if (Session["CookieJar"] == null)

cookieJar= new CookieContainer();

else

cookieJar = (CookieContainer) Session["CookieJar"];

// Assign the CookieContainer to the proxy class.

su.CookieContainer = cookieJar;

// Invoke an XML Web service method that uses session state and thus cookies.

int count = su.PerSessionServiceUsage();

// Store the cookies received in the session state for future retrieval by this session.

Session["CookieJar"] = cookieJar;

// Populate the text box with the results from the call to the XML Web service method.

SessionCount.Text = count.ToString();

}

TransactionOption

§ The transaction options supported by the TransactionOption property are listed below:

§ Disabled

§ NotSupported

§ Supported

§ Required

§ RequiresNew

Thanks & Regards,

Arun Manglick || Tech Lead

Method Overloading in Web Services

Method Overloading in Web Services

By default Web Services do not support ‘Method Overloading’.

Reason:

When data is passed to an XML Web service it is sent in a request and when it is returned it is sent in a response. Therefore, if an XML Web service contains two or more XML Web service methods with the same name, no uniquely identification will be there. Hence it will produce error.

Solution: To resolve this, MessageName property is required to be attached to Web Method - To uniquely identify polymorphic methods.

public class Calculator : WebService

{

[WebMethod]

public int Add(int i, int j) {

return i + j;

}

[WebMethod(MessageName="Add2")]

public int Add(int i, int j, int k) {

return i + j + k;

}

}

This works perfectly well in .Net 1.x. But in .Net 2.0 this solution solves only one problem. The other problem is related to the ‘Conformity to WS-I Basic Profile v1.1’.

Reason: In .Net 2.0, by default below two attributes are added to the Web Service Class.

[WebService(Namespace = "http://tempuri.org/")]

[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

public class Service : System.Web.Services.WebService

{

}

This line indicates that your webservice conforms to the Web Services Interopability Organization's (WS-I) Baisc Profile 1.1. The Basic Profile defines a set of rules to which your webservice must conform.

One of its rules is that the webservice May Not Include Method Overloading. If you run a webservice that uses method overloading, you will receive an errormessage telling that your service is not conform to WS-I Basic Profile v1.1:

This produces below error once you have equiped the ‘Web Method’ with ‘MessageName’ property.

Solution: To resolve this error, modify the attribute as:

[WebService(Namespace = "http://tempuri.org/")]

[WebServiceBinding(ConformsTo = WsiProfiles.None)]

Complete Code:

[WebService(Namespace = "http://tempuri.org/")]

[WebServiceBinding(ConformsTo = WsiProfiles.None)]

public class Service : System.Web.Services.WebService

{

public Service () {

}

[WebMethod]

public string HelloWorld()

{

return "hello";

}

[WebMethod(MessageName = "HelloWorld2")]

public string HelloWorld(int i)

{

return "Overloading";

}

}

This will work fine as below:

Thanks & Regards,

Arun Manglick || Tech Lead

DLL/PDB file generation in ASP.Net

http://odetocode.com/Blogs/scott/archive/2005/11/15/2464.aspx

Debug and release builds are based on two things

§ .Net 1.x / .Net 2.0

§ Project Type [ Class Library / Web Site/ Web Service]

1.x

§ In 1.x, you can decide whether you need the build in ‘Debug’ or ‘Release’ mode by using the Build -> Configuration Manager menu option.

§ This works for all three type of projects viz. Class Library, Web Project and Web Service.

§ Class Library

o Debug Mode – bin\Debug\ClassLibrary1.dll and bin\Debug\ClassLibrary1.pdb

o Release Mode - bin\ Release \ClassLibrary1.dll [No .pdb is generated]

o

§ Web Project /Web Service

o Debug Mode – bin\Debug\ WebApplication1.dll and bin\Debug\ WebApplication1.dll.pdb

o Release Mode - bin\Debug\ WebApplication1.dll

M. Imp - Though the build in ‘Release’ mode can be decided thru Build -> Configuration Manager, however it is important to set debug=”false” along with ‘Release’ configuration in web.config to produce a true production ‘Release’ build in 1.x.

2.0

§ .Net 2.0 behaves almost different to the .Net 1.x approach.

§ For class library projects whether you need the build in ‘Debug’ or ‘Release’ mode is decided by using the Build -> Configuration Manager menu option. However .pdb files still gets created in the ‘Release’ mode as well.

§ But for Web Site/Web Services – Something different happens as below.

§ The most important concept to come to terms with in 2.0: Visual Studio 2005 knows nothing about compiling a web application and it delegates all compilation responsibilities to the ASP.NET platform.

§ When you ask Visual Studio to build a web project, nothing seems to happen. We don’t get the comforting feeling of having a bin directory with a .dll file inside. This is because ASP.NET performs the build and not Visual Studio.

§ ASP.NET builds everything, including .cs and .vb code files. Instead of creating ‘bin’ directlory with a .dll file inside, ASP.NET places all the resulting assemblies in a folder underneath the Temporary ASP.NET files directory [C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files].

§ Because ASP.NET does all of the compilation, the debug setting in the compilation section of web.config controls debug or release mode. Compile with debug=”true” and you’ll find the .pdb debugging symbol files alongside each assembly.

§ This new compilation model makes the Configuration Manager for a web site obsolete. The only option appearing in a Visual Studio 2005 web site “project” is a Debug configuration. Don’t fret – it means nothing. The web.config file now rules the school.

Class Library

o Debug Mode – bin\Debug\ClassLibrary1.dll and bin\Debug\ClassLibrary1.pdb

o Release Mode - bin\ Release \ClassLibrary1.dll and bin\ Release \ClassLibrary1.pdb [Yes .pdb is also generated in ‘Release’ Mode as well.]

§ Web Project /Web Service

o Debug Mode – Check Temporary ASP.NET files directory

o Release Mode – Check Temporary ASP.NET files directory

Summary

.Net 1.x –

§ For all types of projects - Build in ‘Debug/Release’ mode can be decided thru Build -> Configuration Manager.

.Net 2.0 –

§ For Class Library Projects - Build in ‘Debug/Release’ mode can be decided thru Build -> Configuration Manager

§ For WebSite/Web Services - Build in ‘Debug/Release’ mode can be decided thru Web.config.

Publish Web Site-

§ Publish will always precompile a Release build without debugging symbols.

§ The Publish command [Build -> Publish] does not change the debug setting in web.config. The Publish command always compiles for “Release”.

§ However, if you precompile to an updateable web site, and then update the web site in place (which results in dynamic compilations), those dynamic compilations will produce debug code and pdb files.

Thanks & Regards,

Arun Manglick || Tech Lead