Asp.

net-Basic

AS P.NE T 4 Page Directives

ASP.NET directives are something that is a part of every ASP.NET page. You can
control the behavior of your ASP.NET pages by using these directives. Here is an
example of the Page directive:
<%@ Page Language="VB" AutoEventWireup="false" CodeFile="Default.aspx.vb"
Inherits="_Default" %>

Page
The @Page directive enables you to specify attributes and values for an ASP.NET
page (.aspx) to be used when the page is parsed or compiled. This is the most
frequently used directive of the bunch. Because the ASP.NET page is such an
important part of ASP.NET, you have quite a few attributes at your disposal.

@Control

The @Control directive is similar to the @Page directive except that @Control is
used when you build an ASP.NET user control. The @Control directive allows you to
define the properties to be inherited by the user control. These values are assigned
to the user control as the page is parsed and compiled

@Master
The @Master directive is quite similar to the @Page directive except that the
@Master directive is meant for master pages (.master). In using the @Master
directive, you specify properties of the templated page that you will be using in
conjunction with any number of content pages on your site. Any content pages
(built using the @Page directive) can then inherit from the master page all the
master content (defined in the master page using the @Master directive). Although
they are similar, the @Master directive has fewer attributes available to it than does
the @Page directive.

@Import
The @Import directive allows you to specify a namespace to be imported into the
ASP.NET page or user control. By importing, all the classes and interfaces of the
namespace are made available to the page or user control. This directive supports
only a single attribute: Namespace.
The Namespace attribute takes a String value that specifies the namespace to be
imported. The @Import directive cannot contain more than one attribute/value pair.
Because of this, you must place multiple namespace imports in multiple lines as
shown in the following example:
<%@ Import Namespace="System.Data" %>
<%@ Import Namespace="System.Data.SqlClient" %>

@Implements
The @Implements directive gets the ASP.NET page to implement a specified .NET
Framework interface. This directive supports only a single attribute: Interface.
The Interface attribute directly specifies the .NET Framework interface. When the
ASP.NET page or user control implements an interface, it has direct access to all its
events, methods, and properties.

@Register
The @Register directive associates aliases with namespaces and class names for
notation in custom server control syntax. You can see the use of the @Register
directive when you drag and drop a user control onto any of your .aspx pages.
Dragging a user control onto the .aspx page causes Visual Studio 2010 to create a
@Register directive at the top of the page. This registers your user control on the
page so that the control can then be accessed on the .aspx page by a specific
name.

Page Life cycle

If you create an ASP.NET 4 page and turn on tracing, you can see the order in which
the main page events
are initiated. They are fired in the following order:
1. PreInit
2. Init
3. InitComplete
4. PreLoad
5. Load
6. LoadComplete
7. PreRender
8. PreRenderComplete
9. Unload
With the addition of these choices, you can now work with the page and the controls
on the page at many different points in the page-compilation process.

Dealing with Postbacks

When you are working with ASP.NET pages, be sure you understand the page
events just listed.
They are important because you place a lot of your page behavior inside these
events at specific points in a page lifecycle.
In Active Server Pages 3.0, developers had their pages post to other pages within
the application. ASP.NET pages typically post back to themselves to process events
(such as a button-click event).
For this reason, you must differentiate between posts for the first time a page is
loaded by the end user and postbacks. A postback is just that — a posting back to
the same page. The postback contains all the form information collected on the
initial page for processing if required.Because of all the postbacks that can occur
with an ASP.NET page, you want to know whether a request is the first instance for
a particular page or is a postback from the same page You can make this check by
using the IsPostBack property of the Page class

Cross-Page Posting

One common feature in ASP 3.0 that is difficult to achieve in ASP.NET 1.0/1.1 is the
capability to do crosspage posting. Cross-page posting enables you to submit a
form (say, Page1.aspx) and have this form and all the control values post
themselves to another page (Page2.aspx).

AS P.NE T Application Folders

App_Code Folder
The App_Code folder is meant to store your classes, .wsdl files, and typed datasets.
Any of these items stored in this folder are then automatically available to all the
pages within your solution. The nice thing about the App_Code folder is that when
you place something inside this folder, Visual Studio 2010 automatically detects this
and compiles it if it is a class (.vb or .cs), automatically creates your XML Web
service
proxy class (from the .wsdl file), or automatically creates a typed
dataset for you from your .xsd files. After the files are automatically
compiled, these items are then instantaneously available to any of your
ASP.NET pages that are in the same solution. Look at how to employ a
simple class in your solution using the App_Code folder.
Everything placed in the App_Code folder is compiled into a single assembly. The
class files placed within the App_Code folder are not required to use a specific
language. This means that even if all the pages of the solution are written in Visual
Basic 2010, the Calculator class in the App_Code folder of the solution can be built
in C# (Calculator.cs).
Because all the classes contained in this folder are built into a single assembly, you
cannot have classes of different languages sitting in the root App_Code folder, as in
the following example:

