The .NET Framework | Understanding .NET: A Tutorial and Analysis (Independent Technology Guides)

< BACK NEXT >

[oR]

For most of the 1990s, application developers in the Microsoft environment relied on the technologies in Windows DNA.

Standards for Web Services

Web services are an unassailably good idea. Yet if these technologies were supported by Microsoft alone, they wouldn't be very interesting. Fortunately, Microsoft, IBM, Sun, Oracle, BEA, and many other vendors have all endorsed the core Web services technologies of SOAP, WSDL, and UDDI. Some of those technologies have been submitted to the World Wide Web Consortium (W3C) and so are on their way to becoming official standards. For example, the W3C has created an XML Protocol working group. This group now owns SOAP and is working to create the next version of this workhorse protocol for Web services. The key point is that while not all of these Web services technologies are official standards yet, all of them have broad vendor support.

Also, none of them contains dependencies on Microsoft-specific technologies such as the .NET Framework. This is a little surprising, given that Microsoft was a major player in the creation of each one. Despite the company's less than stellar reputation for conforming to multivendor standards, Microsoft seems to have realized that Web services cannot succeed without widespread endorsement. Accordingly, the Web services decision makers working with Redmond have thus far chosen to work with their competitors to make this new technology a multivendor reality.

Those technologies include COM and Distributed COM (DCOM), a larger group of COM-based technologies known collectively as COM+, Active Server Pages (ASP), ActiveX Data Objects (ADO), and others. The most commonly used languages for building Windows DNA applications have been Visual Basic and Visual C++, both provided as part of Microsoft's Visual Studio.

Tens of thousands of applications based on these technologies are in production today, providing solid evidence of Windows DNA's success. Yet at the start of a new century, Microsoft has introduced the .NET Framework, a new environment for creating applications. The technologies the Framework includes will change the way nearly every Windows application is created. They will also change the world of everyone who designs and develops Windows-based software or manages those who do.

The .NET Framework is the successor to Windows DNA

As this chapter illustrates, the .NET initiative encompasses a family of new technologies. For Windows developers, however, by far the most important is the .NET Framework. It's no exaggeration to say that the Framework is the most significant advance Microsoft has introduced for software developers since the release of Windows NT.

For developers, the .NET Framework is the most important part of .NET

To understand the changes wrought by the .NET Framework, the place to start is Windows DNA. The technologies Windows DNA includes COM, ASP, and others were developed over time. Because of this, the integration among them wasn't as complete as it might have been. For example, one attractive aspect of the Windows DNA environment is that application developers can use various programming languages, including Visual Basic (VB) and VBScript, C++, and others. Yet each language has its own runtime libraries, its own data types, its own approach to building GUIs, as well as other differences.

The Windows DNA technologies are a diverse lot

Applications written in different languages also access system services in different ways. C++ applications can make direct calls to the operating system through the Win32 interface, for instance, while Visual Basic applications typically access these services indirectly. These differences make life challenging for developers working in more than one language. Another example of diversity is the division between the scripting environment used in ASP pages and the compiled code in the COM components that those pages commonly use. Developers building ASP applications, one of the most popular Windows DNA technologies, must work in both environments using different languages and tools.

Windows DNA applications vary in functionality depending on the language and environment they use

The lives of Windows developers would be simpler if there were a common foundation that could be used from all languages. This is exactly what the .NET Framework offers. Every application written using the Framework depends on a fundamental library called the Common Language Runtime (CLR). The CLR provides a common set of data types and other services that can be used by all languages that target the .NET Framework. Because the foundation is the same no matter which language they choose, developers now see a much more consistent environment.

The CLR provides a common basis for all languages and environments

Along with the CLR, the .NET Framework includes the .NET Framework class library, a large set of standard classes and other types that can be used by any .NET Framework application written in any language. All of those applications can now access system services in the same way through the .NET Framework class library. The differences that complicate the Windows DNA world are gone.

The .NET Framework class library provides standard code for common functions

Among the most important technologies provided in the .NET Framework class library are the following:

