net faqs 4

What are different methods of session maintenance in ASP.NET?
3 types:
In-process storage.
Session State Service.
Microsoft SQL Server.

In-Process Storage
The default location for session state storage is in the ASP.NET process itself.

Session State Service
As an alternative to using in-process storage for session state, ASP.NET provides the ASP.NET State Service. The State Service gives you an out-of-process alternative for storing session state that is not tied quite so closely to ASP. Net's own process.

To use the State Service, you need to edit the sessionState element in your ASP.NET application’s web.config file:
You’ll also need to start the ASP.NET State Service on the computer that you specified in the stateConnectionString attribute. The .NET Framework installs this service, but by default it’s set to manual startup. If you’re going to depend on it for storing session state, you’ll want to change that to automatic startup by using the Services MMC plug-in in the Administrative Tools group.

If you make these changes, and then repeat the previous set of steps, you’ll see slightly different behavior: session state persists even if you recycle the ASP.NET process.

There are two main advantages to using the State Service. First, it is not running in the same process as ASP.NET, so a crash of ASP.NET will not destroy session information. Second, the stateConnectionString that’s used to locate the State Service includes the TCP/IP address of the service, which need not be running on the same computer as ASP.NET. This allows you to share state information across a web garden (multiple processors on the same computer) or even across a web farm (multiple servers running the application). With the default in-process storage, you can’t share state information between multiple instances of your application.

The major disadvantage of using the State Service is that it’s an external process, rather than part of ASP.NET. That means that reading and writing session state is slower than it would be if you kept the state in-process. And, of course, it’s one more process that you need to manage. As an example of the extra effort that this can entail, there is a bug in the initial release of the State Service that allows a determined attacker to crash the ASP.NET process remotely. If you’re using the State Service to store session state, you should install the patch from Microsoft Security Bulletin MS02-66, or install SP2 for the .NET Framework.

Microsoft SQL Server
The final choice for storing state information is to save it in a Microsoft SQL Server database. To use SQL Server for storing session state, you need to perform several setup steps:

Run the InstallSqlState.sql script on the Microsoft SQL Server where you intend to store session state. This script will create the necessary database and database objects. The .NET Framework installs this script in the same folder as its compilers and other tools–for example, C:\WINNT\Microsoft.NET\Framework\v1.0.3705 on a Windows 2000 computer with the 1.0 version of the Framework. Edit the sessionState element in the web.config file for your ASP.NET application as follows:

Supply the server name, user name, and password for a SQL Server account that has access to the session state database in the sqlConnectionString attribute.
Like the State Service, SQL Server lets you share session state among the processors in a web garden or the servers in a web farm. But you also get the additional benefit of persistent storage. Even if the computer hosting SQL Server crashes and is restarted, the session state information will still be present in the database, and will be available as soon as the database is running again. That’s because SQL Server, being an industrial-strength database, is designed to log its operations and protect your data at (almost) all costs. If you’re willing to invest in SQL Server clustering, you can keep the session state data available transparently to ASP.NET even if the primary SQL Server computer crashes.

Like the State Service, SQL Server is slower than keeping session state in process. You also need to pay additional licensing fees to use SQL Server for session state in a production application. And, of course, you need to worry about SQL Server-specific threats such as the “Slammer” worm.

What is Viewstate?
A server control’s view state is the accumulation of all its property values. In order to preserve these values across HTTP requests, ASP.NET server controls use this property, which is an instance of the StateBag class, to store the property values.

Can any object be stored in a Viewstate?
An object that either is serializable or has a TypeConverter defined for it can be persisted in ViewState

What should you do to store an object in a Viewstate?
Do serialization of convert the object to string

Explain how Viewstate is being formed and how it’s stored on client.
The type of ViewState is System.Web.UI.StateBag, which is a dictionary that stores name/value pairs. ViewState is persisted to a string variable by the ASP.NET page framework and sent to the client and back as a hidden variable. Upon postback, the page framework parses the input string from the hidden variable and populates the ViewState property of each control. If a control uses ViewState for property data instead of a private field, that property automatically will be persisted across round trips to the client. (If a property is not persisted in ViewState, it is good practice to return its default value on postback.)

What do you know about ADO.NET’s objects and methods?
ADO.NET provides consistent access to data sources such as Microsoft SQL Server, as well as data sources exposed through OLE DB and XML.
Data-sharing consumer applications can use ADO.NET to connect to these different data sources and retrieve, manipulate, and update data.
ADO.NET provides first-class support for the disconnected, n-tier programming environment for which many new applications are written.

Explain DataSet.AcceptChanges and DataAdapter.Update methods.
DataAdapter.Update method Calls the respective INSERT, UPDATE, or DELETE statements for each inserted, updated, or deleted row in the DataSet.
DataSet.AcceptChanges method Commits all the changes made to this row since the last time AcceptChanges was called.

When we go for html server controls and when we go for web server controls?
Server controls are a part of ASP.net. When a server control is used there will be an extra overhead on the server to create the control at runtime and accordingly set the values. HTML controls are static controls and are easy to use. They are supported is ASP.net.
As a rule, if there is a corresponding HTML control available instead of the server control, you should always go for the HTML control as it enhances the server performance and ensures faster response. Server controls should be used when it is found that the available HTML controls are not sufficient to achieve the task.