ASP.NET 2.0

MSIL supports OO programming, so we can have a class which has public and private methods. The entry point of the program needs to be specified. In fact it doesn't really matter whether the method is called Mam or Dad. The only thing that matters here is that .entrypoint is specified inside the method. MSIL programs are compiled with ilasm compiler. Since we are writing a managed assembly code, we have to make sure that no variables are allocated in memory when the program goes out of scope. Here is a more complicated program that, once again, does not do anything but has some dataThe sample MSIL program.method static void main(){ .entrypoint .maxstack 1 ldstr "Hello world!" call void [mscorlib]System.Console::WriteLine(string) ret}

Viewstate has lots of advantages and as well as disadvantages, so you need to weigh carefully before making the decision to use it. As view state doesnt require any server resources for its operation. It is passed to the client during every postback as an hidden element. Since it is added with every page, it adds few Kbytes to the page. This effects the loading of the page in the client. Other main problem with Viewstate is, since it is passed as plain text to the client. Anybody can tamper this value, because of this you shouldnt store any important data in the viewstate. View state is one of the most important features of ASP.NET, not so much because of its technical relevance, but more because it makes the magic of the Web Forms model possible. However, if used carelessly, view state can easily become a burden. Although ViewState is freely accessible in a hidden field called __VIEWSTATE, the view state information is not clear text. By default, a machine-specific authentication code is calculated on the data and appended to the view state string. The resulting text is then Base64 encoded only, but not encrypted. In order to make the view state more secure, the ASP.NET @Page directive supports an attribute called EnableViewStateMac whose only purpose is detecting any possible attempt at corrupting original data.

ORELSE - Either of the two expressions is true. If the first expression is True, the second is not evaluated. - ex. are from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vblr7/html/valrfOrElseOperator.asp

Dim A As Integer = 10

Dim B As Integer = 8

Dim C As Integer = 6

Dim myCheck As Boolean

myCheck = A > B OrElse B > C ' True. Second expression is not evaluated.

myCheck = B > A OrElse B > C ' True. Second expression is evaluated.

myCheck = B > A OrElse C > B ' False.

If MyFunction(5) = True OrElse MyOtherFunction(4) = True Then

' If MyFunction(5) is True, MyOtherFunction(4) is not called.

' Insert code to be executed.

End If

ANDALSO -

Instead of doing thisIf(Function1() And Function2()) ThenDo thisIf(Function1() AndAlso Function2()) ThenThe first code will evaluate the result of Function2(), even if Function1() returned false.The second will only evaluate Function2() if Function1() returned true.

Differneces between Single Call & Singleton.Single Call objects service one and only one request coming in. Single Callobjects are useful in scenarios where the objects are required to do afinite amount of work. Single Call objects are usually not required tostore state information, and they cannot hold state information betweenmethod calls. However, Single Call objects can be configured in aload-balanced fashion.Singleton objects are those objects that service multiple clients and henceshare data by storing state information between client invocations. Theyare useful in cases in which data needs to be shared explicitly betweenclients and also in which the overhead of creating and maintaining objectsis substantial.

1. Basically for a SAO, the lifetime of the object is controlled by server, whereas for a CAO, the lifetime is controlled by the client.Below are definitions from MSDN. Server activated objects includes Single Call & Singleton.Single Call objects service one and only one request coming in. Single Callobjects are useful in scenarios where the objects are required to do afinite amount of work. Single Call objects are usually not required tostore state information, and they cannot hold state information betweenmethod calls. However, Single Call objects can be configured in aload-balanced fashion.Singleton objects are those objects that service multiple clients and henceshare data by storing state information between client invocations. Theyare useful in cases in which data needs to be shared explicitly betweenclients and also in which the overhead of creating and maintaining objectsis substantial.Client-activated objects (CAO) are server-side objects that are activatedupon request from the client. This way of activating server objects is verysimilar to the classic COM coclass activation. When the client submits arequest for a server object using "new" operator, an activation requestmessage is sent to the remote application. The server then creates aninstance of the requested class and returns an ObjRef back to the clientapplication that invoked it. A proxy is then created on the client sideusing the ObjRef. The client's method calls will be executed on the proxy.Client-activated objects can store state information between method callsfor its specific client and not across different client objects. Eachinvocation of "new" returns a proxy to an independent instance of theserver type.

A DiffGram is an XML format that is used to identify current and original versions of data elements. The DataSet uses the DiffGram format to load and persist its contents, and to serialize its contents for transport across a network connection. When a DataSet is written as a DiffGram, it populates the DiffGram with all the necessary information to accurately recreate the contents, though not the schema, of the DataSet, including column values from both the Original and Current row versions, row error information, and row order.When sending and retrieving a DataSet from an XML Web service, the DiffGram format is implicitly used. Additionally, when loading the contents of a DataSet from XML using the ReadXml method, or when writing the contents of a DataSet in XML using the WriteXml method, you can select that the contents be read or written as a DiffGram

To provide individual data for a user during a session, data can be stored with session scope. In the following sample, values for user preferences are initialized in the Session_Start event in the Global.asax file.Sub Session_Start() Session("BackColor") = "beige" ...End Sub'======================================================================In the following sample a file is read in Application_Start (defined in the Global.asax file) and the content is stored in a DataView object in the application state.Sub Application_Start() Dim ds As New DataSet() Dim fs As New FileStream(Server.MapPath("schemadata.xml"),FileMode.Open,FileAccess.Read) Dim reader As New StreamReader(fs) ds.ReadXml(reader) fs.Close() Dim view As New DataView (ds.Tables(0)) Application("Source") = viewEnd Sub

The web is a stateless medium - state is not maintained between client requests by default. Technologies must be utilized to provide some form of state management if this is what is required of your application, which will be the case for all but the simplest of web applications. ASP.NET provides several mechanisms to manage state in a more powerful and easier to utilize way than classic ASP.

Page level state is information maintained when an element on the web form page causes a subsequent request to the server for the same page - referred to as 'postback'. This is appropriately called ViewState as the data involved is usually, though not necessarily, shown to the user directly within the page output.

The Control.ViewState property is associated with each server control in your web form and provides a dictionary object for retaining values between such multiple requests for the same page. This is the method that the page uses to preserve page and control property values between round trips.

When the page is processed, the current state of the page and controls is hashed into a string and saved in the page as a hidden field. When the page is posted back to the server, the page parses the view state string at page initialization and restores property information in the page.

ViewState is enabled by default so if you view a web form page in your browser you will see a line similar to the following near the form definition in your rendered HTML:

ViewState offers a substantial improvement over the two competing techniques for state management via the client: standard hidden fields and cookies, in that ViewState is not limited to the storage of simple values. You can use ViewState to store any object as long as it is serializable, and the standard VB.NET types are. Serialization is the process of storing an object's data and other information necessary to reconstruct the object later.