ASP.NET: The next generation of Active Server Pages for building Web-accessible applications. A key feature of this new technology is strong support for building applications that use and expose Web services.
ADO.NET: The next generation of ActiveX Data Objects for accessing data stored in relational database management systems (DBMSs) and in other formats.
Windows Forms: A standard set of classes for building Windows GUIs in any .NET Framework programming language.
Enterprise Services: Standard classes for accessing COM+ services such as transactions and object pooling.

The .NET Framework class library contains much more than this short list indicates. Among the other services it provides are support for creating and working with XML documents, services for remote access, and mechanisms for interoperating with COM-based applications. Figure 1-2 illustrates the main components of the .NET Framework and how they relate to one another.

Figure 1-2. The .NET Framework consists of the Common Language Runtime and the .NET Framework class library.

As the figure shows, the .NET Framework can be used to create many different types of applications. The choices include browser-accessible applications, Web services applications, applications that display just a local Windows GUI, and others. Because all of the services in the .NET Framework class library are built on the CLR, applications can combine them as needed. A browser application built using ASP.NET, for example, might use ADO.NET to access stored data and Enterprise Services to perform distributed transactions.

The .NET Framework supports various kinds of applications

Software that uses the .NET Framework (and thus relies on the CLR) is referred to as managed code. That code is usually object-oriented, so the objects it creates and uses are known as managed objects. A managed object can use and even inherit from another managed object even if the two are written in different languages. This fact is a key part of what makes the .NET Framework class library an effective tool: Objects written in any CLR-based language can inherit and use the library's code.

A .NET Framework application consists of managed code

Housing Windows Developers

Think of Windows DNA as a house. It's not a bad house, and a lot of people have lived in it quite happily. But chez DNA was built with no master plan it just grew. Two languages with wildly different personalities, Visual Basic and C++, lived together uneasily beneath the same roof. Additions were constructed when required, and every effort was made to design these additions according to some common architecture. But because they were developed by different groups at different times to meet different needs, the additions didn't always fit together well. The duct tape of COM sometimes seemed like the main thing that kept the house standing.

Rather than trying to keep improving Windows DNA, Microsoft has chosen instead to buy a new lot and construct a completely new house. That house is the .NET Framework, and it's one that many people will one day find themselves living in. But unlike Windows DNA, the Framework has a clear, consistent architecture from its foundation on up to the skylights. There is a well-thought-out master plan, and just about everything in the Framework fits into it.

The lot on which the .NET Framework sits is right next door to the old Windows DNA place. This is good, because between the two there's a workable connection known as COM interoperability. People will still be living under the roof of Windows DNA for many years to come, so this close relationship is critically important. But Windows DNA won't gain many new residents. The future belongs to the .NET Framework.

The Common Language Runtime

The Common Language Runtime is the basis for everything else in the .NET Framework. It's used by every Framework application, regardless of the language in which that application is written, and it's the foundation for the .NET Framework class library as well. To understand the Framework, the CLR is the place to start.

What the CLR Defines

Think about how a programming language is defined today. Each language commonly has its own unique syntax, its own set of control structures, a unique set of data types, its own notions of how classes inherit from one another, and much more. The choices a language designer makes are driven by the target applications for the language, who its users are meant to be, and the designer's own sensibilities.

Yet most people agree on much of what a modern programming language should provide. While opinions on syntax differ some developers love curly braces, others abhor them there's widespread agreement on what semantics a language should offer. Given this, why not define a standard implementation of those semantics, then allow different syntaxes to be used to express those semantics?

There's widespread agreement on the features a modern programming language should offer

The CLR provides this standard implementation. By providing a common set of data types such as integers, strings, classes, and interfaces, specifications for how inheritance works, and much more, it defines a common set of semantics for languages built on it. The CLR says nothing about syntax, however. How a language looks, whether it contains curly braces or semicolons or anything else, is entirely up to the language designer. While it is possible to implement languages with varying behaviors on top of the CLR, the CLR itself provides a consistent, modern set of semantics for a language designer to build on.

The CLR defines a common set of semantics that is used by multiple languages

The CLR also provides other common services

Along with its standard types, the CLR provides other fundamental services. Those services include the following:

