What are page directives?
The first line of an ASP.NET page is the page directive; you will find it on all ASP.NET pages. These directives are instructions for the page. It begins with the @Page directive and continues with the various attributes available to this directive.
It’s unreasonable to expect a candidate to know all of these attributes, but a few popular ones include the following.
AutoEventWireup: Indicates whether page events are autowired.
CodeBehind: The name of the compiled class associated with the page.
Debug: Indicates whether the page is compiled in debug mode (includes debug symbols).
EnableTheming: Indicates whether themes are used on the page.
EnableViewState: Indicates whether view state is maintained across pages.
ErrorPage: Specifies a target URL to be used when unhandled exceptions occur.
Language: Indicates the language used when compiling inline code on the page.
Trace: Signals whether tracing is enabled on the page.
What is a master page?
A master page is a template for one or more Web Forms. The master page defines how the page will be laid out when presented to the user, with placeholders for content. The MasterPageFile Page Directive in a content page’s header is one way to assign a master page. The content pages rely solely on content and leave layout to the master page. ASP.NET merges the content with the master page layout when the content page is requested by a user.
What is the code behind feature of ASP.NET?
The code behind feature divides ASP.NET page files into two files where one defines the user interface (.aspx), while the other contains all of the logic or code (.aspx.cs for C# and .aspx.vb for VB.NET). These two files are glued together with page directives like the following line, which ties the page to the specific code behind class.
<![CDATA[<%@ Page language="c#" Codebehind="UICode.cs" Inherits="Library.UICode" %>
What are ASHX files?
ASP.NET Web handler files have an .ashx file extension. Web handlers work just like .aspx files except you don’t have to deal with the browser interface, thus no worrying about presentation. Web handlers are generally used to generate content dynamically like returning XML or an image. Web handlers use the IHttpHandler interface with the ProcessRequest() method invoked when the handler is requested. Web handlers are simpler than pages (fewer events and wiring), so they are ideal for performance-critical applications.
How does PostBack work?
How can you pass values between ASP.NET pages?
There are numerous ways to accomplish this task; the option you choose depends on the environment. The oldest way to approach it is via the QueryString (i.e., passing values via URL); this is also one of the least secure ways because users can easily see the data and could possibly hack the site/page by changing parameter values. Next, you can use HTTP POST to pass values; these are available via a collection within the ASP.NET page. More specific to ASP.NET is the use of Session state, which makes information available to all pages within the ASP.NET application. Another approach is using public properties on the source page and accessing these properties on the target page. Also, you can use the PreviousPage property of the current page to access control information on the referring page. The last two require the source, and target pages are within the same ASP.NET application.
What are ASP.NET Server controls?
ASP.NET includes a number of built-in server controls that are the foundation of its Web programming model. They have various properties to control their behavior and appearance. These controls provide an event model where events are handled on the server (whereas HTML controls are handled in the client). Server controls have the ability to maintain state (via ViewState) across requests, and they can automatically detect the browser. With these controls, you will see the RunAt attribute (RunAt=”Server”) that signals its processing will be done on the server. A good example of these controls is the basic TextBox control (<asp:textbox runat="”Server”" xmlns:asp="#unknown">.
What is View State?
Basically, View State is how ASP.NET Web pages persists data across requests. It handles data that must be preserved between postbacks, and you can use it to store page-specific data. By default, View State is enabled on a page and its controls. This can be a problem as the amount of data and controls on a page increases resulting in more data for ASP.NET to maintain. This is accomplished via the hidden __VIEWSTATE field on a form (look at the page source in a browser), so more data in this field means a slower load time and slower overall processing, as it has to be posted to the server each time. You can limit the size of the data in View State by disabling controls that do not need to be persisted via the EnableViewState property. View State can be encrypted to address security concerns.
What is the global.asax file?
The global.asax file is an optional piece of an ASP.NET application. It is located in the root of the application directory structure. It cannot be directly loaded or requested by users. It provides a place to define application- and session-wide events. You can define your own events, but it does contain default Application events like when the application starts Application_Start and ends with Application_End. The same is true for Session events (Session_Start and Session_End).
How can you loop through all controls on an ASP.NET Web form?
You can easily traverse all controls on a form via the Web Form’s Controls collection. The GetType method can be used on each control to determine its type and how to work with it. Now, it gets tricky because the form contains a tree of controls; that is, some controls are contained within others (think of a Table). You would have to recursively loop through the controls to make sure everything is processed.
What is a web.config file? Machine.config?
The web.config is the basic configuration file for ASP.NET applications. It utilizes an XML format. It is used to define application settings, connection strings, and much more. These files can appear in multiple directories, and they are applied in a top-down approach; that is, configuration files apply to their container directory as well as all directories below it, but the configuration files in lower directories can override those in parent directories. This provides a way to granularly apply settings. The machine.config file contains ASP.NET settings for all of the applications on the server — it is at the top of the configuration file hierarchy, thus web.configs can override it.