The .NET Framework is divided into an almost painstaking collection of functional parts, with a
staggering total of more than 7,000
core programming ingredients). Before you can program any type of .NET application, you need a
basic understanding of those parts—and an understanding of why things are organized the way
they are.
The massive collection of functionality that the .NET Framework provides is organized in a way
that traditional Windows programmers will see as a happy improvement. Each one of the thousands
of classes in the .NET Framework is grouped into a logical, hierarchical container called a
Different namespaces provide different features. Taken together, the .NET namespaces offer
functionality for nearly every aspect of distributed development from message queuing to security.
This massive toolkit is called the
Interestingly, the way you use the .NET Framework classes in ASP.NET is the same as the way
you use them in any other type of .NET application (including a stand-alone Windows application,
a Windows service, a command-line utility, and so on). In other words, .NET gives the same tools to
web developers that it gives to rich client developers.
If you’ve programmed extensively with ASP.NET 1.
is available in ASP.NET 2.0. The difference is that ASP.NET 2.0 adds even more classes to the mix,
many in entirely new namespaces for features such as configuration, health monitoring, and
personalization.Fact 2: ASP.NET Is Compiled,Not Interpreted
One of the major reasons for performance degradation in ASP scripts is that all ASP web-page code
uses interpreted scripting languages. This means that when your application is executed, a scripting
host on the server machine needs to interpret your code and translate it to lower-level machine
code, line by line. This process is notoriously slow.ASP.NET applications are always compiled—in fact, it’s impossible to execute C# or VB .NET
code without it being compiled first.
ASP.NET applications actually go through two stages of compilation. In the first stage, the C#
code you write is compiled into an intermediate language called Microsoft Intermediate Language
(MSIL) code, or just IL. This first step is the fundamental reason that .NET can be languageinterdependent.
Essentially, all .NET languages (including C#, Visual Basic, and many more) are
compiled into virtually identical IL code. This first compilation step may happen automatically
when the page is first requested, or you can perform it in advance (a process known as
precompiling
The second level of compilation happens just before the page is actually executed. At this
point, the IL code is compiled into low-level native machine code. This stage is known as
). The compiled file with IL code is an assembly.just-intime (JIT) compilation, and it takes place in the same way for all .NET applications (including
Windows applications, for example). Figure 1-1 shows this two-step compilation process.
.NET compilation is decoupled into two steps in order to offer developers the most convenience
and the best portability. Before a compiler can create low-level machine code, it needs to
know what type of operating system and hardware platform the application will run on (for example,
32-bit or 64-bit Windows). By having two compile stages, you can create a compiled assembly
with .NET code but still distribute this to more than one platform.Fact 3: ASP.NET Is Multilanguage
Though you’ll probably opt to use one language over another when you develop an application,
that choice won’t determine what you can accomplish with your web applications. That’s because
no matter what language you use, the code is compiled into IL.
IL is a stepping-stone for every managed application. (A
that’s written for .NET and executes inside the managed environment of the CLR.) In a sense,
IL is
To understand IL, it helps to consider a simple example. Take a look at this function, written
in C#:
managed application is any applicationthe language of .NET, and it’s the only language that the CLR recognizes. namespace HelloWorld
{
public class TestClass
{
private static void Main(string[] args)
{
Console.WriteLine("Hello World");
}
}
}
This code shows the most basic application that’s possible in .NET—a simple command-line
utility that displays a single, predictable message on the console window.
CHAPTER 1
■ INTRODUCING ASP.NET 9 Now look at it from a different perspective. Here’s the IL code for the same class:
.method public static void Main() cil managed
{
.entrypoint
.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() =
( 01 00 00 00 )
// Code size 14 (0xe)
.maxstack 8
IL_0000: nop
IL_0001: ldstr "Hello World"
IL_0006: call void [mscorlib]System.Console::WriteLine(string)
IL_000b: nop
IL_000c: nop
IL_000d: ret
} // end of method Module1::Main
It’s easy enough to look at the IL for any compiled .NET application. You simply need to run the
IL Disassembler, which is installed with Visual Studio and the .NET SDK (software development kit).
Look for the file ildasm.exe in a directory like c:\Program Files\Visual Studio 2005\SDK\v2.0\Bin.
Once you’ve loaded the program, use the File
was created with .NET.
If you’re patient and a little logical, you can deconstruct the IL code fairly easily and figure
out what’s happening. The fact that IL is so easy to disassemble can raise privacy and code control
issues, but these issues usually aren’t of any concern to ASP.NET developers. That’s because all
ASP.NET code is stored and executed on the server. Because the client never receives the compiled
code file, the client has no opportunity to decompile it. If it
that scrambles code to try to make it more difficult to understand. (For example, an obfuscator
might rename all variables to have generic, meaningless names such as f__a__234.) Visual Studio
includes a scaled-down version of one popular obfuscator, called Dotfuscator.
The following code shows the same console application in Visual Basic code:
➤Open command, and select any DLL or EXE thatis a concern, consider using an obfuscator Namespace HelloWorld
Public Class TestClass
Private Shared Sub Main(Ars() As String)
Console.WriteLine("Hello World")
End Sub
End Class
End Namespace
If you compile this application and look at the IL code, you’ll find that every line is identical to
the IL code generated from the C# version. Although different compilers can sometimes introduce
their own optimizations, as a general rule of thumb no .NET language outperforms any other .NET
language, because they all share the same common infrastructure. This infrastructure is formalized
in the CLS (Common Language Specification), which is described in the “The Common Language
Specification” sidebar.
It’s important to note that IL was recently adopted as an ANSI (American National Standards
Institute) standard. This adoption could quite possibly spur the adoption of other common language
frameworks. The Mono project at Fact 4: ASP.NET Runs Inside the Common Language Runtime
Perhaps the most important aspect of ASP.NET to remember is that it runs inside the runtime
engine of the CLR. The whole of the .NET Framework—that is, all namespaces, applications, and
classes—are referred to as
the scope of this chapter, some of the benefits are as follows:
managed code. Though a full-blown investigation of the CLR is beyond Automatic memory management and garbage collection
an object, the CLR allocates space on the
never need to clear this memory manually. As soon as your reference to an object goes out of
scope (or your application ends), the object becomes available for garbage collection. The
garbage collector runs periodically inside the CLR, automatically reclaiming unused memory
for inaccessible objects. This model saves you from the low-level complexities of C++ memory
handling and from the quirkiness of COM reference counting.
: Every time your application instantiatesmanaged heap for that object. However, you Type safety
indicates details such as the available classes, their members, their data types, and so on. As a
result, your compiled code assemblies are completely self-sufficient. Other people can use
them without requiring any other support files, and the compiler can verify that every call is
valid at runtime. This extra layer of safety completely obliterates low-level errors such as the
infamous buffer overflow.
: When you compile an application, .NET adds information to your assembly that Extensible metadata
metadata that .NET stores in a compiled assembly.
you to provide additional information to the runtime or other services. For example, this metadata
might tell a debugger how to trace your code, or it might tell Visual Studio how to display a
custom control at design time. You could also use metadata to enable other runtime services
(such as web methods or COM+ services).
: The information about classes and members is only one of the types ofMetadata describes your code and allows Structured error handling
VBScript code, you’ll most likely be familiar with the limited resources these languages offer
for error handling. With structured exception handling, you can organize your error-handling
code logically and concisely. You can create separate blocks to deal with different types of
errors. You can also nest exception handlers multiple layers deep.
: If you’ve ever written any moderately useful Visual Basic or Multithreading
you can call methods, read files, or communicate with web services asynchronously, withoutFact 5: ASP.NET Is Object-Oriented
ASP provides a relatively feeble object model. It provides a small set of objects; these objects are
really just a thin layer over the raw details of HTTP and HTML. On the other hand, ASP.NET is truly
object-oriented. Not only does your code have full access to all objects in the .NET Framework, but
you can also exploit all the conventions of an OOP (object-oriented programming) environment.
For example, you can create reusable classes, standardize code with interfaces, and bundle useful
functionality in a distributable, compiled component.
One of the best examples of object-oriented thinking in ASP.NET is found in
Server-based controls are the epitome of encapsulation. Developers can manipulate control
objects programmatically using code to customize their appearance, provide data to display, and
even react to events. The low-level HTML details are hidden away behind the scenes. Instead of
forcing the developer to write raw HTML manually, the control objects render themselves to HTML
when the page is finished rendering. In this way, ASP.NET offers server controls as a way to abstract
server-based controls. 12
CHAPTER 1 ■ INTRODUCING ASP.NET Here’s a quick example with a standard HTML text box:
<input type="text" id="myText" runat="server" />
With the addition of the runat="server" attribute, this static piece of HTML becomes a fully
functional server-side control that you can manipulate in your code. You can now work with events
that it generates, set attributes, and bind it to a data source.
For example, you can set the text of this box when the page first loads using the following code:
void Page_Load(object sender, EventArgs e)
{
myText.Value = "Hello World!";
}
Technically, this code sets the Value property of an HtmlInputText object. The end result is that
a string of text appears in a text box on the HTML page that’s rendered and sent to the client.Fact 6: ASP.NET Is Multidevice and Multibrowser
One of the greatest challenges web developers face is the wide variety of browsers they need to
support. Different browsers, versions, and configurations differ in their support of HTML. Web
developers need to choose whether they should render their content according to HTML 3.2,
HTML 4.0, or something else entirely—such as XHTML 1.0 or even WML (Wireless Markup Language)
for mobile devices. This problem, fueled by the various browser companies, has plagued
developers since the World Wide Web Consortium proposed the first version of HTML. Life gets
even more complicated if you want to use an HTML extension such as JavaScript to create a more
dynamic page or provide validation.
ASP.NET addresses this problem in a remarkably intelligent way. Although you can retrieve
information about the client browser and its capabilities in an ASP.NET page, ASP.NET actually
encourages developers to ignore these considerations and use a rich suite of web server controls.
These server controls render their HTML adaptively by taking the client’s capabilities into account.
One example is ASP.NET’s validation controls, which use JavaScript and DHTML (Dynamic HTML)
to enhance their behavior if the client supports it. This allows the validation controls to show
dynamic error messages without the user needing to send the page back to the server for more processing.
These features are optional, but they demonstrate how intelligent controls can make the
most of cutting-edge browsers without shutting out other clients. Best of all, you don’t need any
extra coding work to support both types of client.Fact 7: ASP.NET Is Easy to Deploy and Configure
One of the biggest headaches a web developer faces during a development cycle is deploying a
completed application to a production server. Not only do the web-page files, databases, and components
need to be transferred, but you also need to register components and re-create a slew of
configuration settings. ASP.NET simplifies this process considerably.
Every installation of the .NET Framework provides the same core classes. As a result, deploying
an ASP.NET application is relatively simple. In most cases, you simply need to copy all the files to a
virtual directory on a production server (using an FTP program or even a command-line command
like XCOPY). As long as the host machine has the .NET Framework, there are no time-consuming
registration steps.
Distributing the components your application uses is just as easy. All you need to do is copy the
component assemblies when you deploy your web application. Because all the information about
your component is stored directly in the assembly file metadata, there’s no need to launch a registration
program or modify the Windows registry. As long as you place these components in the
correct place (the Bin subdirectory of the web application directory), the ASP.NET engine automatically
detects them and makes them available to your web-page code. Try that with a traditional
COM component!
If you’re new to ASP.NET (or you just want to review a few fundamentals), you’ll be interested in the
following sections. They introduce seven touchstones of .NET development.
Fact 1: ASP.NET Is Integrated with the .NET Framework
No comments:
Post a Comment