Garbage collection, which automatically frees managed objects that are no longer referenced.
A standard format for metadata, information about each type that's stored with the compiled code for that type. Unlike COM, there are no separate type libraries, nor is there any need for an IDL. Instead, interfaces and classes are defined directly using whatever programming language a developer is working in and then converted into a standard metadata format.
A common scheme for organizing compiled code, called assemblies. An assembly can consist of one or more Dynamic Link Libraries (DLLs) and/or executables (EXEs), and it includes the metadata for the classes it contains. A single application might use code from one or more assemblies, and so each assembly can specify other assemblies on which it depends.

COM and the .NET Framework

Because it defines common conventions for interfaces, data types, and other aspects of interaction among different software, COM provides the glue that connects all of the components in a Windows DNA world. Since the introduction of COM in 1993, Windows developers (including those in Redmond) have used it more and more in creating new software. Given this technology's important role, it's worth saying a bit more about the place of COM in the .NET Framework environment.

Applications built on the .NET Framework don't face many of the problems that COM addresses. For example, .NET Framework applications all use the CLR, and the CLR defines a common approach to interfaces and other data types. As a result, the glue between different languages that COM provides is no longer necessary. This is why traditional COM technology isn't used in building pure .NET Framework applications. Instead, developers can build software that interacts in a more natural and substantially simpler way.

Does this mean that the arrival of the .NET Framework signals the death of COM? Certainly not. In a highly abstract sense, the CLR is the next generation of COM (in fact, Microsoft referred to it internally as COM+ 2.0 during its development). Also, as described later in this book, the CLR has a great deal of built-in support for interoperating with COM-based applications. Finally, for some new applications, developers will choose not to use the .NET Framework at all. The creators of a new DBMS, for instance, might decide to use straight C++ instead of building on the Framework. If so, they would likely also use COM to expose external services and define internal interfaces. While the role of COM gets much smaller in a .NET world, COM is not dead.

Using the CLR

The CLR was not defined with any particular programming language in mind. Instead, its features are derived largely from popular existing languages, such as C++, Visual Basic, and Java. Yet it doesn't exactly match any of these languages. Accordingly, Microsoft has provided new languages built on the CLR for .NET Framework developers to use, including Visual Basic.NET and C#. C++ can also be used to write .NET Framework applications using a set of managed extensions. The result, commonly called Managed C++, allows the large number of developers familiar with C++ to access the services provided by the .NET Framework.

The CLR supports many different programming languages

No matter what language it's written in, all managed code is compiled into Microsoft Intermediate Language (MSIL) rather than a machine-specific binary. MSIL is a set of CPU-independent instructions for performing typical operations such as loading and storing information and calling methods. Each DLL and EXE in an assembly contains MSIL rather than processor-specific code. Installing a .NET Framework application on your system really means copying to your disk files that contain MSIL rather than a machine-specific binary. When the application is executed, MSIL is transformed into native code before it's executed.

Managed code is always compiled first into MSIL

Figure 1-3 illustrates the process of compiling and executing managed code. Source code written in VB.NET, C#, Managed C++, or another language that targets the CLR is first transformed into MSIL by the appropriate language compiler. As the figure shows, the compiler also produces metadata that's stored in the same file as the MSIL. Before execution, this MSIL is compiled into native code for the processor on which the code will run. By default, each method in a running application is compiled the first time that method is called. Because the method is compiled just in time to execute it, this approach is called just-in-time (JIT) compilation.

Figure 1-3. All managed code is compiled first to MSIL, then translated into native code before execution.

Each method is typically JIT compiled the first time it's invoked

One point worth noting is that all languages targeting the CLR should exhibit roughly the same performance. Unlike the Windows DNA world, where the performance difference between VB and C++ is sometimes significant, .NET Framework applications written in C# are not noticeably faster than those written in VB.NET. While some compilers may produce better MSIL code than others, large variations in execution speed are unlikely.

All .NET Framework based languages have about the same level of performance

The CLR is the foundation of everything else in the .NET Framework. All code in the .NET Framework class library depends on it, as do all Framework-based applications. Chapter 3 provides a more detailed look at the technology of the CLR.

The .NET Framework and Existing Applications

The .NET Framework is a big change. It's so big, in fact, that most existing applications, especially those written in Visual Basic 6, won't run on the Framework without at least some modification. Releasing a new development environment that won't run existing applications is an unusual step for a vendor to take. How big a problem is it likely to cause?