\App_Code

Calculator.cs
AdvancedMath.vb

Having two classes made up of different languages in the App_Code folder (as
shown here) causes an error to be thrown. It is impossible for the assigned compiler
to work with two different languages. Therefore, to be able to work with multiple
languages in your App_Code folder, you must make some changes to the folder
structure and to the web.config file.
The first step is to add two new subfolders to the App_Code folder — a VB folder and
a CS folder. This gives you the following folder structure:
\App_Code
\VB
Add.vb
\CS
Subtract.cs
App_Data Folder
The App_Data folder holds the data stores utilized by the application. It is a good
spot to centrally store all the data stores your application might use. The App_Data
folder can contain Microsoft SQL Express files (.mdf files), Microsoft Access files
(.mdb files), XML files, and more.

App_Themes Folder

Themes are a way of providing a common look-and-feel to your site across every
page. You implement a theme by using a .skin file, CSS files, and images used by
the server controls of your site. All these elements can make a theme, which is then
stored in the App_Themes folder of your solution. By storing these elements within
the App_Themes folder, you ensure that all the pages within the solution can take
advantage of the theme and easily apply its elements to the controls and markup of
the page.

App_GlobalResources Folder
Resource files are string tables that can serve as data dictionaries for your
applications when these applications require changes to content based on things
such as changes in culture. You can add Assembly Resource Files (.resx) to the
App_GlobalResources folder, and they are dynamically compiled and made part of
the solution for use by all your .

App_LocalResources Folder

Even if you are not interested in constructing application-wide resources using the
App_GlobalResources folder, you may want resources that can be used for a
single .aspx page. You can do this very simply by using the App_LocalResources
folder.
You can add resource files that are page-specific to the App_LocalResources folder
by constructing the name of the .resx file in the following manner:

➤➤ Default.aspx.resx
➤➤ Default.aspx.fi.resx
➤➤ Default.aspx.ja.resx
➤➤ Default.aspx.en-gb.resx

App_WebReferences Folder
The App_WebReferences folder is a new name for the previous Web References
folder that was used in versions of ASP.NET prior to ASP.NET 3.5. Now you can use
the App_WebReferences folder and haveautomatic access to the remote Web
services referenced from your application.

App_Browsers Folder

The App_Browsers folder holds .browser files, which are XML files used to identity
the browsers making requests to the application and understanding the capabilities
these browsers have. You can find a list of globally accessible .browser files at C:\
Windows\Microsoft.NET\Framework\v4.0.xxxxx\Config\
Browsers. In addition, if you want to change any part of these default browser
definition files, just copy the appropriate .browser file from the Browsers folder to
your application’s App_Browsers folder andchange the definition

Compilation

You already saw how Visual Studio 2010 compiles pieces of your application as you
work with them (for instance, by placing a class in the App_Code folder). The other
parts of the application, such as the .aspx pages, can be compiled just as they were
in earlier versions of ASP.NET by referencing the pages in the browser.When an
ASP.NET page is referenced in the browser for the first time, the request is passed
to the ASP.NETparser that creates the class file in the language of the page. It is
passed to the ASP.NET parser based on thefile’s extension (.aspx) because ASP.NET
realizes that this file extension type is meant for its handling and processing. After
the class file has been created, the class file is compiled into a DLL and then written
to the disk of the Web server. At this point, the DLL is instantiated and processed,
and an output is generated for the initial requester of the ASP.NET page.

On the next request, great things happen. Instead of going through the entire
process again for the second and respective requests, the request simply causes an
instantiation of the already-created DLL, which sends out a response to the
requester

Build Providers

As you review the various ASP.NET folders, note that one of the more interesting
folders is the App_Code folder. You can simply drop code files, XSD files, and even
WSDL files directly into the folder for automatic compilation. When you drop a class
file into the App_Code folder, the class can automatically be utilized by a running
application. In the early days of ASP.NET, if you wanted to deploy a custom
component, you had to precompile the component before being able to utilize it
within your application. Now ASP.NET simplytakes care of all the work that you once
had to do. You do not need to perform any compilation routine