.Net Interview Questions
1. Explain the differences between Server-side and Client-side code?
2. What type of code (server or client) is found in a Code-Behind class?
3. Should validation (did the user enter a real date) occur server-side or client-side? Why?
4. What does the "EnableViewState" property do? Why would I want it on or off?
5. What is the difference between Servers? Transfer and Response. Redirect? Why would I choose one over the other?
6.Can you give an example of when it would be appropriate to use a web service as opposed to a non-serviced .NET component
7.Let's say I have an existing application written using Visual Studio 6 (VB 6, InterDev 6) and this application utilizes Windows 2000 COM+ transaction services. How would you approach migrating this application to .NET
8.Can you explain the difference between an ADO.NET Dataset and an ADO Recordset?
9. Can you give an example of what might be best suited to place in the Application Start and Session Start subroutines?
10. If I'm developing an application that must accommodate multiple security levels though secure login and my ASP.NET web application is spanned across three web-servers (using round-robin load balancing) what would be the best approach to maintain login-in state for the users?
What is the difference between ADO and ADO.NET?
ADO uses Recordsets and cursors to access and modify data. Because of its inherent design, Recordset can impact performance on the server side by tying up valuable resources. In addition, COM marshalling - an expensive data conversion process - is needed to transmit a Recordset. ADO.NET addresses three important needs that ADO doesn't address: 
1. Providing a comprehensive disconnected data-access model, which is crucial to the Web environment
2. Providing tight integration with XM
3. Providing seamless integration with the .NET Framework (e.g., compatibility with the base class library's type system). From an ADO.NET implementation perspective, the Recordset object in ADO is eliminated in the .NET architecture. In its place, ADO.NET has several dedicated objects led by the DataSet object and including the DataAdapter, and DataReader objects to perform specific tasks. In addition, ADO.NET DataSets operate in disconnected state whereas the ADO RecordSet objects operated in a fully connected state.
In ADO, the in-memory representation of data is the RecordSet. In ADO.NET, it is the dataset. A RecordSet looks like a single table. If a RecordSet is to contain data from multiple database tables, it must use a JOIN query, which assembles the data from the various database tables into a single result table. In contrast, a dataset is a collection of one or more tables. The tables within a dataset are called data tables; specifically, they are DataTable objects. If a dataset contains data from multiple database tables, it will typically contain multiple DataTable objects. That is, each DataTable object typically corresponds to a single database table or view. In this way, a dataset can mimic the structure of the underlying database.
In ADO you scan sequentially through the rows of the RecordSet using the ADO MoveNext method. In ADO.NET, rows are represented as collections, so you can loop through a table as you would through any collection, or access particular rows via ordinal or primary key index. A cursor is a database element that controls record navigation, the ability to update data, and the visibility of changes made to the database by other users. ADO.NET does not have an inherent cursor object, but instead includes data classes that provide the functionality of a traditional cursor. For example, the functionality of a forward-only, read-only cursor is available in the ADO.NET DataReader object.
There is one significant difference between disconnected processing in ADO and ADO.NET. In ADO you communicate with the database by making calls to an OLE DB provider. In ADO.NET you communicate with the database through a data adapter (an OleDbDataAdapter, SqlDataAdapter, OdbcDataAdapter, or OracleDataAdapter object), which makes calls to an OLE DB provider or the APIs provided by the underlying data source.