For most organizations, the fact that existing applications won't run on the .NET Framework shouldn't be too much of an issue. To see why, it's important to realize that most existing applications won't need to run on the Framework. Installing the Framework doesn't break any code that's already running on a system, so Framework-based applications can run side by side with existing software, such as Windows DNA applications. In spite of the .NET Framework's benefits for developing new applications, there probably won't be compelling business reasons to modify most existing applications to run on top of it.

The core problem, then, is building new Framework-based code that either extends or interacts with existing non-Framework-based software. To make this possible, the CLR has built-in support that allows managed code to call existing DLLs, access and be accessed by COM objects, and interoperate in other ways with the current generation of software. Achieving this interoperability can be simple, but it can also get complicated in more involved situations. It is possible, however, so existing code does not need to be rewritten to work with new Framework-based code.

Transitioning to a wholly new environment still has its challenges, however. One of the most obvious is the cost of retraining. In the long run, avoiding the .NET Framework isn't possible for Windows-oriented organizations, so ponying up the cash for developer education is unavoidable. It's not fun, and time will be lost as developers come up to speed on this new technology. The .NET Framework really is substantially better than Windows DNA, however, so most organizations are likely to see productivity gains once developers have internalized this new environment.

Another concern is that organizations will need to have two development environments for some period of time. Maintaining Windows DNA applications will generally require Visual Studio 6, while new applications will require Visual Studio.NET. Both can be installed at once on a single machine, but still, maintaining parallel worlds is not a desirable thing. Also, Microsoft promises to support Visual Studio 6 for some time, but it's not yet clear exactly how long this will be. Microsoft is now an enterprise vendor mission-critical applications rely on Windows DNA so this period should be measured in years, perhaps even decades. If the people in Redmond fail to understand this and drop support for Visual Studio 6 too soon, they will demonstrate that Microsoft isn't really an enterprise vendor after all.

CLR-Based Languages

One of the goals of the .NET Framework is to let developers work in the language of their choice. To allow this, the CLR can support many different programming languages. Those languages often have a good deal in common, since the CLR defines the core semantics for each one, but a developer can still choose the language that feels most natural to her. Visual Studio.NET, Microsoft's primary tool for building .NET Framework applications, supports four CLR-based languages: Visual Basic.NET, C#, C++, and JScript.NET. Third parties have demonstrated support for other languages built on the CLR, including Perl, Python, and COBOL. All of these languages use at least some of the services provided by the CLR, and some expose virtually everything the CLR has to offer. This section provides a short introduction to each of the CLR-based languages included in Visual Studio.NET.

Visual Studio.NET provides four languages for building .NET Framework applications

Visual Basic.NET

From its humble beginnings at Dartmouth College in the 1960s, Basic has grown into perhaps the most widely used programming language in the world today. This success is due largely to the popularity of Microsoft's Visual Basic. Yet it's likely that the original creators of Basic wouldn't recognize their creation as it's implemented in the Microsoft tool. The price of success has been adaptation sometimes radical to new requirements.

Visual Basic is a very widely used environment

Visual Basic.NET is the next step in the evolution of Visual Basic. In addition to being enormously different from the original Basic language, it is a big leap from its immediate predecessor, Visual Basic 6. The primary reason for this substantial change is that VB.NET is built entirely on the CLR. In fact, it's not possible to create traditional standalone binary executables with VB.NET. Instead, every application built with this tool is compiled into MSIL and requires the .NET Framework to execute.

VB.NET is a big change from VB 6

Because it's built on the CLR, VB.NET has a host of new features that this standard library provides, including the following:

Support for implementation inheritance, allowing a new child class to inherit code from one parent class (this is sometimes referred to as single inheritance)
The ability for a child class to override one or more methods in its parent
Support for exception handling
Full multithreading
The ability to define explicitly interfaces directly in VB
Support for properties and events
Support for attributes, allowing features such as transaction support and Web services to be implemented by inserting keywords in source code
Garbage collection, freeing developers from the need to destroy explicitly objects they have created

VB.NET also marks the end of Visual Basic, Scripting Edition (commonly called just VBScript) as a separate technology. Traditionally used in Active Server Pages, command scripts, and other places, this VB dialect is replaced by VB.NET. Among other things, this change allows using the full power of Visual Basic in ASP.NET applications. Yet it also replaces a simple tool with a more complex one, which may make life a bit more challenging for system administrators accustomed to the simplicity of VBScript.

VBScript no longer exists as a separate technology

C#

Modifying Visual Basic to work with the CLR required substantial changes to the language, but the result is still close enough to the original to warrant having the same name. The other dominant language in the pre-.NET Microsoft world has been C++. A large number of Windows developers know (and love) C++, so how can those developers be brought forward to use the .NET Framework? One answer is to extend C++, an option described in the next section. Another approach, one that will likely prove more appealing for most current C++ developers, is to create a new language based on the CLR but with a syntax derived from C++. This is exactly what Microsoft has done by creating C#.

C# is the natural language for .NET Framework developers who prefer a syntax derived from C

The only completely new language in Visual Studio.NET, C# will look familiar to anyone accustomed to programming in C++ or Java. Like those languages and like VB.NET, C# is object-oriented. C# is much like VB.NET in other ways, too, which shouldn't be surprising. Both are built on the CLR, and both expose the same core functionality from this standard foundation. In fact, the biggest difference between C# and VB.NET is in syntax; functionally, the two languages are very similar.

C# provides almost exactly the same features as Visual Basic.NET

The list of features provided by C# is nearly identical to the list just given for Visual Basic.NET. Among those features are the following:

Support for single implementation inheritance
Method overriding
Support for exception handling
Full multithreading
The ability to define explicitly interfaces directly in C#
Support for properties and events
Support for attributes as in VB.NET
Garbage collection

C# also provides a few features that aren't available in VB.NET, including the following:

Operator overloading, allowing a class to define its own unique meaning for standard operators such as the plus sign
The ability to write code that directly accesses specific memory addresses, sometimes referred to as unsafe code

Most Visual Basic programmers can safely ignore C# if they choose because VB.NET offers almost everything that's in C#. C++ or Java developers, who are accustomed to a C-like syntax, will likely prefer C# for writing .NET Framework applications.

C++

C++ presents a challenge in the world of .NET. To be used in building .NET Framework applications, this popular language must be modified to use the CLR. Yet some of the core semantics of C++, which allows such things as a child class inheriting directly from multiple parents (known as multiple inheritance), conflict with those of the CLR. At the same time, C++ is likely to remain the dominant language for creating non-Framework-based Windows applications, so modifying it to be purely Framework specific isn't possible. What's the solution?

The semantics of C++ differ from those defined by the CLR

In Visual Studio.NET, Microsoft's answer is to support standard C++ as always, leaving this powerful language able to create efficient processor-specific binaries as before (in fact, there are even quite a few enhancements in this area). To allow the use of C++ to create .NET Framework applications, Microsoft added a set of extensions to the language. The C++ dialect that includes these extensions is called Managed C++, and it provides access to all features of the CLR. Using Managed C++, for instance, a developer can write C++ code that takes advantage of garbage collection, defines interfaces, uses attributes, and more.

.NET Framework applications can be created using Managed C++

Because not all applications will use the .NET Framework, Visual Studio.NET still allows building traditional Windows applications in C++. Rather than using Managed C++, a developer can write standard C++ code and then compile it into processor-specific binaries. Unlike VB.NET, C#, and JScript.NET, C++ is not required to compile into MSIL.

Standard C++ can also be used to create non-Framework-based applications

JScript.NET

JScript, Microsoft's implementation of what's more commonly called JavaScript, is primarily used for two things in the Windows DNA world: writing code that's sent to and executed by browsers, and writing code for Active Server Pages. JScript.NET, the .NET world's successor to JScript, still can be used for both of these things. In fact, it is a superset of standard JScript, although one to which quite a bit has been added.

JScript.NET is the Visual Studio.NET implementation of JavaScript

JScript.NET is built on the CLR

Like the other languages in Visual Studio.NET, JScript.NET is now implemented on top of the CLR. Accordingly, it now includes several new features, among the most important of which are

Support for classes, which can contain methods, variables, and properties; can implement interfaces; and can inherit from other classes.
A variety of new data types, including Boolean, String, int, float, and more.
Compiled rather than interpreted code.

Especially for developers accustomed to writing Active Server Pages in traditional JScript, JScript.NET should bring welcome enhancements. Creators of scripts sent to and executed by browsers, however, probably won't gain much from these new features. Unless the target browser is guaranteed to be a recent version of Internet Explorer, the extensions can't be used. Furthermore, because the Microsoft extensions aren't supported by Netscape's browser, embedding JScript.NET code in pages sent to arbitrary browsers on the Internet is unlikely to lead to happy users. For these situations, applications will need to continue to use traditional JavaScript, an option that is still supported for .NET Framework applications.

ASP.NET developers will likely be the most common users of JScript.NET

Support for multiple programming languages is one of the most attractive things about the .NET Framework. Chapter 4 takes a closer look at C#, VB.NET, and Managed C++, the three languages likely to be most popular for building .NET Framework based applications.

The .NET Framework Class Library

The .NET Framework class library is exactly what its name suggests: a library of classes and other types that developers can use to make their lives easier. While these classes are written in C#, they can be used from any CLR-based language. Code written in VB.NET, C#, Managed C++, or any other language supported by the .NET Framework can create instances of these classes and call their methods. That code can also rely on the CLR's support for inheritance to inherit from the library's classes.

The.NET Framework class library can be used from any CLR-based language

The.NET Framework class library is organized as a tree

Surveying the Library

The contents of the .NET Framework class library are organized into a tree of namespaces. Each namespace can contain types, such as classes and interfaces, and other namespaces. The root of the tree, the namespace that contains all other namespaces as well as many types of its own, is the System namespace. Figure 1-4 shows a very small part of the .NET Framework class library's namespace tree. The namespaces shown include the following:

Figure 1-4. The .NET Framework class library is structured as a hierarchy of namespaces, with the System namespace at the root.

System: Along with all of the other namespaces in the .NET Framework class library, this namespace also contains the core data types used by the CLR (and thus by languages built on the CLR). These types include several varieties of integers, a string type, and many more.
System.Web: The types in this namespace comprise ASP.NET. Types in the System.Web.UI namespace are used to build browser-accessible applications, while those in System.Web.Services are used to build Web services applications.
System.Data: The types in this namespace comprise ADO.NET. For example, the Connection class is used to establish connections to a database management system (DBMS), while an instance of the DataSet class can be used to cache and examine the results of a query issued against that DBMS.
System.Windows.Forms: The types in this namespace are used to build Windows GUIs. Rather than using language-specific mechanisms, such as Microsoft Foundation Classes (MFC) in C++, .NET Framework applications written in any programming language use this common set of types to build local GUIs.
System.EnterpriseServices: Services provided by COM+, such as distributed transactions, remain important in the .NET world. The types in this namespace allow managed code to access these services. Most important is the ServicedComponent class, from which every class that wishes to use COM+ services must inherit.
System.XML: Types in this namespace provide support for creating and working with XML-defined data. The XmlDocument class, for instance, allows accessing an XML document using the Document Object Model (DOM). This namespace also includes support for newer technologies such as the XML Schema definition language (commonly referred to as XSD) and XPath.

Many more namespaces are defined, providing support for file access, serializing an object's state, remote access to objects, and much more. In fact, the biggest task facing developers who wish to build on the .NET Framework is learning to use the many services that the library provides. There's no requirement to learn everything, however, so a developer is free to focus on only those things relevant to his or her world. See Chapter 5 for a more complete description of this large library.

Learning the.NET Framework class library will take time

ADO.NET

Because it contains the types that implement ADO.NET, System.Data is one of the most important namespaces in the .NET Framework class library. Like its predecessor ADO, ADO.NET lets applications work with data stored in a DBMS. Apart from this fundamental similarity, however, ADO and ADO.NET don't have much in common. Instead, ADO.NET focuses on allowing managed code to work with data in a way that makes sense for a world increasingly dominated by Web-based applications.

ADO.NET lets applications access stored data

Figure 1-5 illustrates how an application can use ADO.NET to access stored information. As the figure shows, access to a DBMS relies on a .NET data provider, written as managed code. .NET data providers that allow access to SQL Server, Oracle, and other DBMSs exist today, and they allow a client application to issue commands against the DBMS and examine any results those commands return. The result of a SQL query, for example, can be examined in two ways. Applications that need only read the result a row at a time can do this in a straightforward way, marching directly through what a query returns one record at a time. Applications that need to do more complex things with the result of a query, such as send it to a browser or store it on disk, can instead have the query's result packaged inside a DataSet object.

Figure 1-5. ADO.NET allows .NET Framework applications to access data stored in DBMSs and XML documents.

ADO.NET clients rely on a .NET data provider to access a DBMS

As Figure 1-5 illustrates, a DataSet can contain one or more tables. Each table can hold the result of a different query, so a single DataSet might potentially contain the results of two or more queries, perhaps from different DBMSs. In effect, a DataSet acts as an in-memory cache for data. As the figure shows, however, DataSets can hold more than just the result of a SQL query. It's also possible to read an XML document directly into a table in a DataSet without relying on a .NET data provider. Data defined using XML has become much more important in the last few years, so ADO.NET allows accessing it directly. While not all .NET Framework applications will rely on ADO.NET for data access, a large percentage surely will. Given this importance, ADO.NET is described in more detail in Chapter 6.

An ADO.NET DataSet acts as an in-memory cache for data

ASP.NET

Implemented in the System.Web namespace, ASP.NET is a major piece of the .NET Framework. The successor to the very popular Active Server Pages technology, ASP.NET brings a number of new features to ASP developers. Like traditional ASP applications, ASP.NET applications are built from one or more pages. Each page contains HTML and/or executable code. As Figure 1-6 shows, however, ASP.NET allows the creation of two types of applications: traditional browser applications accessible via HTTP and HTML, and Web services applications accessible via SOAP.

Figure 1-6. ASP.NET allows the creation of both browser applications and Web services applications.

ASP.NET is the successor to Active Server Pages

These two different kinds of applications use different kinds of pages. Applications that present traditional browser GUIs can be built by combining HTML and executable code in files with the extension .aspx. Applications that expose methods as Web services can be built from files with the extension .asmx, each of which contains only code. As Figure 1-6 shows, all that's required to expose a method as a Web service from an .asmx page is to insert WebMethod before the method definition.

ASP.NET applications can use .aspx pages and .asmx pages

ASP.NET changes ASP development in many ways

ASP.NET also brings many other new features to the world of ASP development. Among the most important are the following:

The code in ASP.NET applications is compiled rather than interpreted as in traditional Active Server Pages, so applications execute faster than in previous versions.
The distinction between script code and components is eliminated. Rather than deciding whether a function should be implemented as script code or as compiled but more complex COM components, all code in ASP.NET applications is managed code.
Web controls can be used to build browser-based GUIs more easily. Running on the server rather than the client, Web controls allow drag-and-drop construction of a user interface, just as in Visual Basic today.
ASP.NET applications are easier to install and remove than traditional ASP applications. An ASP.NET application is just a .NET Framework application, so it can be installed by simply copying files and removed by deleting those files. No registration entries are required (unless COM interoperability features are used).

The .NET Framework and the Java Environment

Mainstream software development today has split cleanly into two camps. Microsoft, promoting the .NET Framework, is in one, while most other vendors, backing Sun's Java environment, are in the other. Both technologies have their fans and detractors, and I'm convinced that both have a good future.

These competing worlds are strikingly similar. To see how similar, compare the figure above with Figure 1-2. Both environments are trying to support the same classes of applications (although the .NET Framework has significantly better support for Web services than is specified for the Java world today), and the Java virtual machine is similar to the .NET Framework's CLR. The large standard library that Java provides includes JavaServer Pages for Web scripting, JDBC for database access, Swing for building GUIs, Enterprise JavaBeans for building more scalable server applications, and other classes. These are quite analogous to the .NET Framework's ASP.NET, ADO.NET, Windows Forms, and Enterprise Services, respectively. Even the semantics of the dominant languages Microsoft's C# and VB.NET versus Java are quite similar.

There are also differences, of course. One obvious distinction between the two is that the Java environment runs on diverse operating systems, while the .NET Framework focuses on Windows. The trade-off here is clear: Portability is good, but it prevents tight integration with any one system, and integration is also good. You can't have everything, at least not all at the same time. Also, Java-based products are available from multiple vendors, while only Microsoft provides the .NET Framework. Java products commonly provide extensions to the core specifications, so developers tend to get somewhat locked into a single vendor. Still, portability across different Java platforms is possible, while the .NET Framework unambiguously ties your application to Microsoft.

This bifurcation and the competition it engenders are ultimately a good thing. Both camps have had good ideas, and each has borrowed from the other. Having one completely dominant technology, whether the .NET Framework or Java, would produce a stultifying monopoly. Having a dozen viable choices would produce something close to anarchy, an idea that should send shivers through anyone who lived through the chaos of the two-tier client/server era. Two strong competitors, each working to outdo the other, is just right.

Given the popularity of traditional ASP technology, ASP.NET may affect more developers than any other part of the .NET Framework class library. Although it's just one part of this large set of new technology, ASP.NET is likely to be very widely used. Chapter 7 provides more detail on this important part of the .NET Framework.

The .NET Compact Framework

While the .NET Framework is useful for writing applications on desktops and server machines, it can also be used with smaller devices, such as mobile phones, PDAs, and set-top boxes. Small devices are becoming more and more important, and they're an important piece of Microsoft's overall .NET strategy. These devices typically have less memory, however, so they're unable to run the complete .NET Framework. The .NET Compact Framework addresses this issue. By eliminating some parts of the .NET Framework class library, it allows use of the Framework in smaller devices.

The .NET Compact Framework is a smaller version of the .NET Framework

The .NET Framework on Non-Windows Systems

Applications written using the .NET Framework are compiled to a processor-independent form MSIL and shield themselves from the vagaries of a specific operating system by writing to the .NET Framework class library. This is much like the Java world, where applications are compiled to bytecode and can rely on standard Java libraries rather than making direct calls to a specific operating system. Java was expressly designed to work on multiple processors and operating systems. Is the same thing true for .NET?

To some extent, the answer is clearly yes. Microsoft has said that the .NET Compact Framework will be available for multiple processors and operating systems, not just for devices running Windows CE. Microsoft has also announced a port of the Framework's fundamentals to the FreeBSD version of UNIX. Theoretically, the .NET Framework could become a cross-platform solution on a wide range of systems.

Yet some technical issues remain. While MSIL is clearly platform independent, some parts of the .NET Framework class library just as clearly are not. Enterprise Services, for example, providing support for scalable, transaction-oriented applications, is based on COM+. Accordingly, this part of the library runs only where COM+ is available. This leaves out not only UNIX, but also older versions of Windows, such as Windows 98. Other parts of the class library also betray their Windows origins in more or less obvious ways.

Just as important, Microsoft will face some challenges in making customers believe that it's serious about long-term support of the .NET Framework on non-Windows systems. The company's laserlike focus on its own operating systems has been a hallmark of its business, as well as a primary factor in its success. Customers may remember earlier promises about making COM available on other platforms. While partners such as Software AG and Compaq labored mightily to make cross-platform COM a reality, Microsoft appeared to lose interest in the idea quickly. Might the same thing happen with non-Windows versions of the .NET Framework?

It's too soon to know. If Microsoft wishes to make the .NET Framework a true multiplatform rival for Java, the technical potential is there. But it will be several years before a critical mass of customers believes that the company is serious about helping them build software on operating systems that don't come from Redmond.

The .NET Compact Framework first targets Windows CE, but Microsoft also plans to make it available in other environments. Because it's built on the same foundation used in larger systems, the .NET Compact Framework allows the use of Visual Studio.NET as its development environment. Organizations that must create software for a range of devices can now use the same languages and the same tools to target systems of all sizes.

Visual Studio.NET can be used to develop applications for the .NET Compact Framework

The .NET Framework itself is scheduled to be generally available in early 2002. The .NET Compact Framework is not scheduled to ship until sometime after that, however. Given that the Compact Framework is a subset of its larger sibling, this is counterintuitive. Why should it ship later? A large part of the answer is that the version of the CLR provided with the .NET Compact Framework is not the same as that in the Framework itself. Instead, the Compact Framework's CLR was rewritten to work more effectively on smaller devices with less memory and less processing power. As a result, the .NET Compact Framework will come to market some number of months later than its big brother.

The .NET Compact Framework will ship after the .NET Framework

< BACK NEXT >