A Guide to Evaluating the Microsoft .

NET Framework:
The .NET Framework is an integral Microsoft Windows® component
that supports building and running the next generation of software
applications and XML Web services.

Abstract

The Microsoft .NET Framework is an integral Windows component for

building and running the next generation of applications and XML Web
services. It provides a highly productive, standards-based, enterprise-ready,
multilanguage environment that simplifies application development, enables
developers to leverage their existing skill set, facilitates integration with
existing software, and eases the challenges of deploying and operating
Internet-scale applications. The .NET Framework consists of two main parts:
the common language runtime (CLR) and a unified, hierarchical class library
that includes a revolutionary advance to Active Server Pages (ASP.NET), an
environment for building smart client applications (Windows Forms), and a
loosely coupled data access subsystem (ADO.NET).

For the latest information on the .NET Framework, visit

http://msdn.microsoft.com/netframework/.
The information contained in this document
represents the current view of Microsoft
Corporation on the issues discussed as of the date
of publication. Because Microsoft must respond to
changing market conditions, it should not be
interpreted to be a commitment on the part of
Microsoft, and Microsoft cannot guarantee the
accuracy of any information presented after the
date of publication.
This document is for informational purposes only.
MICROSOFT MAKES NO WARRANTIES,
EXPRESS OR IMPLIED, AS TO THE
INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the
responsibility of the user. Without limiting the
rights under copyright, no part of this document
may be reproduced, stored in, or introduced into a
retrieval system, or transmitted in any form or by
any means (electronic, mechanical, photocopying,
recording, or otherwise), or for any purpose,
without the express written permission of Microsoft
Corporation.
Microsoft may have patents, patent applications,
trademarks, copyrights, or other intellectual
property rights covering subject matter in this
document. Except as expressly provided in any
written license agreement from Microsoft, the
furnishing of this document does not give you any
license to these patents, trademarks, copyrights,
or other intellectual property.
 2003 Microsoft Corporation. All rights reserved.
Microsoft, the .NET logo, ActiveX, JScript, Visual
Basic, Visual C++, Visual FoxPro, Visual InterDev,
Visual J++, Visual Studio, Win32, Windows, and
Windows NT are either registered trademarks or
trademarks of Microsoft Corporation in the United
States and/or other countries.
The names of actual companies and products
mentioned herein may be the trademarks of their
respective owners.
Microsoft Corporation • One Microsoft Way •
Redmond, WA 98052-6399 • USA
 CONTENTS
EVALUATION CRITERIA.................................................1

AN OVERVIEW OF THE .NET FRAMEWORK...................4

Common Language Runtime (CLR) 4

Class Libraries 4

.NET FRAMEWORK ARCHITECTURE..............................6

.NET Framework-based Applications 6

.NET Framework Design Goals 7

Architecture Drilldown 8

The Common Language Runtime 8

The Unified Class Libraries 14

ASP.NET 15

XML Web Services 16

Windows Forms 17

Common System Namespaces 18

Data Access with ADO.NET 18

Directory Services 21

Enterprise Services 22

InteropServices 22

Management 23

Remoting 24

Security 25

.NET Framework Device Support 26

.NET Compact Framework 26

ASP.NET Mobile Controls 27

Administration 27

Tools for developing with the .NET Framework 28

Deploying the .NET Framework Redistributable 30

MICROSOFT'S APPLICATION PLATFORM....................31

Web Applications with ASP.NET 32

Inside ASP.NET 32

Microsoft .NET Framework Evaluation Guide i

 Tracing and Debugging 33

Application Configuration 34

Updating Applications 35

Extensibility 35

State Management 36

Code Compilation 36

Caching 36

ASP and ASP.NET Co-existence 37

Security 37

Mobile Web Device Support 38

XML Web Services 39

Core XML Web Services Technologies 40

Create XML Web Services Easily 41

Testing an XML Web Service 42

Access an XML Web Service 45

Windows Server 2003 45

What's New in IIS 6.0 46

BUILDING SMART CLIENT APPLICATIONS..................48

Advantages of Smart Client Applications 48

Deploying Smart Clients from a Web Server 48

Code Access Security: Making No-Touch Deployment Safe 49

Smart Client Versus Browser-Based 50

Work Offline 50

Use Resources Efficiently and Safely 50

Access Local APIs 52

Use Peer-to-Peer Technology 52

Consume XML Web Services 52

A Minimal Windows Form 52

Programming with Windows Forms 53

Forms 53

Controls 53

Events 54

Microsoft .NET Framework Evaluation Guide ii

 Extending Forms 54

Creating Controls 54

Mobile Device Development 55

When to Implement Smart Clients 55

SUMMARY....................................................................57

Loosely Coupled Designs Enable Scalability 57

Leverage Operating System Services 57

Multilanguage Support 57

Operational Excellence 57

Developer Productivity 58

Standards-Based 58

APPENDIX A: CHANGES FROM

.NET FRAMEWORK 1.0.................................................59

Native Support for Developing Mobile Web Applications 59

Granular Version Control: Side-by-Side Execution 59

Enable Execution of Windows Forms Assemblies Originating

from the Internet 60

Enable Code Access Security for ASP.NET Applications 60

Native Support for Communicating with ODBC and Oracle

Databases 61

Unified Programming Model for Smart Client Application

Development 61

Support for IPv6 62

Scalability, Performance, Documentation 62

APPENDIX B: MINIMUM CONFIGURATION

REQUIREMENTS...........................................................64

Platform and Software Requirements 64

Minimum Requirements 64

Recommended Software 64

Recommended Server Software 65

Hardware Requirements 65

Minimum Hardware Requirements 65

Recommended Hardware Requirements 65

Microsoft .NET Framework Evaluation Guide iii

 EVALUATION
CRITERIA
APPENDIX C: STANDARDS AND THE .NET
FRAMEWORK................................................................66

ECMA C# and Common Language Infrastructure Standards 66

Microsoft Shared Source CLI Implementation "Rotor" 66

XML Standards 66

Standards for XML Web Services 67

Global XML Web Services Architecture (GXA) 67

APPENDIX D: RELATIONSHIP TO OTHER MICROSOFT

PRODUCTS...................................................................70

Development Tools 70

Enterprise Servers 70

Windows Server 2003 70

Windows 2000 Server 70

SQL Server 2000 71

BizTalk Server 2002 72

Exchange Server 2000 73

Commerce Server 2002 73

Host Integration Server 2000 74

Microsoft Office 74

APPENDIX E: GLOSSARY.............................................75

APPENDIX F: FOR MORE INFORMATION.....................78

The Microsoft .NET Framework belongs, in the broadest sense, in

the software development category. The leading edge of the
category, according to customers and industry analysts, is the
distributed application development segment. The software
development category contains all developer tools products, while
the distributed application development segment includes only those
tools that provide for both server- and client-side application
development. Microsoft believes the main contenders in this
segment include the .NET Framework and Microsoft Visual
Studio® .NET, versus the Java-based product offerings of IBM

Microsoft .NET Framework Evaluation Guide iv

WebSphere Application Server and SunONE Application Server.

If you examine the needs of developers and enterprise

organizations, you can create a list of criteria for evaluating how
the .NET Framework—and the Visual Studio .NET integrated
development environment (IDE) for building .NET Framework-based
applications—enable the rapid development, simple integration, and
improved operation of the next generation of both server-side and
client-side Microsoft Windows®-based applications. These criteria
include:

Improved Time-to-Market Criteria

 The ability to use any programming language. Give

developers the ability to use any programming language.
Allow applications written with different programming
languages to integrate deeply with each other. Leverage
current development skills to go forward without retraining.
Customers have discovered the exorbitant cost of finding
developers skilled in some specialized technologies.
Industry analysts recommend using existing skills whenever
possible, and avoiding the high cost and high failure rate of
relying on the technical skills in shortest supply.

 Access to state-of-the-art development tools. Deliver

well-designed development tools that provide access to the
full suite of functionality required by enterprise developers—
from drag-and-drop user interface (UI) layout to integrated
debugging and profiling.

 Improved code design. Provide a component-based,

plumbing-free design that enables developers to focus on
writing business logic. Eliminate the need to generate
substantial plumbing and infrastructure code. Provide
existing, well-tested controls that encapsulate common
programmer tasks.

 Support for loosely coupled and tightly coupled

architectures. To achieve performance, scalability, and
reliability in distributed applications, there are some
operations in which components can be tightly coupled, that
is, interdependent in real time. Most modern systems have
this capability. However, successful platforms must also
have complete support for loosely coupled, message-
oriented communication, in which the chain of events
supporting a distributed transaction is not broken or blocked
by any real-time dependencies. Both architectures must be
supported completely and naturally so developers create
scalable solutions by default.

Microsoft .NET Framework Evaluation Guide v

Simple Integration Criteria

 Native, developer-friendly support for XML Web

services. Make cross-platform integration easy with
support for building and consuming XML (Extensible
Markup Language) Web services, components which
facilitate integration by sharing data and functionality over
the network through standard, platform-independent
protocols such as XML, SOAP, and HTTP.

 Transparent extensions for legacy components and

applications. Provide technology so that developers may
easily harness existing functionality in their new solutions.

 Ease of data access. Make available a productive

interface to any database—an interface that is designed to
support the use of both tightly coupled and loosely coupled
data access. Support XML as the native data format so that
the data may be exchanged across platforms.
Improved Operations Criteria

 Fine-grained application security model. Provide a

security model that provides systems administrators with
powerful, granular control over what applications running in
their domain can and cannot do.

 Simplified application deployment. Support a simplified

application deployment model that makes installing
applications as easy as copying them into a directory.

 Increased reliability for applications. Deliver

technologies that make applications more reliable, such as
high-performance, automated memory management and
event-driven monitoring of Web applications with automated
granular control of restarts.

 Maximum performance. Maximize performance by taking

full advantage of the latest technological advances in
compilation and caching.

 A comprehensive solution that provides all the services

needed to produce an enterprise-class solution. These
include application services, such as an object request
broker, transaction-processing monitor, and feature-rich
Web server, and world-class messaging support,
monitoring, and management infrastructure. All of these
services are integrated, so developers can spend their time
building applications, not cobbling together application
services.

Microsoft .NET Framework Evaluation Guide vi

 AN OVERVIEW
OF THE .NET
FRAMEWORK
 A consistent and unified programming model for
applications running within, and applications running
across, Internet firewalls. Related to loosely coupled
architectures, this criterion seeks out the solutions that
enable organizations to learn, build, and support a simple
programming model for intranet- and Internet-based
applications in order to reduce training and support costs.

 A consistent and unified programming model for

broad-reach Web-based clients, as well as smart client
interfaces, and emerging smart devices. Customers
today are evaluating the full range of client devices,
including PCs, browsers, personal digital assistants (PDAs),
and mobile telephones. To be successful, complex,
distributed systems must have a programming model that
elegantly supports all of today's user experiences—as well
as those that will emerge in the future—and that contains a
simple model for maintaining consistent business logic
across any client architecture.

A solution embracing the above principles will enable customers to

lead in their respective industries—to build, deploy, and maintain
better applications, and to bring new software and new services to
market faster and less expensively than competitors. The .NET
Framework and Visual Studio .NET, with Windows as the underlying
operating system, satisfy these requirements more completely and
effectively than any other development platform available today, and
will continue to do so into the foreseeable future. We invite you to
examine these technologies carefully and to make your own
comparison.

The .NET Framework is an integral Windows component that

supports building and running the next generation of software
applications—both client- and server-side—and XML Web
services. It is based on industry standards and manages much of
the plumbing involved in developing and running a piece of software,
enabling developers to focus on writing the core business logic
code. The .NET Framework provides:

 A consistent language-neutral, object-oriented

programming environment.

 A code-execution environment that minimizes software

deployment and versioning conflicts, guarantees safe
execution of code, and eliminates the performance
problems of scripted or interpreted environments.

Microsoft .NET Framework Evaluation Guide vii

 .NET
FRAMEWORK
ARCHITECTURE
 A consistent developer experience across widely varying
types of applications—including smart client applications
and Web-based applications and services, all running on
Windows.

The .NET Framework is composed of two key parts: the common

language runtime and the class libraries.

Common Language Runtime (CLR)

The common language runtime (CLR) is responsible for run-time
services such as language integration; security enforcement; and
memory, process, and thread management. In addition, it has a role
at development time when features such as life-cycle management,
strong type naming, cross-language exception handling, dynamic
binding, and so on, reduce the amount of code that a developer
must write to turn business logic into a reusable component.

The runtime can be hosted by high-performance, server-side

applications, such as Microsoft Internet Information Services (IIS) for
building Web applications with ASP.NET and the next release of
Microsoft SQL Server™. This infrastructure enables you to use code
“managed” by the .NET Framework to write your business logic,
while still enjoying the superior performance of the industry's best
enterprise servers that support runtime hosting.

Class Libraries
Base classes provide standard functionality such as input/output,
string manipulation, security management, network communications,
thread management, text management, user interface design
features, and other core functions. The ADO.NET data classes
enable data access and manipulation. XML classes enable XML
manipulation, searching, and translations. The ASP.NET classes
support the development of Web applications and XML Web
services. The Windows Forms classes support the development of
Windows-based smart client applications. Together, the class
libraries provide a common, consistent development interface
across all languages supported by the .NET Framework.

.NET Framework-based Applications

The .NET Framework can be used to build many different types of
Windows-based applications, including those that run on servers—
such as Web applications and XML Web services—as well as those
that run on the client-side.

Microsoft .NET Framework Evaluation Guide viii

In particular, the application platform solution—composed of the
.NET Framework, and Windows with Visual Studio .NET—can
provide the following types of applications:

 Web applications. These applications run on the server-

side and can be accessed with any Web browser. Using
the ASP.NET mobile controls (these were available in the
form of the Microsoft Mobile Internet Toolkit in the .NET
Framework 1.0), these applications can target small
devices—such as PDAs and mobile phones—generating
the markup language and UI configuration appropriate for
the client device.

 XML Web services. XML Web services are components

which facilitate integration across different platforms by
sharing data and functionality over the network through
standard, platform-independent protocols such as XML,
SOAP, and HTTP.

 Server Components. Communication between different

objects and services running on the same or remote
machines.

 Other. The application platform can also host .NET

Framework-based programs written as console applications
or Windows Services.

On the client, the .NET Framework can be used for the following
types of applications:

 Smart Client. Programs that run locally on the Windows

desktop that take advantage of the rich user interface
capabilities of the underlying operating systems.

 Smart Client on Smart Devices. Applications that run on

the Pocket PC and Windows CE platforms and use the
Microsoft .NET Compact Framework, which will be
discussed in detail below.

 Other. As with the server, the Windows client can also

execute .NET Framework programs written as console
applications or Windows Services.

All of these application types make use of the .NET Framework,

though the details of how they are built, their user interfaces, and the
functional areas of the .NET Framework used by the applications will
vary significantly.

Since the applications that can be created using the .NET

Framework can vary so widely, we will first take a look at the design
and features of the overall .NET Framework itself. Then, in
subsequent sections of this document, we will drill into the

Microsoft .NET Framework Evaluation Guide ix

application platform and building smart client applications.

.NET Framework Design Goals

The .NET Framework is the culmination of the combined efforts of
several teams at Microsoft, which have worked together to create a
set of class libraries and a runtime for rapidly building and efficiently
operating applications and XML Web services on the Windows
operating system. The vision for the .NET Framework is to combine
a simple-to-use programming paradigm with the scalable, open
protocols of the Internet. To achieve this vision several intermediate
goals had to be delivered.

Integration through public Internet standards. To enable

communication between business partners, customers,
geographically separated divisions, and even future applications,
development solutions need to offer both support for open Internet
standards and deep, transparent integration with these standards—
without forcing the developer to learn this underlying infrastructure.
This is provided in the .NET Framework's developer-friendly support
for building and consuming XML Web services.

Scalability through a loosely coupled architecture. The largest,

most scalable systems in the world are built on message-based
asynchronous architectures. But building applications on such an
architecture is complex, and the tools are often less rich than those
of more tightly coupled, n-tier application development
environments. The .NET Framework was built to bring together the
productivity advantages of tightly coupled architectures with the
scalability and interoperability advantages of loosely coupled
architectures.

Multilanguage support. Developers use different languages

because the different languages are good at providing different
things such as string manipulation, rich mathematical functions, and
so on. Rather than forcing everyone to learn a single programming
language, the .NET Framework enables applications written in over
20 different programming languages to integrate deeply with each
other. As a result, the .NET Framework enables companies to take
advantage of their current development skills without the need for
retraining, and allows developers to program in the language of their
choice.

Enhancing developer productivity. Developers must be made

more productive. The .NET Framework development team focused
on eliminating as much programming plumbing as possible, leaving
the developer free to focus on writing business logic. For example,
the .NET Framework includes time-saving features, such as easy-to-
use transactions, automatic memory management, and a rich set of

Microsoft .NET Framework Evaluation Guide x

 controls that encapsulate many common development tasks.

Protecting investments through advanced security. One of the

largest concerns with the Internet today is security, and an Internet
development solution needs to have security implemented as an
integral component, not layered on top. The security architecture of
the .NET Framework is designed from the ground up to ensure that
data and applications are protected through complementary fine-
grained, evidence-based, and role-based security models.

Utilizing operating system services. Windows provides the richest

services available with any platform, including comprehensive data
access, integrated security, interactive user interfaces, a mature
component object model, transaction processing monitors, and
world-class message queuing. The .NET Framework takes
advantage of this richness and exposes it in an easy-to-use way.

Architecture Drilldown
As mentioned above, the .NET Framework includes the common
language runtime and a complete set of class libraries. In this
section, we will explore at a lower level the functionality provided by
these features.

The Common Language Runtime

The common language runtime (CLR) is a high-performance engine
for running applications built using the .NET Framework. Code that
targets the CLR and whose execution is managed by the CLR is
referred to as managed code. Responsibility for tasks such as
creating objects, making method calls, and so on is delegated to the
CLR which enables it to provide additional services —such as
memory management (including garbage collection), process
management, thread management, and security enforcement—to
the code as it executes. The CLR is also responsible for loading
components that the application requires.

Despite its name, the CLR also has a role in a component's

development-time experiences. Because it automates so much
work at run time, the CLR makes the developer's experience
simpler. In particular, features such as lifetime management of
objects, strong type-naming, cross-language exception handling,
Cross-Language Interoperability delegate-based event management, dynamic binding, and reflection
dramatically reduce the amount of code a developer must write in
Compiler Support order to turn business logic into reusable components.
Security Runtimes are nothing new for languages; virtually every
programming language has a runtime. Microsoft Visual Basic® has
Memory Management
the most well known runtime (the aptly-named VBRUN), but
Common Type System Microsoft Visual C++® also has one (MSVCRT), as do Microsoft

Class Loader

Major components of the Microsoft .NET Framework Evaluation Guide xi

common language runtime (CLR)

Visual FoxPro®, Microsoft Jscript®, SmallTalk, Perl, Python,
Haskell, and Java. The critical role of the CLR, and what really sets
it apart, is its provision of a unified run-time environment across all
programming languages.

The key features of the runtime include a common type system

(enabling cross-language integration), self-describing components,
simplified deployment and versioning, and integrated security
services.

Common Type System and Multilanguage

Integration

To fully interact with other objects regardless of the programming

language they were implemented in, objects must expose to callers
only those features that are common to all the languages with which
they must interoperate. The CLR makes use of a new common type
system capable of expressing the semantics of modern
programming languages. The common type system defines a
standard set of data types and rules for creating new types. The
CLR understands how to create and execute these types. The
different language compilers for the .NET Framework use the CLR
to define data types, manage objects, and make method calls
instead of using tool- or language-specific methods.

The Common Language Specification (CLS) defines a set of

language features to which programming languages must adhere in
order to integrate with the .NET Framework. This goes beyond the
common type system, specifying rules about events, exception
handling, metadata (to be discussed in more detail later), and other
key details of a language implementation.

The CLS and common type system facilitate deep multilanguage

integration, enabling the following activities to take place
transparently across components written in different languages,
without any additional work on the part of the developer:

 Calling methods on other objects.

 Inheriting implementations from other objects.

 Passing instances of a class to other objects.

 Using a single debugger across multiple objects.

 Trapping errors from other objects.

This means that developers no longer need to create different

versions of their reusable libraries for each programming language
or compiler, and developers using class libraries are no longer
limited to libraries developed for the programming language they are
using or forced to create Component Object Model (COM) wrappers

Microsoft .NET Framework Evaluation Guide xii

to facilitate the interaction.

Cross-language integration is useful in several scenarios. For

example, development projects gain access to a larger skills base—
project managers can choose developers skilled in any
programming language and join them together on the same team.
Alternately, developers writing components for a distributed
application will find it helpful to know that no matter what language
they choose to write their components in, those components can
interact closely with each other and with components supplied by
other developers.

Simplified Code through Typed Programming

Programmers manipulate .NET Framework objects through typed

programming. Typed programming is programming in which the
types of things are recognized and known by the programming
environment or by the programming language itself.

For example, consider the following line of code, which uses generic
(non-typed) programming:

If TotalCost >
Table("Customer").Column("AvailableCredit")

The code contains words such as "Customer" and "Available Credit"

that are relevant to the application developer—and end user—but it
also exposes implementation details, such as "Table" and “Column."

As a summary statement, typed programming is a style of

programming in which the application terminology figures
prominently in the business logic. For example, consider this next
line of code, which uses typed programming involving the ADO.NET
classes:

If TotalCost >
DataSet1.Customer("Jones").AvailableCredit

This line of code is equivalent to the earlier line that used non-typed
programming. In the typed code, the code is easier to read: A
business analyst with little or no programming experience can grasp
the meaning of the condition being tested without having to filter out
the data programmer vocabulary in the conventional line of code.

The typed code is also easier to write, because statement

completion (for example, IntelliSense® in Visual Studio .NET) can
be provided. "AvailableCredit" is among the list of choices provided
by the IDE for completing the following statement:

IF TotalCost > Customer…

Microsoft .NET Framework Evaluation Guide xiii

In addition, the typed code is safer, because it provides for the
compile-time checking of types. For example, suppose that
AvailableCredit is expressed as a currency value. If the
programmer erroneously assigns a string value to
AvailableCredit, the typed environment reports the error to the
programmer during compile time. In a weakly typed programming
environment, the programmer would not learn of the error until run
time.

Metadata and Self-Describing Components

The .NET Framework enables the creation of self-describing

components, which simplify development and deployment and
improve system reliability. Self-description is accomplished through
metadata—information contained in the binary that supplements the
executable code, providing details about dependencies, versions,
and so on. The metadata is packaged together with the component
it describes, resulting in self-describing components.

A key advantage of self-describing components is that you do not

need any other files in order to use a component. This contrasts with
typical application development today, which requires separate
header files for class definitions, separate Interface Description
Language (IDL) files, separate type libraries, and separate proxies
and stubs. Since the metadata is generated from the source code
during the compilation process and stored with the executable code,
it is never out of sync with the executable.

Because each application contains a full description of itself, the

CLR can dynamically assemble a cache of information about the
components installed on a system. If that cache becomes damaged
somehow, the runtime can rebuild it without the user even knowing.
In addition to solving development challenges, self-description
eliminates the dependency on the Windows registry for locating
components. A benefit of not relying on the Windows registry is the
ability to do XCOPY deployment.

XCOPY Deployment

This is the ability to simply copy an application to a target machine

and have it run, without any registration of the dynamic-link libraries
(DLLs) and without any installation scripts. By default, applications
are completely self-contained. An executable lives in an application
directory with all the DLLs and resources it needs. To install an
application onto a target machine, simply copy its application
directory into the appropriate location on disk. The CLR will simply
look within the executable's directory to fulfill any dependencies it
might have.

Microsoft .NET Framework Evaluation Guide xiv

Global Assembly Cache

In local disk-constrained scenarios, an administrator may share

DLLs among multiple applications using the .NET Framework global
assembly cache (GAC). The GAC effectively serves as an
intelligent store for DLLs and is used in place of the system registry
when working with DLLs written using the .NET Framework. It can
contain multiple versions of a given DLL. Each DLL entered into the
GAC is entered with a “strong name.” This consists of a digital
signature, the name of the DLL, its version number, and the culture
for which it was created (for example, English, German, Japanese,
and so on). This information enables the GAC to differentiate
between different versions of a given DLL.

There are several ways to deploy a DLL into the global assembly
cache. The .NET Framework ships with a command line utility
(gacutil.exe) as well as a Microsoft Management Console snap-in
(the .NET Framework Configuration Tool) which can also be used.
Alternatively, one can simply drag and drop the assembly into the
GAC using Windows Explorer.

By default, the CLR will retrieve from the GAC the particular DLL
against which an executable was compiled. However,
administrators may write a simple XML configuration file or use
the .NET Framework Configuration Tool to redirect an executable to
bind against a different version of a DLL than the one against which
it was built.

Side-by-Side Execution

The isolation of DLLs in their own application directories in the

XCOPY deployment scenario and the global assembly cache in the
shared DLL scenario enable side-by-side execution. This refers to
the fact that different versions of a DLL can be installed on a system
and run concurrently inside different applications without any
conflicts. (In fact, this is true of the .NET Framework as well.
Different versions of the .NET Framework may be installed and
execute on a machine concurrently. More information on this may
be found in Appendix A.)

Side-by-side execution all but eliminates so-called “DLL hell”—a

common scenario in which a new version of a DLL would replace an
older version in the system registry, resulting in incompatibilities with
applications that had been depending upon functionality or behavior
present only in the older version.

No-Touch Deployment

As before, smart client applications can be delivered by CD, DVD, or

floppy disk, or through application deployment infrastructure such as

Microsoft .NET Framework Evaluation Guide xv

Microsoft Systems Management Server. Thanks to the fact that
DLLs no longer have to be registered by default, the .NET
Framework introduces yet another option: No-Touch Deployment,
deploying the application from a remote Web server using the
Hypertext Transfer Protocol (HTTP).

Essentially, this process mirrors the Web application deployment

approach. An administrator just copies the application onto a Web
server. The user can then navigate to the URL of the executable in
Microsoft Internet Explorer, and the CLR will automatically download
the application into the .NET Framework assembly download cache
and begin to run it, outside of the browser. Going forward, if the
executable or DLL required is already on the client computer and the
version on the Web server has not changed, the local copy will be
loaded. If the version on the Web server has been updated, that new
version will be downloaded and executed. Thus, updates are
automatically propagated to the client, but the network is not flooded
with redundant downloads. More detail on this will be provided later,
in the section entitled “Building Smart Client Applications.”

No-Touch Deployment is made safe through a technology called

code access security, which prevents un-trusted or partially-trusted
code from performing undesired actions on the end user's machine.

Code Access Security

The .NET Framework takes a major step forward in software

security by introducing a fine-grained, evidence-based security
system called code access security. This security system now gives
the systems administrator a wide range of granular permissions that
can be granted to code in place of the “all-or-nothing” or “sandbox”
security models available with many earlier software technologies.
The permissions granted are tailor-fit to each managed code
application based on evidence about the application. Evidence can
be any data about the application, including its origin, its location on
disk, the presence of a digital signature, and so on. Permissions
can refer to resources or operations such as accessing the local
disk, interacting with databases or other servers, displaying user
interface, printing, and so on.

Because the CLR is used to load code, create objects, and make
method calls, the runtime can actually perform low-level security
checks and enforce these security policies as code is loaded and
executed.

This design ensures that semi-trusted code cannot perform

unauthorized actions, which improves overall system safety and
reliability.

In version 1.0 of the .NET Framework, code access security did not

Microsoft .NET Framework Evaluation Guide xvi

 apply to ASP.NET Web applications or XML Web services. In
version 1.1 of the .NET Framework, code access security can be
used to constrain the permissions granted to ASP.NET applications
beyond what is possible using Windows Access Control Lists (See
Appendix A for details).

The Unified Class Libraries

The classes of the .NET Framework provide a unified, object-
oriented, hierarchical, and extensible set of class libraries, or
application programming interfaces (APIs), that developers can use
from the languages they are already familiar with.

Previously, Visual C++ developers used the Microsoft Foundation

Classes, Microsoft Visual J++® developers used the Windows
Foundation Classes, and Visual Basic developers used the classes
provided by the Visual Basic runtime. Simply put, the classes of
the .NET Framework provide a superset of the functionality of all of
these other libraries— one which may be accessed by any of the
programming languages supported by the .NET Framework. By
creating a common set of APIs across all programming languages,
the .NET Framework enables such powerful features as cross-
language inheritance and method calls, error handling, and
debugging. In effect, all programming languages—from JScript to
C++—become equal and developers are free to choose the right
language for the job at hand.

Some of the .NET Framework key class libraries are shown in the
The .NET Framework class libraries figure at left.

The .NET Framework includes a base set of class libraries that

developers would expect in any standard library, such as collections,
input/output, data type, and numerical classes. In addition, there are
classes that provide access to all of the operating system services—
such as graphics, networking, threading, globalization, cryptography,
and data access; classes that development tools can use for
purposes such as debugging; as well as a set of classes that supply
the services necessary for building enterprise-scale applications,
such as transactions, events, partitions, and messaging.

We will first take a look at the three high-level class libraries used to
build server and client applications, specifically:

 ASP.NET (System.Web)

 XML Web Services (System.Web.Services)

 Windows Forms (System.Windows.Forms)

After covering these, we will then look at the other classes—such as

ADO.NET, remoting, and security—that can be used across all

Microsoft .NET Framework Evaluation Guide xvii

 application types.

Then, in subsequent sections of this document, you will learn how to

use some of these classes in the .NET Framework to build:
1) A Web application and XML Web service.
2) A Windows-based smart client application.

ASP.NET
ASP.NET provides a set of controls as well as a run-time
environment and infrastructure that enable developers to build
scalable, reliable, and secure Web applications more quickly than
ever before.

ASP.NET comes with a set of server-side controls (sometimes

called Web Forms) that mirror the typical HTML user interface
widgets (including list boxes, text boxes, and buttons), and an
additional set of Web controls that are more complex (such as
calendars and ad rotators). These controls actually run on the Web
server and project their user interface as HTML to a browser. On the
A view of ASP.NET
server, the controls expose an object-oriented programming model
that brings the richness of object-oriented programming to the Web
developer.

One important feature of these controls is that they can be written to

adapt to client-side capabilities; the same pages can be used to
target a wide range of client platforms and form factors. In other
words, ASP.NET controls can sniff the client that is requesting a
page and return an appropriate user experience—HTML 3.2 for a
down-level browser and Dynamic HTML for Internet Explorer 5.5. In
the case of the ASP.NET mobile controls, which will be discussed in
more detail below, the controls can go even further, returning
XHTML or WML, for example, if required.

ASP.NET also provides features such as cluster session-state

management and process recycling, which dramatically increase
application reliability.

ASP.NET works with all development languages and tools (including

Visual Basic, C++, C#, and JScript). We will have a lot more to say
about ASP.NET in the section entitled Microsoft's Application
Platform.

XML Web Services

Integrating systems has historically been a daunting and expensive
process. Integration solutions were often point-to-point, minimizing
opportunities for code reuse should one of the systems in question
eventually need to integrate with other systems. Solutions were also
often brittle, relying on technology such as HTML “screen-
scraping”—which broke down whenever the “client” Web site

Microsoft .NET Framework Evaluation Guide xviii

 Browsers
Other Web
changed its format.
Services
XML
W eb
XML Web services are components which facilitate integration
S ervices
Business Partners
across platforms by sharing data and functionality over the network
Devices

Open Internet
through standard, platform-independent protocols such as XML,
Communications Protocols
(HTTP, SMTP, XML, SOAP) SOAP, and HTTP. XML Web services provide a low-cost, scalable,
Cellular Rich and flexible solution to the challenges of integration.
Phones Clients

An XML Web service is an application that XML Web services solve the challenges facing Web developers by
exposes its functionality programmatically combining the tightly coupled, highly productive aspects of n-tier
over the Internet or intranets using standard
computing with the loosely coupled, message-oriented concepts of
Internet protocols, such as HTTP and XML.
the Web. Think of XML Web services as component programming
over the Web.

Conceptually, developers integrate XML Web services into their

applications by calling the methods exposed in this manner just as
they would call local services. The difference is that these calls can
be routed across the network to a service residing on a remote
system. For example, an XML Web service such as Microsoft
MapPoint® provides mapping and location functionality to client
applications from a remote set of Microsoft-hosted servers. By
programming against the MapPoint service, a developer could take
advantage of MapPoint's logic and infrastructure—shifting a whole
set of a development and operational chores. From an integration
perspective, because MapPoint was implemented as an XML Web
service, any client, written in any programming language, running on
any platform, can interact with it.

Clearly, a considerable amount of infrastructure is required to make

building XML Web services transparent to developers and users.
The Microsoft .NET Framework provides that infrastructure in the
System.Web.Services classes, part of the ASP.NET library. There,
the .NET Framework supplies an application model and key
enabling technologies to simplify the creation, deployment, and
ongoing evolution of secure, reliable, scalable, and highly available
XML Web services while building on existing developer skills.

To the .NET Framework, all components can be XML Web services,

and XML Web services are just another kind of component. In effect,
the .NET Framework combines the best aspects of COM with the
best aspects of loosely coupled XML Web services-style
applications. The result is a powerful, productive Web component
system that simplifies program plumbing, deeply integrates security,
introduces an Internet-scale deployment system, and greatly
improves application reliability and scalability.

The baseline XML Web services specifications are built using

industry standards:

 XML (Extensible Markup Language)

Microsoft .NET Framework Evaluation Guide xix

  SOAP (Simple Object Access Protocol)

 UDDI (Universal Description, Discovery, and Integration)

 WSDL (Web Services Description Language)

We will cover each of these standards in greater detail in the section

of this document entitled Microsoft's Application Platform.

Microsoft has also announced that the .NET Framework will be

enhanced to support the Global XML Web Services Architecture
(GXA). This architecture builds on these base XML Web services
standards to provide principles, specifications, and guidelines to
address more complex and sophisticated tasks in standard ways.
These enhancements include coordinating the actions of distributed
applications, inspecting available services, routing messages,
enhancing message security, and supporting transactions. See the
section entitled “Global XML Web Services Architecture (GXA)” in
Appendix B of this document for more information.

Windows Forms
The unified class libraries also offer full, rich support for developing
Windows-based smart client applications.

Developers who write smart client applications for Windows can use
the Windows Forms (System.Windows.Forms) classes to take
advantage of all the rich user interface features of the operating
system, reuse existing Microsoft ActiveX® controls, harness the
graphical capabilities of the GDI+ graphics library, and build
applications that will run offline. Smart client applications may
consume XML Web services in the same manner as ASP.NET Web
applications. Overall, developers will find the Windows Forms
classes and Visual Studio .NET design-time support for them very
intuitive, given their similarities to existing Windows-based forms
packages.

Since it is part of the .NET Framework, Windows Forms can

automatically take advantage of .NET Framework features such as a
common type system; strongly typed code; memory management;
and all of the deployment, security, and administration features of
.NET Framework-based applications.

We will cover Windows Forms development in greater detail in the

section of this document entitled Building Smart Client Applications.

Common System Namespaces

The three class libraries we just looked at—used to build particular
types of applications—rely heavily on a number of common class
libraries. We will focus on a few of these below:

Microsoft .NET Framework Evaluation Guide xx

  ADO.NET (System.Data)

 XML (System.XML)

 Directory Services (System.DirectoryServices)

 Enterprise Services (System.EnterpriseServices)

 InteropServices (System.Runtime.InteropServices)

 Management (System.Management)

 Remoting (System.Runtime.Remoting)

 Security (System.Security)

Data Access with ADO.NET

Nearly all applications need to query or update persisted data,
whether it is contained in simple files, relational databases, or any
other type of store. To fulfill this need, the .NET Framework includes
ADO.NET, a data access subsystem optimized for n-tier
environments. For easy cross-platform interoperability, ADO.NET
uses XML as its native data format. As the name implies, ADO.NET
evolved from ADO (ActiveX Data Objects).

Designed for loosely coupled environments, ADO.NET provides a

high-performance, disconnected data model, which maximizes
scalability and is thus more suitable for returning data to Web
applications.

As you develop applications, you will have different requirements for

working with data. In some cases, you might simply want to display
data on a form. In other cases, you might need to devise a way to
share information with another company. No matter what your
requirements are, there are a few fundamental concepts key to
understanding data handling in the .NET Framework.

Disconnected Data Architecture

In traditional two-tier applications, components establish a
connection to a database and keep it open while the application is
running. For a variety of reasons, this approach is impractical in
many applications:

 Open database connections take up valuable system

resources. The overhead of maintaining these connections
impacts overall application performance.

 Applications that require an open database connection

are extremely difficult to scale. An application that might
perform acceptably with four users will likely not do so with
one hundred. Web applications, in particular, need to be
easily scalable, because traffic to a Web site can go up by

Microsoft .NET Framework Evaluation Guide xxi

 orders of magnitude in a very short period.

 In Web applications, the components are inherently

disconnected from each other. The browser requests a
page from the server; when the server has finished
processing and sending the page, it has no further
connection with the browser until the next request. Under
these circumstances, maintaining an open connection to a
database is not viable, because there is no way to know
whether the data consumer (the client) requires further data
access.

 A model based on connected data can make it difficult

to share data between components, especially
components in different applications. If two components
need to share the same data, both components have to be
connected, or a way must be devised for the components to
pass data back and forth.

For all these reasons, data access in ADO.NET is designed around

a disconnected architecture. Applications are connected to the
database only long enough to fetch or update the data. Because the
database is not hanging on to connections that are largely idle, it
can service many more users.

Data Is Cached in Datasets

Far and away the most common data task is to retrieve data from
the database and do something with it: display it, process it, or send
it to another component. Very frequently, the application needs to
process not just one record, but a set of them: a list of customers or
today's orders, for example. Often the set of records that the
application requires comes from more than one table: my customers
and all their orders; all authors named "Smith" and the books they've
written; and other, similar, sets of related records.

Once these records are fetched, the application typically works with
them as a group. For example, the application might allow the user
to browse through all the authors named "Smith" and examine the
books for one Smith, then move to the next Smith, and so on.

In a disconnected data model, it's impractical to go back to the

database each time the application needs to process the next
record. (Doing so would undo much of the advantage of working
with disconnected data in the first place.) The solution, therefore, is
to temporarily store the records retrieved from the database and
work with this temporary set.

This temporary dataset is a cache of records retrieved from the

database. It works like a virtual data store—it includes one or more

Microsoft .NET Framework Evaluation Guide xxii

tables based on the tables in the actual database (or databases),
and it can include information about the relationships between those
tables and constraints on what data the tables can contain.

The data in the dataset is usually a much-reduced version of what's

in the database. However, you can work with it in much the same
way you work with the real data. While you are doing so, you remain
disconnected from the database, which is thus freed to perform
other tasks.

Because you often need to update data in the database (although

not nearly as often as you retrieve data from it), you can perform
update operations on the dataset, and these are written through to
the underlying database.

Scalability
Because the Web can vastly increase the demands on your data,
scalability has become critical. Internet applications have a limitless
supply of potential users. An application that consumes resources
such as database locks and database connections will not serve
high numbers of users well, because the user demand for those
limited resources will eventually exceed their supply. Because
applications using ADO.NET employ disconnected access to data,
they do not retain database locks or active database connections for
long durations and thus offer performance advantages.

XML and Data

Data and XML are tightly integrated in the .NET Framework, where
the System.Xml namespace provides standards-based support for
processing XML. The supported standards are:

 XML 1.0

 XML Namespaces

 XSD Schemas

 XPath expressions

 XSLT transformations

 DOM Level 1 and DOM Level 2 Core

In fact, in ADO.NET, XML is the fundamental format for sharing and

remoting data. When you share data, the ADO.NET APIs
automatically create XML files or streams out of information in the
dataset and send them to the requesting component. The second
component can invoke similar APIs to read the XML back into a
dataset. In fact, if you have an XML file available, you can use it like
any data source and create a dataset out of it.

Why XML? There are several reasons:

Microsoft .NET Framework Evaluation Guide xxiii

  XML is an industry-standard format. This means that
your application data components can exchange data with
any other component in any other application, as long as
that component understands XML. All applications can be
written to understand XML, which provides an
unprecedented level of exchange between disparate
applications.

 XML is text-based. The XML representation of data uses

no binary information, which enables XML to be sent
through any protocol, such as HTTP. Most firewalls block
binary information, but by formatting information in XML,
components can still easily exchange the information.

 Interoperability. ADO.NET enables easy creation of

custom XML documents through the use of XSD schemas.
The resulting XSD schemas format the XML specific for
your use.

ADO.NET applications can take advantage of the flexibility and

broad acceptance of XML. Because XML is the format for
transmitting datasets among components and across tiers, any
component that can read the XML format can process an ADO.NET
dataset. As an industry standard, XML was designed with exactly
this kind of interoperability in mind.

Best of all, one need not have any familiarity with XML to access
and manipulate data via ADO.NET. ADO.NET automatically
converts data into and out of XML as needed; you interact with the
data using ordinary programming methods.

Directory Services
The Directory Services classes provide easy access to Active
Directory from managed code. They are built on Active Directory
Services Interfaces (ADSI) technology, which provides a set of
interfaces that serve as a flexible tool for working with a variety of
network providers. ADSI gives the administrator the ability to locate
and manage resources on a network with relative ease, regardless
of the network's size.

Directory Services can be used with any of the Active Directory

service providers. The current providers are: Internet Information
Services (IIS), Lightweight Directory Access Protocol (LDAP), Novell
NetWare Directory Service (NDS), and WinNT.

Enterprise Services
Using the Enterprise Services classes, developers can create
“serviced components” that take advantage of COM+ services.
COM+ provides a services architecture for component programming

Microsoft .NET Framework Evaluation Guide xxiv

 models deployed in an enterprise environment. Some of these
services available include Just-in-Time (JIT) Activation,
Synchronization, Object Pooling, Transactions, and Shared Property
Management. In a disconnected environment typical of Web-based
applications, additional COM+ services can be used such as loosely
coupled events, Queued Components, and role-based security.

Automatic Transaction Support

One of the most critical COM+ features that developers will want to
use is Transactions, which ensure that multiple related data
operations happen together or not at all and thus enhance data
integrity. It is easy to build applications that use transaction support
in the .NET Framework through simple keywords and settings. In
fact, the .NET Framework takes advantage of the COM+ transaction
infrastructure to provide both manual and automatic distributed
transactions.

The beauty of the integration between the .NET Framework and

COM+ transactions is that .NET Framework developers can use the
high-performance COM+ transaction environment without needing to
learn COM+. For example, you can simply copy your .NET
Enlisting in a transaction Framework components that need COM+ Services such as
transactions into a directory, and the .NET Framework will
dynamically add the components to the COM+ transaction monitor.

InteropServices
InteropServices provide a collection of classes useful for accessing
the Win32 APIs and COM objects from .NET Framework-based
code. This is a great way to harness the functionality of legacy code
as you move forward in your development. It also provides access
to functionality not directly available in the .NET Framework class
libraries.

InteropServices' platform invoke (p/invoke) enables managed code

to call unmanaged functions implemented in DLLs, such as those in
the Win32 API.

Using COM Interop, it is also possible to call between COM types

and managed code. To use a COM object from .NET, a managed
definition of the COM type must be made available to the managed
code. The InteropServices namespace provides managed
definitions of many common interfaces. In addition, tools provided
with the .NET Framework software development kit (SDK) enable
developers to generate run-time callable wrapper assemblies
around COM components, as well as COM callable type libraries for
managed assemblies that allow .NET components to be invoked by
COM components.

Microsoft .NET Framework Evaluation Guide xxv

The .NET Framework extends the COM model for reusability by
adding implementation inheritance. Managed types can derive
directly or indirectly from a COM class; more specifically, from the
run-time callable wrapper generated by the CLR. The derived type
can expose all the method and properties of the COM object as well
as methods and properties implemented in managed code. The
resulting object is partly implemented in managed code and partly
implemented in unmanaged code.

InteropServices is also used to indicate how data should be

transferred—or “marshaled”—between managed and unmanaged
memory. Finally, InteropServices manages exceptional
circumstances such as errors while performing certain operations,
and serves as a way to bridge COM HRESULT errors to .NET
Framework exceptions.

Management
Management services provide access to a rich set of management
information and management events about the system, devices, and
applications instrumented to the Windows Management
Instrumentation (WMI) infrastructure.

WMI is a component of the Windows operating system that provides

management information and control in an enterprise environment.
Using industry-wide standards, WMI enables managers to query and
set information on desktop systems, applications, networks, and
other enterprise components. Developers can use WMI to create
event monitoring applications that alert users when important
incidents occur.

Applications and services can query for interesting management

information—such as how much free space is left on the disk, what
the current CPU utilization is, which database a certain application is
connected to, and much more, or subscribe to a variety of
management events. The accessible data can be from both
managed and unmanaged components in the distributed
environment.

The System.Management.Instrumentation namespace provides the

classes necessary for instrumenting applications for management
and exposing their management information and events through
WMI to potential consumers. Consumers such as Microsoft
Application Center or Microsoft Operations Manager can then
manage your application easily, and monitoring and configuring of
your application is available for administrator scripts or other
applications, both managed as well as unmanaged.

Microsoft .NET Framework Evaluation Guide xxvi

Remoting
You can also use remoting (available through
System.Runtime.Remoting) to enable different applications to
communicate with one another, whether those applications reside
on the same computer, on different computers in the same local
area network, or across the world in very different networks. Unlike
XML Web services, remoting can only take place between
applications and components running on the .NET Framework.

The .NET Framework provides a number of services used by

remoting such as activation and lifetime control as well as
communication channels for transporting messages to and from
remote applications. Formatters are used to encode and decode the
messages before they are sent along a channel. Applications can
use XML encoding or binary encoding, in situations where
performance is critical. Remoting was designed with security in
mind, so you can access the call messages and serialized streams
in order to secure them before they are transported over the
channel.

The remoting infrastructure is an abstract approach to inter-process

communication. Much of the system functions without requiring any
attention. For example, objects that can be passed by value, or
copied, are automatically passed between applications in different
application domains or on different computers. You need only mark
your custom classes as serializable to make this work.

The real strength of the remoting system, however, resides in its

ability to enable communication between objects in different
application domains or processes using different transportation
protocols, serialization formats, object lifetime schemes, and modes
of object creation. In addition, if you need to intervene in almost any
stage of the communication process, for any reason, remoting
makes this possible.

Whether you have implemented a number of distributed applications

or are simply interested in moving components to other computers
to increase the scalability of your program, it is easiest to
understand the remoting system as a generic system of inter-
process communication with some default implementations that
easily handle most scenarios. While XML Web services are an ideal
mechanism for building integrated, distributed applications across a
public network, remoting can be used where performance has a
greater emphasis, where end-to-end network connectivity can be
specified, and where application architecture requires passing
remote object references rather than data.

Microsoft .NET Framework Evaluation Guide xxvii

 Security
As we mentioned earlier, code access security provides fine-
grained, method-level control over what applications can and cannot
do based on who wrote the code, what it's trying to do, where it was
installed from, and so on.

The .NET Framework System.Security namespace, in combination

with the CLR, provides this code access security infrastructure along
with role-based security functionality and an extensible library of
cryptographic functions.

Code Access Security and Role-based Security

The .NET Framework offers security through two high-level
categories: code access security and role-based security.

Code access security is deeply integrated into the .NET Framework,

and, as mentioned before, it provides security enforcement of
different levels of trust on different components. For example, code
originating from the Internet through No-Touch Deployment, for
example, should be trusted less and granted fewer permissions than
code coming from a known, reliable vendor.

Using the System.Security classes, developers can interact with the

code access security infrastructure in the CLR at load time and run
time. They might choose to refuse any superfluous permissions
granted in order to further “lock down” their code. They might
Configuring security by zone in the .NET
demand that their code not be loaded or that it behave differently (by
Framework Configuration Tool disabling buttons, for example) if certain permissions, integral to its
operation, are not granted, so as to avoid a frustrating user
experience.

Role-based security is based on two fundamental concepts:

authentication and authorization. Authentication is the process of
validating a set of user credentials against an authority. If the
credentials are valid, that user is said to have a particular identity.
Authorization is the process of using that identity to grant access to
or protect a resource.

Applications can authenticate users with all of the common

authentication protocols, including Basic; Digest; Microsoft Passport;
Integrated Windows Authentication (Kerberos on Windows 2000,
Windows Server 2003, and Windows XP, and Windows NT® LAN
Manager, or NTLM, for Windows 98, Windows NT, and Windows
Me); or custom, forms-based authentication. The application
program is written the same way no matter what type of
authentication is used.

Authorization may be accomplished using Access Controls Lists on

resources in Windows, through Active Directory, via XML

Microsoft .NET Framework Evaluation Guide xxviii

 configuration files, or through custom authorization check (for
example, database queries).

Cryptography APIs
The classes located at System.Security.Cryptography provide
developer-friendly access to most of the popular hash, encryption,
decryption, digital signature, and random number generation
algorithms. This progressive set of functionality includes support for
the XML Digital Signature, recently ratified by the World Wide Web
Consortium.

.NET Framework Device Support

The .NET Framework supports two different forms of mobile device
applications: those that run locally on the device on a compact
version of the .NET Framework and those that run in the device's
Web browser. .

.NET Compact Framework

The Microsoft .NET Compact Framework is an integral Windows
component used for running consumer and enterprise smart client
software applications on resource-constrained devices, such as
Pocket PC and other Windows CE-based systems. It provides a
highly productive environment for integration with virtually any data
source, ranging from local SQL Server CE databases to enterprise
back ends through XML Web services.  The .NET Compact
Framework's unified, hierarchical class library also enables software
developers to rapidly construct rich user interfaces, access native
operating system methods, and interoperate with assets on the
device, such as the infrared data port and other hardware
extensions.

The .NET Compact Framework supports a large subset of the .NET

Framework class libraries and the CLR. Supported devices include
the Pocket PC 2000, Pocket PC 2002, Pocket PC 2002 Phone
Edition, and custom-designed embedded devices built with the
Windows CE .NET 4.1 operating system. Earlier versions of
Windows CE .NET are not supported.
The .NET Compact Framework provides the following key features:

 A compact CLR that brings the benefits of managed code,

.NET Compact Framework application on a such as memory management, code reliability, and
smart device programming language neutrality, to devices.

 Consistency with desktop and server programming models.

 Seamless connection with XML Web services.

 Rich enterprise class data access features with XML

Microsoft .NET Framework Evaluation Guide xxix

 classes and ADO.NET.

 Classes to program applications that access data using

Microsoft SQL Server 2000 Windows CE Edition 2.0.

 Full access to native Windows platform features through

platform invoke.

 Just-in-time (JIT) compilation for optimal performance.

Visual Studio .NET 2003 enables developers to create projects that

target the .NET Compact Framework. Effectively, it enhances Visual
Basic .NET and Microsoft Visual C#® .NET with device-specific
project types and a forms designer to implement .NET Compact
Framework Windows Forms controls. You can debug and deploy
directly to a device or to Pocket PC and Windows CE .NET
emulators.

ASP.NET Mobile Controls

ASP.NET mobile controls (formerly the Microsoft Mobile Internet
Toolkit) extend the .NET Framework and Visual Studio .NET by
providing support for mobile (wireless) devices such as mobile
phones and PDAs. The .NET Framework version 1.1 incorporates
the mobile controls into the .NET Framework and Visual Studio
.NET distributions.

ASP.NET mobile controls extend ASP.NET server controls such that

they adapt to the mobile device on which the Web application is
rendering. Through browser detection, the mobile controls conform
to the markup language and user interface capabilities of individual
devices ranging from full-featured PDA browsers to small, 5-line ×
20-character mobile phone displays. This adaptive rendering feature
handles many of the tedious device-specific rendering decisions and
frees you to focus on your core Web application logic.

Administration
The .NET Framework includes technologies to make applications
more reliable. For example, memory, threads, and processes are
managed by the .NET Framework to ensure that memory leaks don't
occur. The Framework also monitors running ASP.NET Web
applications and can automatically restart them at administrator-
The .NET Framework defined intervals. Many of the reliability features in the .NET
Configuration Tool menu
Framework come from the application services supplied by the
unified classes called Enterprise Services
(System.EnterpriseServices). Using the same engine as COM+,
these application services provide such features as transactions,
messaging, events, partitions, and object request broker.

In addition, a number of utilities are provided with the .NET

Microsoft .NET Framework Evaluation Guide xxx

Framework to help administrators work with the Framework and
applications. In particular, the .NET Framework Configuration Tool
running in the Microsoft Management Console lets you work with the
global assembly cache and configure code access security policy. It
has scriptable command line tool equivalents in the gacutil and
caspol utilities, respectively.

Tools for Developing with the .NET

Framework
You can start your development with the .NET Framework
Software Development Kit. This SDK comes with comprehensive
documentation on the Framework, including all of the namespaces
and types within. The SDK also includes several hundred samples—
in Visual Basic, C#, and often JScript or C++—that illustrate how to
work with the major features of the .NET Framework. There are
even several complete tutorials to help developers get up to speed
on writing and debugging programs, using resources, and packaging
and deployment. Finally, the SDK also includes a large number of
tools for debugging, managing, and securing .NET Framework-
based programs. Since several programming language compilers
are included with the .NET Framework SDK, this and a text editor
application, such as Notepad, might be all you need to get started.
The .NET Framework SDK is located on the MSDN® site in the
.NET Development area at http://msdn.microsoft.com/net.

However, most developers will want to make use of an IDE tailored

specifically for writing .NET Framework-connected applications. If
you're a hobbyist interested only in developing Web applications,
then you can download the Microsoft ASP.NET Web Matrix, which
is a small (1.2 megabytes), free, community-supported tool for
building applications with the ASP.NET class libraries. It features a
page designer, integrated database management, support for XML
Web services, mobile applications, and even a personal Web server
for development and testing. ASP.NET Web Matrix can be found on
Microsoft's ASP.NET community Web site at
http://www.asp.net/webmatrix.

For professional developers, Microsoft Visual Studio .NET provides

a comprehensive set of development tools for building all types of
applications using the .NET Framework. In addition to providing an
integrated design, development, test, and debugging environment
with powerful features such as IntelliSense for code development
and designers for Web, Windows-based, and device applications,
Visual Studio features numerous advanced capabilities that will be
of interest to enterprise application developers.

Visual Studio .NET maximizes the productivity of developers

Microsoft .NET Framework Evaluation Guide xxxi

 working with databases by providing integrated support for
designing databases, SQL queries, and SQL scripts and stored
procedures. Visual Studio .NET also simplifies multiple-tier
development by extending the rapid application development (RAD)
principles of visual design to the creation, testing, and deployment of
server-based solutions. These features enable programmers to
drag and drop visual representations of server components, such as
message queues, remote servers, Windows services, and more,
onto a design surface.

Visual Studio .NET targets the entire development life cycle, from
planning and design, through development and testing, to
deployment and ongoing management. With its open model for
extending the IDE through third-party products, Visual Studio .NET
provides the most comprehensive, adaptable environment for
delivering all facets of the enterprise-critical application portfolio.

You can use the same IDE for developing with each of the
programming languages supported by the .NET Framework.
Developers wishing to program with some of the languages not
implemented directly by Microsoft may purchase the compilers from
vendors, such as those listed at
http://msdn.microsoft.com/vstudio/partners/language/default.asp,
and integrate those compilers into the Visual Studio .NET shell.

You can find out more about Visual Studio .NET at

http://msdn.microsoft.com/vstudio/.

In addition to the Microsoft tools for developing with the .NET

Framework, other applications tools vendors have announced their
support for this new programming model. For example, Borland
Software Corporation's Enterprise Studio for Windows will support
.NET Framework-enabled versions of Delphi and C++
(http://www.borland.com/estudiowin/index.html) and Dreamweaver
MX (http://www.macromedia.com/software/dreamweaver/) from
Macromedia Inc. can be used to develop ASP.NET applications.

Finally, a new set of end-to-end sample applications called the

ASP.NET Starter Kits is available on the ASP.NET community Web
site at http://www.asp.net/starterkits. The ASP.NET Starter Kits
demonstrate how to build a complete application solution using the
technologies offered in ASP.NET. Each of the applications targets a
handful of technologies in ASP.NET and shows how to use them to
build a practical, everyday solution. Each Starter Kit sample is
complete and well-documented for immediate reuse in ASP.NET
The Visual Studio .NET Server Explorer development projects. A number of Starter Kits are available,
provides easy access to server-based resources.
including: The ASP.NET Community Starter Kit, Reports Starter Kit,
Time Tracker Starter Kit, Portal Starter Kit, and Commerce Starter
Kit. Details are provided in Appendix A: Changes from .NET

Microsoft .NET Framework Evaluation Guide xxxii

Framework 1.0.

Likewise, you can find a host of good, sample smart client code and
development tips and tricks on the Microsoft community smart client
application development site: http://www.windowsforms.net.
Included here is a major end-to-end sample application called
TaskVision at http://www.windowsforms.net/taskvision.

Deploying the .NET Framework

Redistributable
If you want to deploy a .NET Framework-based application to a
machine, you must first either verify that the machine has the .NET
Framework Redistributable already installed or you must install the
redistributable package as part of your setup process.

There are several methods for determining if the.NET Framework is

installed on a machine. The most reliable method—which can also
be automated—is to check for the
“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework”
key in the Windows system registry. This key can also be used to
determine which versions of the .NET Framework are installed on a
machine: each version will have its own key under the “Policy” sub-
key.

If your target machine does not have the .NET Framework installed,
you should first verify the minimum configuration requirements of
that machine. Detailed minimum hardware and software
specifications are detailed in Appendix B.

The .NET Framework may be installed manually by instructing your

users to visit the Microsoft site at
http://msdn.microsoft.com/netframework/downloads/howtoget.asp.

However, it may be more convenient for you to distribute the .NET

Framework Redistributable with your application. You can find the
NET Framework Deployment Guide at
http://msdn.microsoft.com/library/en-
us/dnnetdep/html/dotnetframedepguid.asp. This guide contains
information on redistributing the .NET Framework, technical
information for developers to make their application's setup invoke
the deployment package of the .NET Framework Redistributable,
and the .NET Framework Redistributable End-User License
Agreement (EULA) which is also available through the following link:
http://msdn.microsoft.com/library/en-us/dnnetdep/html/redisteula.asp

Microsoft .NET Framework Evaluation Guide xxxiii

 MICROSOFT'S
APPLICATION
PLATFORM
Microsoft's Application Platform
Microsoft's application platform refers to the combination of
Windows; the .NET Framework for building, deploying, and running
connected applications and XML Web services; and the Visual
Studio .NET IDE.

The application platform is the combination of operating system,

component execution environment, services, and tools for creating,
executing, and managing server-based componentized software in a
loosely coupled world.

With superior performance, scalability, and reliability, the Microsoft

application platform exceeds corporate requirements for application
development and operation. Indeed, only a year after its formal
introduction, customers have already proclaimed the new Microsoft
application platform an unequivocal success, proven through large
scale deployments worldwide.

Traditional application servers offer a dynamic Web environment

along with business component services. The Microsoft application
platform delivers this core functionality and adds native support for
XML Web services for interoperability, open standards support for
distributed transactions, an intuitive designer and API support for
smart client and mobile device application development, and rich
standards support for programming languages, XML, SOAP, WSDL,
UDDI, and more.

Using the Enterprise Services classes, developers can create

“serviced components” on the application platform that take
advantage of the COM+ services architecture for applications
deployed in an enterprise environment. In particular, COM+
transactions ensure that multiple related data operations happen
together or not at all, thus enhancing the data's integrity.

The beauty of the integration between the .NET Framework and

COM+ transactions is that .NET Framework developers can use the
high-performance COM+ transaction environment without needing to
learn COM+. For example, you can simply copy your .NET
Framework components that need COM+ services, such as
transactions, into a directory, and the .NET Framework will
dynamically add the components to the COM+ transaction monitor.

The Microsoft application platform is designed to deliver the power

and strengths of the Windows platform to the developer. The .NET
Framework provides robust, programming language-independent,
developer-friendly access to the key features of Windows, while

Microsoft .NET Framework Evaluation Guide xxxiv

Visual Studio .NET maximizes developer productivity programming
with the .NET Framework. Smart client application development is
discussed in detail in the section entitled Building Smart Client
Applications. The remainder of this section will focus on Web
application development.

Web Applications with ASP.NET

ASP.NET refers to the class libraries in the .NET Framework for
building powerful Web applications and XML Web services.
ASP.NET offers numerous important advantages over previous Web
development models. Many of these will be discussed in detail later,
but at a high level, ASP.NET provides:

 The ability to create and reuse UI controls that can

encapsulate common functionality. This reduces the
amount of code that a developer has to write and facilitates
code sharing.

 The ability for developers to cleanly structure their page

logic in an orderly fashion, using object-oriented code and
separating the design from the underlying application logic.

 The ability for development tools to provide strong

WYSIWYG design support.

 The ability to target nearly any browser, including mobile

device Web browsers.

 The technology to maximize application reliability and

performance.

 Support for event-driven programming of Web applications.

ASP.NET pages are text files with an .aspx file name extension.
They can be deployed throughout an IIS virtual root directory tree.
When a browser client requests .aspx resources, the ASP.NET
runtime parses and compiles the target file into a .NET Framework
class. This class can then be used to dynamically process incoming
requests. (Note that the .aspx file is compiled only the first time it is
accessed; the compiled type instance is then cached for reuse
across multiple requests.)

Inside ASP.NET
At the core of ASP.NET is its HTTP runtime (different from the
common language runtime), a high-performance execution engine
for processing HTTP commands. The HTTP runtime is responsible
for processing all incoming HTTP requests, resolving the URL of
each request to an application, and then dispatching the request to
the application for further processing. The HTTP runtime is
multithreaded, and it processes requests asynchronously—which

Microsoft .NET Framework Evaluation Guide xxxv

means it cannot be blocked by bad application code from processing
new requests. Furthermore, the HTTP runtime has a resilient design
that is engineered to recover automatically from access violations,
memory leaks, and deadlocks.

Tracing and Debugging

When developing an application, it is often helpful to be able to
insert debugging statements into your code to output variables or
structures, assert whether a condition is met, or just generally trace
through the execution path of the application. ASP.NET provides
two levels of tracing services that make it easy to do just that.

Page-level Tracing. At the page level, developers can use the

TraceContext class to write custom debugging statements that
appear at the end of the client output delivered to the requesting
browser. ASP.NET also inserts some helpful statements regarding
the start/end of life-cycle methods—for example, Init, Render, and
PreRender—in addition to the inputs and outputs to a page—such
as form and QueryString variables or headers—and important
statistics about the page's execution—including control hierarchy,
session state, and application state. Because tracing can be
explicitly enabled or disabled for a page as a whole, these individual
statements can be left in the production code for a page with no
impact to the page's performance. Each statement can be
associated with a user-defined category for organizational purposes,
and timing information is automatically collected by ASP.NET. The
resulting output can be ordered by either time or category.

Application-level Tracing. Application-level tracing provides an

aggregated view of requests to an application's pages. Like page-
level tracing, it also displays inputs and outputs to a page as well as
some important statistics about the page's execution. Application-
level tracing is enabled through the ASP.NET configuration system
(see below) and is accessed as a special mapped URL into that
application (Trace.axd). When application tracing is enabled, page-
level tracing is automatically enabled for all pages in that application
(provided there is no page-level directive to explicitly disable trace).

The following illustration shows the variety and completeness of

tracing information available to the developer:

Microsoft .NET Framework Evaluation Guide xxxvi

Application Configuration
A central requirement of any Web application platform is a rich and
flexible configuration system—one that enables developers to easily
associate settings with an installable application (without having to
hard code values into the application itself) and enables
administrators to easily customize these values post-deployment.
The ASP.NET configuration system has been designed to meet the
needs of both of these audiences; it provides a hierarchical
configuration infrastructure that enables extensible configuration
data to be defined and used throughout an application, site, and/or

Microsoft .NET Framework Evaluation Guide xxxvii

machine. It has the following qualities that make it uniquely suited to
building and maintaining Web applications:

 ASP.NET allows configuration settings to be stored

together with static content, dynamic pages, and business
objects within a single application directory hierarchy. A
user or administrator simply needs to copy a single
directory tree to set up an ASP.NET application on a
machine. This is XCOPY deployment, defined earlier.

 Configuration data is stored in plain XML text files that are

both human-readable and human-writable by administrators
and developers and can be accessed using any standard
text editor, XML parser, scripting language, or XML-aware
tool.

 ASP.NET provides an extensible configuration

infrastructure that enables third-party developers to store
their own configuration settings and participate in their
processing.

 Changes to ASP.NET configuration files are automatically

detected by the system and are applied without requiring
any user intervention.

 Configuration sections can be made secure and can be

prevented from being overridden.

Updating Applications
Another significant benefit of ASP.NET is support for live updating of
applications. Application files can be updated without an
administrator needing to shut down the Web server or even the
application—minimizing the impact on customers. Application files
are never locked, so they can be overwritten even when the
application is running. When files are updated, the system gracefully
switches over to the new version.

Extensibility
When an ASP.NET application executes, the HTTP requests are
routed through a pipeline of HTTP modules, ultimately to a request
handler. HTTP modules and request handlers are simply managed
classes that implement specific interfaces defined by ASP.NET—
interfaces that .NET Framework application developers can use and
extend. This modular architecture makes it very easy to add
services to applications: Just supply an HTTP module. For example,
security, state management, and tracing are implemented in
ASP.NET as HTTP modules. Support for XML Web services and
Web pages are also implemented as request handlers. An
application can be associated with multiple request handlers—one

Microsoft .NET Framework Evaluation Guide xxxviii

per URL—but all HTTP requests in a given application are routed
through the same HTTP modules.

State Management
The Web is fundamentally a stateless model with no correlation
between successive HTTP requests. This can make writing Web
applications difficult, since applications usually need to maintain
state across multiple requests. ASP.NET enhances the state
management services introduced by ASP to provide three types of
state to Web applications: application, session, and user. Application
session state is stored in a separate process and can even be
configured to be stored on a separate machine or persisted to a
SQL Server database for increased scalability even when an
application is deployed across the largest Web farms.

User state resembles session state, but is persisted and reused for
long-lived information. Thus user state is useful for storing user
preferences and other personalization information. All the state
management services are implemented as HTTP modules, so they
can be added, extended, or even removed from an application's
pipeline easily. If additional state management services are required
beyond those supplied by ASP.NET, they can be provided by a
third-party module.

Code Compilation
ASP.NET takes advantage of performance enhancements found in
the .NET Framework. Additionally, it has been designed to offer
significant performance improvements over ASP and other Web
development platforms. All ASP.NET code is compiled, unlike ASP
which was interpreted. This enables early binding, strong typing,
and huge performance benefits.

Caching
The ASP.NET programming model provides a cache API that
enables programmers to activate caching services to improve
performance. An output cache saves completely rendered pages,
and a fragment cache stores partial pages (that is, static
components of a given page). Classes are provided so that
applications, HTTP modules, and request handlers can store
arbitrary objects in the cache as needed.

Aggressive caching capabilities are provided as part of ASP.NET.

ASP.NET is designed to provide a robust Web application
environment capable of running mission-critical projects for long
periods of time.

The new caching and JIT compilation technologies are delivering

some significant improvements in Web application performance—a

Microsoft .NET Framework Evaluation Guide xxxix

throughput improvement of up to three times over existing ASP-
based applications,

ASP and ASP.NET Co-existence

Of course, you don't have to migrate all your existing applications to
start using ASP.NET. ASP.NET runs on IIS side-by-side with
classic ASP on Windows 2000, Windows Server 2003, and
Windows XP. Your existing ASP applications continue to be
processed by ASP.DLL, while new ASP.NET pages are processed
by the new ASP.NET runtime in the .NET Framework. You can
migrate an entire application or single pages. And ASP.NET even
lets you continue to use your existing classic COM business
components through COM interop.

Security
An important part of many Web applications is the ability to identify
users and control access to resources. The act of determining the
identity of the requesting entity is known as authentication.
Generally, the user must present credentials, such as a
name/password pair, in order to be authenticated. Once an
authenticated identity is available, it must be determined whether
that identity should be allowed access a given resource. This
process is known as authorization. ASP.NET works in conjunction
with IIS to provide authentication and authorization services to
applications.

An important feature of COM objects is the ability to control the

identity under which COM object code is executed. When a COM
object executes code with the identity of the requesting entity, this is
known as impersonation. ASP.NET Framework applications can
optionally choose to impersonate requests.

Some applications also need to be able to dynamically tailor content,

based on the requesting identity or based on a set of roles that a
requesting identity belongs to. ASP.NET applications can
dynamically check whether the current requesting identity
participates in a particular role. For example, an application might
want to check to see whether the current user belongs to the
manager's role, in order to conditionally generate content for
managers.

For additional information on Web application security, please see

the guide Building Secure ASP.NET Applications on the Microsoft
patterns & practices Web site:

http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnnetsec/html/secnetlpMSDN.asp
There is also an ASP.NET forum devoted specifically to security:

Microsoft .NET Framework Evaluation Guide xl

http://www.asp.net/Forums/ShowForum.aspx?
tabindex=1&ForumID=25

Mobile Web Device Support

ASP.NET mobile controls—previously known as the Microsoft
Mobile Internet Toolkit (MMIT)—let you easily target mobile phones,
PDAs, and other devices (over 200 mobile Web devices in total)
using ASP.NET. You write your application just once, and the
mobile controls automatically generate WAP/WML, XHTML, HTML,
or cHTML as required by the requesting device. The ASP.NET
mobile controls also feature an extensible model for devices
support. As new devices become available, Microsoft provides
"device updates" to add support for new devices to existing
applications (no modifications to the applications are required).

Over the past few years, the world has seen an explosion of new
wireless devices such as mobile phones, pagers, and personal
digital assistants (PDAs), which enable users to browse Web sites at
any time from any location. Developing applications for these
devices is challenging:

 Different markup languages are necessary for different

clients, including HTML for PDAs, wireless markup
language (WML) for wireless application protocol (WAP)
phones, compact HTML (cHTML) for Japanese i-mode
phones, and so on.

 Devices have different form factors. For example, devices

have varying numbers of display lines, horizontal or vertical
screen orientation, and color or black and white displays.

 Devices have different network connectivity, ranging from

9.6 KB cellular connections to 11 MB Wireless LANs.

 Devices have different capabilities. Some devices can

display images, some can make phone calls, and some can
receive notification messages.

The ASP.NET mobile controls address these challenges by isolating

them from the details of wireless development. Thus, developers
can quickly and easily build a single, mobile Web application that
delivers appropriate markup for a wide variety of mobile devices.

The ASP.NET mobile controls are server-side controls that provide

user interface elements such as list, command, call, and calendar,
to cite just a few examples. At execution time, the mobile controls
generate the correct markup for the device that makes the request.
As a result, you can write a mobile application once and access it
from multiple devices.

Because these mobile controls are based on the ASP.NET controls,

Microsoft .NET Framework Evaluation Guide xli

 you can leverage your current Web development skill set when
creating mobile applications. You can also reuse the same business
logic and data access code that you use in your PC browser Web
application. Mobile and PC browser Web applications can reside in
the same Visual Studio .NET project. This makes an application
faster to develop and lowers your maintenance cost.

The following example provides just a taste of programming with

mobile controls. In this example, the Hello World program creates an
ASP.NET mobile controls page with a single form on it. That form
contains a Label control with the string: "Hello, Mobile World." All of
this code was generated automatically simply by dragging a Label
onto a Form and setting a single property using the Visual Studio
.NET forms designer.
<%@ Page language="c#"
Inherits="System.Web.UI.MobileControls.MobilePag
e" %>
<%@ Register TagPrefix="Mobile"
Namespace="System.Web.UI.MobileControls"
Mobile phone with a WAP Assembly="System.Web.Mobile" %>
browser
<mobile:Form id=Form1 runat="server">
<mobile:Label id=Test Runat="Server">Hello,
Mobile World</mobile:Label>
</mobile:Form>

In the figures to the left, you can see how a more sophisticated
application renders on different devices. The first device is a mobile
phone running a WAP browser that supports WML. The second
device is Pocket PC running an HTML browser.

The ASP.NET mobile controls also enable you to customize the

markup that is generated by mobile controls for a specific device,
should you choose to do so. You can designate templates and
styles for a specific device within the mobile page.

XML Web Services

Pocket PC with browser
XML Web services are at the core of solving the challenges of
application integration and delivering software as a service. As
mentioned above, XML Web services are components which
facilitate integration by sharing data and functionality over the
network through standard, platform-independent protocols such as
XML, SOAP, and HTTP. XML Web services provide a simple,
flexible, standards-based model for binding applications together
over existing Internet infrastructure. Web applications can be easily
assembled from new or existing XML Web services, irrespective of
the platform, development language, or object model used to
implement any of the constituent services or applications.

Microsoft .NET Framework Evaluation Guide xlii

 Core XML Web Services Technologies
The key to making XML Web services work across the Web and its
heterogeneous infrastructure is to have applications agree on simple
data description formats, based on XML. These data formats, along
with what they do, include the following:

Extensible Markup Language (XML)

XML provides a uniform method for describing and exchanging

structured data that is independent of applications or vendors. As
the major building block for XML Web services, XML's largest
strength is its flexibility to carry any type of data in a platform-
independent way. Sample XML being returned from an XML Web
service can be seen at left.

Simple Object Access Protocol (SOAP)

At the lowest level, systems need to speak the same language. In

Example of XML being returned from an particular, communicating applications need to have a set of rules
for how they are going to represent different data types (such as
XML Web service
integers and arrays) and how they are going to represent commands
(for example, what should be done with the data). Real-world
applications also need a way to extend these basic definitions if they
have to. SOAP, an XML grammar, represents one common set of
rules for representing and extending data and commands. SOAP
has been accepted as a standard by the World Wide Web
Consortium (W3C).

Web Services Description Language (WSDL)

Once applications have general rules for how they will represent
data types and commands, they need a way to describe the specific
data and commands they accept. It is not enough for an application
to say that it accepts integers; somehow, there must be a way to say
deterministically that, if you give it two integers, it will multiply them.
The Web Services Description Language (WSDL) enables
developers and development tools to describe and learn about the
capabilities of an XML Web service.

SOAP Discovery (Disco)

Beyond WSDL, you need a set of rules for locating an XML Web
service's description—where does a tool look to discover an XML
Web service's capabilities? The SOAP Discovery specification
provides a set of rules for automatically discovering the WSDL
description files on a particular Web site.

Microsoft .NET Framework Evaluation Guide xliii

 Universal Description, Discovery, and Integration
(UDDI)

The Universal Description, Discovery, and Integration (UDDI)

specification defines a SOAP-based XML Web service for locating
XML Web services and programmable resources on a network.
UDDI provides a foundation for developers and administrators to
readily share information about internal services across the
enterprise and public services on the Internet.

In te rn e t
Windows Server 2003 includes UDDI Services, enabling companies
to run their own private UDDI service for intranet or extranet use.
UDDI Services helps companies organize and catalog programmatic
resources. As a core piece of XML Web services infrastructure in
Windows Server 2003, UDDI Services makes it easy to discover,
SOAP

W e b S it e share, and re-use XML Web services and other programmable

D is c o v e r y resources. With UDDI Services, companies can build and deploy
O rd e r S e r v ic e D e s c r ip tio n
smarter, more reliable applications. For more about UDDI Services
Q ty S e rv ic e D e s c r ip tio n in Windows Server 2003, see:
P r ic e S e r v ic e D e s c r ip tio n http://www.microsoft.com/windows.netserver/evaluation/overview/do
C a ta lo g S e r v ic e D e s c r ip tio n tnet/uddi.mspx.

View of accessing an XML Web service Microsoft also hosts a node of the UDDI Business Registry (UBR).
Offered at no cost, this instance of UDDI is a public directory where
one can publish and inquire about XML Web services available on
the Internet. The Microsoft UBR node replicates with other UBR
operator nodes. For more information, see http://uddi.microsoft.com.

The .NET Framework implements all of these XML Web services

standards.

For more information on XML and SOAP standards, visit the

official W3C site at http://www.w3.org/XML/Activity.html.

Create XML Web Services Easily

As outlined in the ASP.NET section above, Microsoft is making
Web-based development easier and more reliable than ever before.
With the .NET Framework, developers can make all objects Internet-
accessible as XML Web services simply by marking them with the
WebMethod attribute—without developers having to learn XML at
all.

The following Visual Basic code shows how to create an XML Web
service that exposes a function to Web requests. As we mentioned
previously, this functionality can be found in the
System.Web.Services namespace, which we first import into our
project. This then allows us to specify both the WebService attribute
on the class (which is inherited from
System.Web.Services.WebService) as well as the WebMethod

Microsoft .NET Framework Evaluation Guide xliv

attribute on the appropriate function (in this example CalcTemp, for
converting degrees Fahrenheit into Celsius):
Imports System.Web.Services

<WebService(Namespace := "http://tempuri.org/")>
_
Public Class Service1
Inherits System.Web.Services.WebService
...
<WebMethod(Description:="Converts F to C")> _
Public Function CalcTemp(ByVal dF As Double)
_
As Double
CalcTemp = ((dF - 32) * 5) / 9
End Function
End Class

Testing an XML Web Service

But this is only half the solution; the WebMethod keyword gives
programmers the capability to expose functionality to the Internet,
but how does a developer figure out how to use these functions?
The .NET Framework supplies the utility WebServiceUtil.exe, which
takes the path to a WSDL file and a language (C#, Visual Basic
.NET, or JScript) as input arguments. The utility then generates a
single source file as output. This file contains a proxy class, defined
using the language specified, that exposes methods (both
synchronous and asynchronous) for each of the methods exposed
by the XML Web service. Each proxy method contains the
appropriate network invocation and marshaling code necessary to
invoke and receive a response from the remote service. Visual
Studio .NET makes this even easier by providing an explorer
interface to XML Web services and automating the bulk of this work.
Running this utility against our simple XML Web service creates a
test page for developers to use to ensure the code works as desired:

Microsoft .NET Framework Evaluation Guide xlv

This test page contains test entry points for all of the service's
members given the WebMethod attribute, as well as additional
documentation about working with XML Web services including
pointers to online reference material.

Selecting an individual WebMethod—CalcTemp in our example—

then creates a page to test that specific method, including input
boxes for each of the parameters which can be filled with test data
by the developer as well as sample data for SOAP, HTTP GET, and
HTTP POST requests and responses:

Microsoft .NET Framework Evaluation Guide xlvi

Entering a value of 65 for the temperature in degrees Fahrenheit
and invoking the function generates an XML response, which in the
test case, is displayed within a browser window:

To make your XML Web service available to others, you must

deploy it to a Web server that is accessible to the clients you wish to
support. To deploy the XML Web service to a server other than the
development server, you can simply XCOPY the required files to the
destination server.

Microsoft .NET Framework Evaluation Guide xlvii

Access an XML Web Service
Accessing an XML Web service from managed code is also a
straightforward process. First, if you are using Visual Studio .NET
you add a Web reference to your project for the XML Web service
you wish to access. The Web reference automatically creates a
class with methods that serve as proxies for each exposed method
of the XML Web service. This can also be done using the
WebServiceUtil.exe utility from the command line. Next, use the
proxy class in your code and you're free to access the methods of
that class as you would the methods of any other class. By default,
adding a Web reference also adds methods to the proxy class for
accessing the XML Web service asynchronously, which will be
essential for certain architectures.

In the example Visual Basic .NET code below, the client application
is accessing the XML Web service described above, named
Converter—for which it has a Web reference. It is accessing this
XML Web service through a proxy class Service1, which has
exposes the XML Web service's CalcTemp method. The two lines
of code that are underlined are the only code that is necessary to
instantiate and call the XML Web service. The .NET Framework
handles all the complexities of generating and parsing XML, HTTP
requests, etc. for the developer transparently.
Imports System
Module Module1
Sub Main()
Dim cService As New Converter.Service1()
Dim dFahrenheit As Double
Dim dCelsius As Double
Console.Write("Temp in degrees Fahrenheit:
")
dFahrenheit =
Convert.ToDouble(Console.ReadLine())
dCelsius = cService.CalcTemp(dFahrenheit)
Console.Write("Temp in degrees Celsius: ")
Console.WriteLine(dCelsius.ToString())
End Sub
End Module

Windows Server 2003

The Windows Server 2003 operating system family features
significant advancements in security, reliability, availability, and
scalability. In addition, Microsoft has improved and extended the

Microsoft .NET Framework Evaluation Guide xlviii

Windows server operating system to enable organizations to more
directly experience the benefits of Microsoft .NET for connecting
information, people, systems, and devices. The .NET Framework
and UDDI ship natively with the operating system. COM+
applications can be exposed as XML Web services with a single
click of the mouse. MSMQ 3.0 introduces support for sending
messages over the Internet, including URL-based queue
referencing, transmission of SOAP formatted messages, and HTTP-
based secure messaging. Improved symmetric multi-processor
support enables application developers to take advantage of highly
scalable hardware platforms.

Perhaps the single greatest area of interest to developers is Internet

Information Services (IIS) 6.0, the new version of the Windows Web
server.

What's New in IIS 6.0

With IIS 6.0, Microsoft has completely revised the IIS architecture to
address the demanding performance and reliability needs of
enterprise customers, Internet service providers (ISPs), and
independent software vendors (ISVs).

Its features and improvements can be categorized in two main

areas:

 Reliability and Scalability

 Security and Manageability

Reliability and Scalability

To enhance reliability, a new request-processing architecture
automatically detects memory leaks, access violations, and other
errors. When these conditions occur, the underlying architecture
provides fault tolerance and the ability to automatically restart
processes as necessary. In the event of a process restart, IIS 6.0
will continue to queue requests without interrupting the user
experience. IIS 6.0 is also capable of monitoring the health of
worker processes, applications, and Web sites based on various
factors including uptime, a designated schedule, number of
requests, and memory consumption.

IIS 6.0 has improved the way the operating system uses internal
resources. For example, IIS 6.0 does not pre-allocate resources at
initialization time, so starting up and shutting down a server is faster.
And a new kernel mode driver for HTTP parsing and caching
provides increased scalability and performance.

Security and Manageability

IIS 6.0 provides significantly improved security. IIS 6.0 is no longer

Microsoft .NET Framework Evaluation Guide xlix

 BUILDING
SMART CLIENT
APPLICATIONS
enabled by default; rather, it ships in a locked-down state, serving
only static content when it is first turned on. Web site administrators
can enable or disable IIS functionality based on the individual needs
of the organization. Another new feature—constrained delegation—
now provides domain administrators with control to delegate
impersonation only to particular computers and services.

With the new IIS process model, for the first time, each ASP.NET
application can now run in its own process. This enables
administrators to isolate applications from one another, granting
each different access privileges to available resources. (Note:
Version 1.1 of the .NET Framework enables administrators to
emulate this feature on IIS 5.0 by setting up code access security
policies for each of the different ASP.NET applications running in the
ASPNET process.)

The XML-formatted, plain-text metabase in IIS 6.0 provides

improved backup and restore capabilities for servers that experience
critical failures. It also provides for improved troubleshooting and
metabase corruption recovery. Direct editing, using common text
editing tools, provides greater manageability. A Windows
Management Instrumentation (WMI) interface provides a consistent
enterprise interface for monitoring and managing IIS configurations.

Advantages of Smart Client Applications

Software developers targeting the corporate environment have
faced a difficult tradeoff when deciding between the browser-based,
thin client application model and its rich client counterpart.

The browser-based application is easy to install and maintain, can

target many desktops, and has no impact on the state of the client
computer. Yet in spite of these advantages, the browser-based
model is far from perfect. Rich client applications provide a richer
user interface (UI) along with access to the local disk and local APIs,
further empowering the developer and resulting in a more productive
user experience. Because they run locally on the client computer,
rich client applications also make for more efficient use of available
resources, eliminate the issue of network latency, and enable the
user to work offline.

Overall, relative to the smart client, the browser-based model is

wonderful for information technology (IT) administrators, but leaves
much to be desired for both developers and end users. The
Microsoft .NET Framework programming model serves the interests
of all three parties. Its smart client application model combines all

Microsoft .NET Framework Evaluation Guide l

the power and flexibility of the rich client model with the ease of
deployment and stability of the browser-based model.

Deploying Smart Clients from a Web Server

As mentioned previously, components built using the .NET
Framework are not subject to versioning conflicts. “DLL hell,” which
had previously been a major obstacle to delivering rich client
applications is all but eliminated.

This addresses application stability, predictability, and ease of

installation—essentially what happens when the application arrives
at the client computer. But how do you get the application to the
client computer in the first place?

As in the past, smart client applications can be delivered by CD,

DVD, floppy disk, or through application deployment infrastructure
such as Microsoft Systems Management Server. The .NET
Framework introduces yet another option: No-Touch Deployment,
deploying the application from a remote Web server using HTTP.

As explained early in this paper, No-Touch Deployment enables

administrators to deploy smart client applications to the target client
machines from remote Web servers.

Essentially, this process mirrors the browser-based application

deployment approach. Using methods provided in the .NET
Framework class libraries, an application can be written to download
the assemblies it needs dynamically from a remote Web server. The
first time a particular assembly is referenced, it is downloaded to the
assembly download cache on the client computer and loaded for
use. Going forward, if the assembly required is already on the client
computer and the version on the Web server has not changed, the
local copy will be loaded. If the version on the Web server has been
updated, that new version will be downloaded and executed. Thus,
updates are automatically propagated to the client, but the network
is not flooded with redundant downloads.

Note that assemblies are downloaded dynamically, only as they are

referenced. This allows applications to load quickly—no 50-MB, half-
hour installation process just to get started.
For more detail and sample code on how to do this, see
http://msdn.microsoft.com/netframework/techinfo/articles/smartclient
/default.asp#deploying.

Code Access Security: Making No-Touch

Deployment Safe
For system administrators and users to feel safe about downloading
and running applications from a remote Web server, there must be a
security system in place that protects client computers from

Microsoft .NET Framework Evaluation Guide li

activating a virus or other harmful code. To prevent security
breaches from happening, the .NET Framework supports a
powerful, fine-grained, evidence-based security system, enabling
code to be trusted to varying degrees, depending upon its origin and
other characteristics such as its digital signature or the identity of the
author. For example, code loaded from an intranet Web server will
not be allowed to access the client computer's Registry or file
system or gain network access to any other server on the network
besides the one from which it originated. Meanwhile, code bearing a
particular digital signature or Authenticode signature might be
granted significantly more permissions, such as the ability to read
from, but not write to the local disk, the ability to revise some
environment variables, the ability to interact with three of the seven
available databases on the network, and so on. The .NET
Framework ships with default security settings that are safe and
appropriate for most situations. Systems administrators can use
the .NET Framework Configuration Tool or a scriptable command
line tool (caspol.exe) to modify these settings as desired.

At run time, the CLR performs low-level security checks with a

technology known as code access security. This technology ensures
that code executes only those operations allowed by the security
policies it has been assigned. In doing so, the CLR checks not only
the permissions allotted to the assembly attempting a particular
operation, but also those of all the other assemblies in the stack that
might be calling the active assembly to act on their behalf. Only
operations approved in this comprehensive stack walk will be
performed.

If software developers are concerned that their applications will not

run properly without a certain minimum set of security permissions,
they can specify their requirements in advance with attributes
included in the assembly's metadata. If these permissions are not
granted, the assembly will not be loaded.

This security architecture ensures that unauthorized code cannot

access or otherwise abuse the local system in any way, and gives IT
administrators more granular control over the applications running
on their systems.

Smart Client Versus Browser-Based

With these smart client technologies, it's easy to see how the
platform-specific application model reflects a practical approach to
software development. But how does it compare with the browser-
based model? Consider the following.

Microsoft .NET Framework Evaluation Guide lii

Work Offline
One obvious but critical advantage that smart client applications
have over browser-based applications is the capability to work
offline. Practical Internet access is anything but ubiquitous.
According to IDC, at the end of 2002, approximately 38.9 percent of
U.S. households were expected to engage in some form of home-
office activity.¹ At that time, according to The Yankee Group, only 16
percent of those households were expected to have any form of
high-speed connectivity to the Internet.² This means that, assuming
a remote worker has access to the Internet (not a given for those
traveling and seeking to work from hotels, airports, or airplanes),
chances are he or she will be forced to endure an irritatingly slow
dial-up connection every time an attempt is made to access or
manipulate data using a browser-based application. Even if high-
speed access is available, what happens when the server goes
down? With smart client applications, these problems can be
avoided. Once the necessary assemblies are downloaded to the
local disk or otherwise installed off of a CD, the user can work
productively offline.

Use Resources Efficiently and Safely

Web-based applications are often designed so that all processing is
handled by the servers. The advantage of placing the entire burden
on the server is that it makes it easier to push an application to
multiple different types of clients. The disadvantage is that, for even
the simplest request, the client-side user must endure both network
latency and the amount of time it takes the server to queue up the
given request and process it.

Performing some or all of the work locally with smart client

applications means quicker response time and reduced network and
server workload, making for more scalable infrastructure. A smart
client application can run without any interaction with the network
and the server, completely freeing up that infrastructure, or it can go
to the server as needed to dynamically download an assembly or to
invoke an XML Web service. With XML Web services and remoting,
smart client applications are free to leverage the benefits of the
application platform, as needed. The fact that even some of the
work will be done locally—loading and implementing the UI controls,
for example—results in a more dynamic user experience and much
more efficient use of the infrastructure available, both client and
networked.

Web-based applications can be designed to offload some of the

processing to the client using scripting or ActiveX controls, but both
have limitations when compared with the smart client application
model. By default, Web-based script essentially runs in a "sandbox"

Microsoft .NET Framework Evaluation Guide liii

and is prevented from accessing local resources. Scripted
applications cannot read from or write to a client user's local disks,
so all data must be stored on a remote server. Again, this causes
problems when the user is faced with a slow Internet connection or
wishes to work offline. Scripted applications are also unable interact
with applications housed on the client computer, such as a Microsoft
Excel or the Microsoft Outlook® messaging and collaboration client
(as explained in the next section). They can certainly offload some
of the work from the server, but they do not have the crucial
flexibility of smart client applications when it comes to interacting
with the local computer. While ActiveX controls can overcome many
of these obstacles, their security architecture is not up to par with
that of smart client applications. Users must decide whether or not to
run the control. Once the control is activated, there is no way to limit
the access it has to the local computer.

Smart client applications built on the .NET Framework have the best
of all possible worlds. The Windows Forms libraries enable quick
and easy Windows-style UI development that can be implemented
either by hand-coding or by dragging and dropping controls onto a
form in Visual Studio .NET. Smart client applications can access the
local system but only in so much as they are allowed by .NET
Framework code access security policies, as described above.

Again, it is no longer an all-or-nothing security decision but a fine-

grained determination that can permit some operations but forbid
others. Finally, the burden of this decision is taken off the user and
handled transparently by the CLR, using either the default security
settings or those configured by the system administrator.

Access Local APIs

Smart client applications can leverage powerful Windows-based
APIs that are unavailable to non-ActiveX browser-based
applications. For example, smart client applications can utilize the
graphical power of the GDI+ libraries. Smart client applications can
tie into the Microsoft Office APIs, enabling developers to manipulate
Microsoft Word, Microsoft Access, Excel, Outlook, and Microsoft
PowerPoint® through their own applications. Smart client
applications also have the ability to listen for incoming network
requests, thus enabling peer-to-peer connectivity. This example, in
particular, deserves a section all its own.

Use Peer-to-Peer Technology

In a peer-to-peer scenario, a computer can act as both client and
server, making requests of other peer computers and responding to
requests placed on it by these peers. One example of this is a file-
sharing system, in which an application running on one computer

Microsoft .NET Framework Evaluation Guide liv

 can search for and retrieve a desired file from a peer computer while
making its own files available in reciprocation. Another example is
an application running on one computer that can seek out those
computers on the network with spare processor power and disk
space and harness these unused resources for its own use,
enabling a corporation to more fully leverage the infrastructure
available to it.

Peer-to-peer technology represents a powerful paradigm with

tremendous promise, but it can only be implemented using smart
client applications. Web browsers, being user-driven by design, do
not have the necessary capacity to listen for and respond to
spontaneous requests made by other clients on the network.

Consume XML Web Services

Like ASP.NET applications, smart client applications can consume
functionality provided by XML Web services, enabling them to
integrate with remote functionality, potentially running on another
platform.

A Minimal Windows Form

So, what is involved in creating a Windows Forms application? Let's
first take a look at a minimal Windows Form, the prototypical “Hello
World” application. Here is one way to write this application using
Visual Basic .NET:
Imports System
Imports System.Windows.Forms

Public Class Form1

Inherits System.Windows.Forms.Form

Public Sub New()

MyBase.New()
Me.Text = "Hello World"
End Sub
End Class

Minimal Windows Form As you can see, the code for this application is quite small. Most of
the functionality comes automatically by inheriting from the Form
class in the System.Windows.Forms class library.

Programming with Windows Forms

The application programming model for Windows Forms is primarily
comprised of forms, controls, and their events.

Microsoft .NET Framework Evaluation Guide lv

 Forms
In Windows Forms, the Form class is a representation of any
window displayed in your application. You can use the BorderStyle
property of the Form class to create standard, tool, borderless, and
floating windows. You can also use the Form class to create modal
windows, such as dialog boxes. A special kind of form, the MDI
form, can be created by setting the MDIContainer property of the
Form class. An MDI form can contain other forms, called MDI child
forms, within its client area. The Form class provides built in support
for keyboard handling (tab order) and scrolling of the contents of the
form.

When designing the user interface for your application, you typically
Data entry grid showing an error create a class that derives from Form. You can then add controls,
set properties, create event handlers, and add programming logic to
your form.

In addition, you can inherit from your own defined forms: this so-
called “visual forms inheritance” gives you both the appearance of
the form as well as the functionality built into your defined form,
which you can extend, as needed.

Controls
Each component that is added to a form, such as a Button, a
TextBox, or a RadioButton, is called a control. Windows Forms
includes all of the controls commonly associated with Windows
client applications.

You typically interact with controls by setting properties to alter their

appearance and behavior. For example, the following derived class
of Form adds a Button control to the form and sets its Size and
Location properties.

Many controls are provided with the .NET Framework, including

such advanced controls as a tray notification icon, a sophisticated
grid, and even a control to indicate data entry errors.

Events
The Windows Forms programming model is event-based. When a
control changes state, such as when the user clicks a button, it
raises an event. In order to handle an event, your application
registers an event-handling method for that event. This code in this
method will be called and run whenever that particular event
transpires. The Windows Forms controls support most of the events
you will be interested in following and responding to in your
applications. You can easily create and handle custom events—
either triggered by controls or by other actions in the flow of your
application logic.

Microsoft .NET Framework Evaluation Guide lvi

 Extending Forms
In addition to the “visual forms inheritance” mentioned above,
Windows Forms provides substantial support for advanced graphics
operations using the GDI+ graphics library. Forms can also easily be
associated with visual and text-based resources from multiple
languages and cultures for creating localized applications. Windows
Forms provides built-in support for creating applications that are
accessible to people with visual disabilities, who access UI through
a tool such as Microsoft Narrator.

Creating Controls
There are many sources for controls that can be used in your smart
client applications. Many controls are already included with the
.NET Framework (these are often referred to as “built-in” controls) in
the Windows Forms class library, as discussed above. You can also
reuse virtually any existing ActiveX controls. In addition, you can
use third-party .NET Framework-based or ActiveX controls from a
software vendor or any custom controls that you develop to perform
specific tasks. Of course, using the .NET Framework you can author
A composite control controls in any of the programming languages supported by the
.NET Framework.
There are three basic techniques for creating controls:

 Inherit from another control. Because the .NET

Framework provides an object-oriented programming
environment, you can inherit all of the controls in the
Windows Forms library or any custom controls that do not
explicitly disallow inheritance. Effectively, with a single line
of code, this enables you to import all of the functionality of
the control from which you are inheriting. You can use this
functionality as is, replace it, or add new functionality
alongside it, as desired. This is useful when another control
is very close to what you want and you merely want to add
some additional behavior. For instance, you may want to
create a version of a TextBox that only accepts numeric
keyboard input.

 Build a composite control. A composite control combines

existing controls and exposes a single interface for the
aggregated functionality. A popular composite control is
used for building a list of options from a pre-populated list of
available choices.

 Develop from scratch. A developer can create a control

directly by inheriting from the
System.Windows.Forms.Control class. The developer must

Microsoft .NET Framework Evaluation Guide lvii

 SUMMARY
write all of the code pertaining to the appearance and
behavior of this control. This gives the developer maximum
control but also requires the most work of the three options.

Since all controls ultimately inherit from the

System.Windows.Forms.Control class, they all gain the functionality
of that class including its properties (such as Anchor, BackColor,
ForeColor, Dock, and Visible) and methods (such as BringToFront,
Hide, Refresh, Show, and Update).

Mobile Device Development

As mentioned above, the .NET Compact Framework provides a
subset of the .NET Framework functionality for developing smart
client applications for the Pocket PC and other Windows CE-based
systems. The .NET Compact Framework includes the Windows
Forms classes, so developers already familiar with developing smart
client applications for the PC can seamlessly transfer their skills to
building applications for the device, and vice versa.

When to Implement Smart Clients

The smart client architecture is not ideal for every scenario. In
situations such as e-commerce, where user platforms are unknown
or diverse, the browser-based model, implemented using the
ASP.NET classes with the full support of the application platform,
continues to represent the most practical approach. However, in the
context of a corporate computing environment, where clients are
known to be running the Windows operating system, the smart client
model is the architecture of choice, combining the power and
flexibility of rich client applications with the stability and ease of
deployment associated with browser-based applications.

The .NET Framework is an integral Windows component that

supports building and running the next generation of software
applications and XML Web services. The .NET Framework
enables developers to rapidly create XML Web services, Web
applications, smart client applications, and other types of
applications through the use of developer productivity features, such
as multi-language support, adherence to public Internet standards,
and the use of a loosely coupled, scalable architecture. While many
vendors sell application servers separately, Microsoft delivers a
comprehensive set of Web application services fully integrated into
the Windows operating systems and available through the .NET
Framework.

Loosely Coupled Designs Enable Scalability

Microsoft .NET Framework Evaluation Guide lviii

The core XML Web services technologies on which the .NET
Framework is built are loosely coupled, which means you can
change the implementation at either end of a connection and the
application will continue to work. Technically, this translates to using
message-based, asynchronous technology to achieve scalability
and reliability, and using Web protocols such as HTTP, SMTP, and
most importantly, XML to achieve universal reach.

Leverage Operating System Services

Because other solutions try to provide identical functionality across
many different platforms, these solutions are limited to a least-
common denominator approach, which means that services
provided by the operating system are abandoned and recreated
from scratch. In contrast, the .NET Framework design pattern is
engineered to exploit the power and flexibility of the Windows
operating system.

Multilanguage Support
With the .NET Framework, developers can take advantage of the
programming language they are most comfortable with or use the
language that is best suited to the job at hand. Having objects of one
language call into objects of another may not be new, but the .NET
Framework takes this a step further by enabling developers to use
cross-language implementation inheritance and cross-language
debugging—all of this with a single, easy-to-use, unified class
library.

Operational Excellence
With XCOPY and No-Touch Deployment, the .NET Framework
makes it easy for administrators to efficiently roll out new
applications or updates to existing ones. With code access security,
the .NET Framework puts administrators firmly in control of the
security permissions granted to managed code running within their
domain. With its automatic restart capabilities, its support for
compilation, and improvements in caching, the ASP.NET libraries
make Web-enabled applications more reliable with better
performance than ever before.

Developer Productivity
By providing one unified programming model with a unified set of
class libraries for building all types of applications, developers skilled
in building ASP.NET Web applications can quickly translate their
skills over into building smart client applications, Windows Services,
or console applications, and vice versa. With the ASP.NET mobile

Microsoft .NET Framework Evaluation Guide lix

 APPENDIX A:
CHANGES
FROM .NET
FRAMEWORK 1.0
controls and the .NET Compact Framework developers targeting PC
clients with Web and smart client applications can now leverage
their existing skills in building device applications. These
opportunities combined with the extensive amount of pre-packaged
functionality made available in the .NET Framework class libraries
and the amount of work done for developers behind the scenes by
the .NET Framework—for example, memory management,
seamlessly integrating components written in different programming
languages, generating the XML and SOAP automatically for building
and consuming XML Web services etc.—enable developers to be
more productive than ever before.

Standards-Based
The .NET Framework is based on Extensible Markup Language
(XML) and SOAP, which are standards overseen by the World Wide
Web Consortium standards body. In addition, key parts of the .NET
Framework, referred to collectively as the common language
infrastructure, have been ratified as a standard by the European
Computer Manufacturers Association (ECMA). For more
information, see Appendix C.

The Microsoft® .NET Framework version 1.1 extends the .NET

Framework version 1.0 with new features, improvements to existing
features, and enhancements to the documentation. The major
feature areas of this new release are outlined below.

Native Support for Developing Mobile Web

Applications
The .NET Framework 1.1 features native support for developing
mobile Web applications. ASP.NET mobile controls (formerly the
Microsoft Mobile Internet Toolkit) extend ASP.NET server controls
such that they adapt to the mobile device on which the Web
application is rendering. Through browser detection, the mobile
controls conform to the capabilities of individual devices ranging
from full-featured personal digital assistant (PDA) browsers to small,
5-line × 20-character mobile phone displays. This adaptive rendering
feature handles many of the tedious, device-specific rendering
decisions and frees you to focus on your Web application logic.
The .NET Framework 1.1 incorporates the mobile controls into
the .NET Framework and Microsoft Visual Studio® .NET

Microsoft .NET Framework Evaluation Guide lx

distributions.

Granular Version Control: Side-by-Side

Execution
Support for side-by-side execution in the .NET Framework 1.1
enables system administrators to store and execute multiple
versions of an application or component on the same computer. This
means that you can have multiple versions of the .NET Framework
Redistributable, as well as multiple versions of applications and
components that use a version of the Redistributable, on the same
computer at the same time.

Side-by-side execution does not imply that a managed application is

compatible with other versions of the Redistributable or of a
component. Rather, it means that a managed application can
choose the Redistributable and the components it executes with,
and that multiple versions of the Redistributable, applications, and
components can coexist on the same computer. Systems
administrators control this through the application's configuration file.

By default, in the absence of configuration file instructions:

 If an application written with the .NET Framework 1.0 is

installed on a system with only the .NET Framework 1.1
Redistributable present, the application will try to run
against version 1.1.

 If an application written with the .NET Framework 1.0 is

installed on a system with both versions 1.1 and 1.0 of the
Redistributable present, the application will run against
version 1.0 unless an administrator changes the behavior.

 If an application written with the .NET Framework 1.1 is

installed on a system with only the .NET Framework 1.0
Redistributable, it will not run (unless configured to do so).

ASP.NET applications represent an exception to this behavior.

When the .NET Framework 1.1 Redistributable is installed on a
server, ASP.NET Web applications and XML Web services are, by
default, automatically configured to run with it. Again, systems
administrators have the ability to override this default behavior and
configure some or all of these applications to run with the .NET
Framework 1.0 Redistributable.

Enable Execution of Windows Forms

Assemblies Originating from the Internet
Assemblies originating from the Internet zone—for example,
Microsoft Windows® Forms controls embedded in an Internet-based

Microsoft .NET Framework Evaluation Guide lxi

Web page or Windows Forms assemblies hosted on an Internet
Web server and loaded either through the Web browser or
programmatically using the
System.Reflection.Assembly.LoadFrom() method—now receive
sufficient permission to execute in a semi-trusted manner. Default
security policy has been changed so that assemblies assigned by
the common language runtime (CLR) to the Internet zone code
group now receive the constrained permissions associated with the
Internet permission set. In the .NET Framework 1.0 Service Pack 1
and Service Pack 2, such applications received the permissions
associated with the Nothing permission set and could not execute.

Note: While we are re-enabling code from the Internet zone, the
defaults do not give this code full access to the user's machine.
Thanks to code access security, this code runs in a restricted
manner by default, and is allowed access only to a limited set of
resources that are safe to use. This code cannot damage your data
or system, nor can it steal private information that you do not
explicitly give it.

Enable Code Access Security for ASP.NET

Applications
Systems administrators can now use code access security to further
lock down the permissions granted to ASP.NET Web applications
and XML Web services. Although the operating system account
under which an application runs imposes security restrictions on the
application, the code access security system of the CLR can enforce
additional restrictions on selected application resources based on
policies specified by systems administrators. You can use this
feature in a shared server environment (such as an Internet service
provider hosting multiple Web applications on one server) to isolate
separate applications from one another, as well as with stand-alone
servers where you want applications to run with the minimum
necessary privileges.

Native Support for Communicating with

ODBC and Oracle Databases
With the .NET Framework 1.1, developers can now enjoy native
support for communication with ODBC and Oracle databases.
The .NET Framework Data Provider for ODBC, which previously
was available only as a Web download, now ships with the .NET
Framework under the namespace System.Data.Odbc. It provides
access to native ODBC drivers the same way the OLE DB .NET
Data Provider provides access to native OLE DB providers.

The .NET Framework Data Provider for Oracle, which also

Microsoft .NET Framework Evaluation Guide lxii

previously was available only as a Web download, now ships with
the .NET Framework under the namespace
System.Data.OracleClient. It provides access to Oracle databases
using the Oracle Call Interface (OCI) as provided by Oracle Client
software.

Note:  Developers using the .NET Framework version 1.0 may

download the .NET Framework Data Provider for ODBC and the
.NET Framework Data Provider for Oracle from
http://msdn.microsoft.com/downloads.

Unified Programming Model for Smart

Client Application Development
The Microsoft .NET Compact Framework brings the CLR, Windows
Forms controls, and other .NET Framework features to small
devices. The .NET Compact Framework supports a large subset of
the .NET Framework class library optimized for small devices.

Supported devices include the Pocket PC 2000, Pocket PC 2002,

Pocket PC 2002 Phone Edition, and custom-designed embedded
devices built with the Windows CE .NET 4.1 operating system.
Earlier versions of Windows CE .NET are not supported.

The .NET Compact Framework provides the following key features:

 A compact CLR that brings the benefits of managed code

(such as memory management, code reliability, and
language neutrality) to devices.

 Consistency with desktop and server programming models.

 Seamless connection with XML Web services.

 Rich enterprise-class data access features with XML

classes and ADO.NET.

 Classes to program applications that access data using

Microsoft SQL Server™ 2000 Windows CE 2.0.

 Full access to native platform features through platform

invocation.

 Just-in-time (JIT) compilation for optimal performance.

Note: The .NET Compact Framework does not ship natively with the
.NET Framework. Developers may access the .NET Compact
Framework using Visual Studio .NET 2003.

Support for IPv6

The .NET Framework 1.1 supports the emerging update to the
Internet Protocol, commonly referred to as IP version 6, or simply

Microsoft .NET Framework Evaluation Guide lxiii

 APPENDIX B:
MINIMUM
CONFIGURATION
REQUIREMENTS
IPv6. This protocol is designed to significantly increase the address
space used to identify communication endpoints in the Internet to
accommodate its ongoing growth.

Scalability, Performance, Documentation

In addition to the areas discussed above, significant improvements
have been made to the .NET Framework in the areas of scalability
and performance. Enhancements have also been made to the
documentation, which now includes more code examples and
several new sections (including one entitled Secure Code
Guidelines).

ASP.NET Starter Kits

The ASP.NET Starter Kits demonstrate how to build a complete

application solution using the technologies offered in ASP.NET.
Each of the applications targets a handful of technologies in
The ASP.NET Starter Kits are available
ASP.NET and shows how to use them to build a practical, everyday
online at http://www.asp.net/starterkits/. solution. Each Starter Kit sample is complete and well-documented
for immediate reuse in ASP.NET development projects. A number
of Starter Kits are available:

 Community Starter Kit. A Web-based community site that

includes modules that may be customized for a portal-type
application.

 Time Tracker Starter Kit. A line-of-business ASP.NET

application to track time worked on projects.

 Reports Starter Kit. A simple data reporting solution for

displaying multiple views on data, creating charts, and
rendering any type of data in a Web application.

 Commerce Starter Kit. An e-commerce storefront

application complete with shopping cart, product catalog,
and an XML Web service to submit orders.

 Portal Starter Kit. Use ASP.NET and the .NET Framework

to build a dynamic portal application. The ASP.NET Portal
Starter Kit offers all the functionality of typical portal
applications.

This section describes the minimum configuration requirements for a

computer where the Microsoft® .NET Framework redistributable

Microsoft .NET Framework Evaluation Guide lxiv

package (Dotnetfx.exe) is to be installed. If the minimum
requirements are not met, the setup program will block the
installation of the redistributable package. Specifically, note that you
cannot install the .NET Framework redistributable package on a
computer running the Microsoft Windows® 95 operating system.

The .NET Framework redistributable package (Dotnetfx.exe) itself is

approximately 21 megabytes (MB) for version 1.0 of the .NET
Framework and 24 MB for version 1.1. The disk requirements for the
installation are approximately 145 MB free space required for the
installation process, and a final requirement of 111 MB.

Platform and Software Requirements

Minimum Requirements
To install the .NET Framework using the redistributable package,
you must have one of the following operating systems with Microsoft
Internet Explorer 5.01 or later installed on your computer:

 Windows 98

 Windows 98 Second Edition

 Windows Millennium Edition (Windows Me)

 Microsoft Windows NT® 4.0 (Workstation or Server) with

Service Pack 6a

 Windows 2000 (Professional, Server, or Advanced Server)

with the latest Windows service pack and critical updates
available from the Microsoft Security Web site

 Windows XP (Home or Professional)

 Windows Server 2003 family (Ships with the .NET

Framework already installed)

Recommended Software
Depending on your application requirements, you might also need to
install one or more of the following:

 Microsoft Data Access Components (MDAC) 2.6 or later for

data access, available from the Universal Data Access Web site.

 Windows Management Instrumentation (WMI) Core 1.5,

available from the MSDN Download Center.

Note: If the recommended software requirements are not met, setup

will not block installation or warn you of their absence.

Recommended Server Software

Depending on your application requirements, you might also need
the following server software:

Microsoft .NET Framework Evaluation Guide lxv

 APPENDIX C:
STANDARDS
AND THE .NET
FRAMEWORK
 MDAC 2.7 for data on the server, available at the Universal
Data Access Web site.

 Internet Information Services (IIS) on the server for

Windows 2000, Windows XP (Professional), and Windows
Server 2003. This is required for using ASP.NET
applications.

Hardware Requirements
Minimum Hardware Requirements
Scenario CPU Required RAM Required

Client Pentium 90 MHz* 32 MB**

Server Pentium 133 MHz* 128 MB**

* Or the minimum CPU required to run the operating system,

whichever is higher.

** Or the minimum RAM required to run the operating system,

whichever is higher.

Recommended hardware requirements

Scenario CPU Recommended RAM Recommended

Client Pentium 90 MHz or 96 MB or higher

faster

Server Pentium 133 MHz or 256 MB or higher

faster

ECMA C# and Common Language

Infrastructure Standards
The Common Language Infrastructure (CLI) is the European
Computer Manufacturers Association (ECMA) standard that
describes the core of the Microsoft® .NET Framework. On
December 13, 2001, the ECMA General Assembly ratified the C#
and CLI specifications into international standards. The ECMA
standards will be known as ECMA-334 (C#) and ECMA-335 (the
CLI). There is also a technical report on the CLI which will be known
as ECMA TR84. In addition, the ECMA approved the fast-track
motion of these specifications to the International Organization for

Microsoft .NET Framework Evaluation Guide lxvi

Standardization (ISO). This is a huge step toward the Microsoft
.NET Framework being widely accepted by the industry.

This standardization demonstrates strong support in the C# and CLI

technologies both from the ECMA and from the member companies
such as Hewlett-Packard and Intel, who helped develop the
standards. The approval of these standards is the culmination of
extensive technical work from Microsoft, the cosponsoring
companies Hewlett-Packard and Intel, and the many other ECMA
member companies that contributed to this work, including IBM,
Fujitsu, and Plum Hall.

The official submissions are available from the ECMA Web site at
http://www.ecma.ch.

Microsoft Shared Source CLI

Implementation "Rotor"
The Shared Source CLI is the source code to a working
implementation of the ECMA-335 (CLI) and the ECMA-334 (C#
language specification) standards. This implementation builds and
runs on Microsoft Windows® XP and the FreeBSD operating
system. It is released under a shared source initiative license and
the Shared Source CLI compressed archive is available for
download from the MSDN® Download Center.

XML Standards
The System.Xml namespace provides standards-based support for
processing Extensible Markup Language (XML). The supported
standards are:

 XML 1.0
http://www.w3.org/TR/1998/REC-xml-19980210 (including
DTD support)

 XML Namespaces
http://www.w3.org/TR/REC-xml-names/ (both stream level
and DOM)

 XSD Schemas
http://www.w3.org/2001/XMLSchema

 XPath expressions
http://www.w3.org/TR/xpath

 XSLT transformations
http://www.w3.org/TR/xslt

 DOM Level 1 Core

http://www.w3.org/TR/REC-DOM-Level-1/

Microsoft .NET Framework Evaluation Guide lxvii

  DOM Level 2 Core
http://www.w3.org/TR/DOM-Level-2/

Standards for XML Web Services

XML Web services are built on the World Wide Web Consortium's
XML, SOAP, Web Services Description Language (WSDL), and
Universal Description, Discovery, and Integration (UDDI)
specifications. These constitute a set of baseline specifications that
provide the foundation for application integration and aggregation.
From these baseline specifications, companies are building real
solutions and getting real value from them.

Global XML Web Services Architecture

(GXA)
As companies develop XML Web services, their solutions have
become more complex and their need for standards beyond the
baseline (XML, SOAP, WSDL, and UDDI) has become apparent.
The baseline specifications are a strong start for XML Web services,
but today developers are compelled to implement higher-level
functionality such as security, routing, reliable messaging, and
transactions in proprietary and often non-interoperable ways.

To address these requirements, Microsoft has proposed the Global

XML Web Services Architecture (GXA), which provides principles,
specifications, and guidelines for advancing the protocols of today's
XML Web services standards to address more complex and
sophisticated tasks in standard ways, allowing XML Web services to
continue to meet customer needs as the fabric of application
internetworking.

The GXA framework is based on four design tenets:

Modular. GXA uses the extensibility of the SOAP specification to

deliver a set of modules that can be combined as needed to deliver
end-to-end capabilities. As new capabilities are required, new
modular elements can be created.

General Purpose. GXA is designed for a wide range of XML Web

services scenarios, ranging from business-to-business (B2B) and
EAI solutions to peer-to-peer applications and business-to-consumer
(B2C) services.

Federated. GXA is fully distributed and designed to support XML

Web services that cross organizational and trust boundaries and
requires no centralized servers or administrative functions.

Standards-Based. As with previous XML Web services

specifications, GXA protocols will be submitted to appropriate

Microsoft .NET Framework Evaluation Guide lxviii

standards bodies and Microsoft will work with interested parties to
complete their standardization.

In addition to this underlying protocol framework, GXA defines a

family of pluggable infrastructure protocols that provide applications
with commonly needed services such as security, reliability, and
multi-party agreement. These services are:

 WS-Coordination
Provides protocols that coordinate the actions of distributed
applications. This enables existing transaction processing,
workflow, and other systems for coordination to operate in a
heterogeneous environment

 WS-Inspection
Assists in the inspection of a site for available services.

 WS-Referral
Enables the routing strategies used by SOAP nodes in a
message path to be dynamically configured.

 WS-Routing
Provides a simple, stateless, SOAP-based protocol for
routing SOAP messages in an asynchronous manner over
a variety of transports like TCP, UDP, and HTTP.

 WS-Security
Enhances SOAP messaging to provide quality of protection
through message integrity, message confidentiality, and
single message authentication.

 WS-Transaction
Describes coordination types that are used with the
extensible coordination framework described in the WS-
Coordination specification.

The Web Services Enhancements for Microsoft .NET (WSE) can

be used in conjunction with the .NET Framework and Microsoft
Visual Studio® .NET to build XML Web services that use several of
the more advanced protocols, including WS-Security and WS-
Routing, as well as WS-Attachments and Direct Internet Message
Encapsulation (DIME) for defining SOAP attachments and binary
messages respectively.

The WSE can be found on the MSDN Web site at:

http://msdn.microsoft.com/webservices/building/wse/default.aspx

Microsoft .NET Framework Evaluation Guide lxix

 APPENDIX D:
RELATIONSHIP
TO OTHER
MICROSOFT
PRODUCTS
Development Tools
Microsoft® Visual Studio® .NET enables developers to rapidly
design and build the next generation of applications. Using Visual
Studio .NET, programmers can target a variety of devices, visually
construct server based solutions, and integrate with Extensible
Markup Language (XML) Web services.

By providing the most modern and feature-rich development

environment, Visual Studio .NET gives developers the tools for
integrating solutions across operating systems and languages.
Using Visual Studio .NET you can:

 Create, consume, and deploy powerful XML Web services.

 Quickly construct and deploy robust client- and server-side

applications.

 Build high-performance data driven solutions.

Web Services Enhancements for Microsoft .NET (WSE) can be

used to build XML Web services that use several of the more
advanced Global XML Web Services Architecture (GXA) protocols,
including WS-Security and WS-Routing as well as WS-Attachments
and Direct Internet Message Encapsulation (DIME) for defining
SOAP attachments and binary messages respectively.

The Microsoft ASP.NET Web Matrix is a lightweight, free,

community-supported Microsoft Windows®-based tool for ASP.NET
development efforts targeted at hobbyist developers. It features a
Web page designer, integrated database management, support for
XML Web services, mobile applications, and even a personal Web
server for development and testing.

Enterprise Servers
Windows Server 2003
The Windows Server 2003 family takes the best of Windows 2000
Server technology and makes it easier to deploy, manage, and use,
while adding new technologies to maximize performance and
security. The result is a highly productive infrastructure that helps
make networks a strategic asset for organizations.

Windows Server 2003 includes all the functionality customers expect

from a mission-critical Windows server platform, such as security

Microsoft .NET Framework Evaluation Guide lxx

features, reliability, availability, and scalability. In addition, Microsoft
has improved and extended the Windows server platform to enable
organizations to experience the benefits of Microsoft .NET.

Windows 2000 Server

Windows 2000 Advanced Server enables businesses to deploy
highly available and scalable systems. Because it helps ensure that
systems are always online, it is the right choice for running the
applications that businesses depend on. It is also the right choice
for situations that require a high performance server, capable of
supporting multiple processors and larger amounts of memory than
Windows 2000 Server.

Windows 2000 Advanced Server platform contains all the features

and functionality of the standard version of Windows 2000 Server,
plus additional features for organizations that require higher levels of
scalability, reliability, and availability. Windows 2000 Advanced
Server provides the development backbone for demanding Internet
servers and business-critical applications, where scalability and high
availability demands are most critical.

SQL Server 2000

Business today demands a different kind of database solution.
Performance, scalability, and reliability are essential, and time-to-
market is critical. Beyond these core enterprise qualities, Microsoft
SQL Server™ 2000 provides agility to data management and
analysis, enabling organizations to adapt quickly and gracefully
derive competitive advantage in a fast-changing environment. A
complete database and data analysis package, SQL Server 2000
opens the door to the rapid development of a new generation of
enterprise-class business applications that can give organizations a
critical competitive advantage. The record-holder of important
benchmark awards for scalability and speed, SQL Server 2000 is a
fully Web-enabled database product, providing core support for XML
and the ability to query across the Internet and beyond the firewall.
With seamless integration into the Visual Studio .NET Server
Explorer and designers, SQL Server 2000 represents the
comprehensive data access solution for today's developers.

Note: The first Microsoft enterprise server to feature native support

for the Microsoft .NET Framework will be the next generation of SQL
Server, codenamed "Yukon.” This release will embed the common
language runtime (CLR), along with support for multiple
programming languages, in the database engine itself. This means
that software developers will now be able to use familiar .NET
Framework programming languages and Visual Studio .NET to
develop their SQL Server stored procedures, improving the flexibility

Microsoft .NET Framework Evaluation Guide lxxi

and security of their applications.

The integration between .NET Framework technologies, SQL

Server, and Visual Studio .NET will represent a major enhancement
to developer productivity. Developers will be able to leverage their
mid-tier development skills easily on the data tier without changing
the languages or techniques in which they code. Plus, with the
enhancements to the graphical development environment in Visual
Studio .NET and the tight integration with SQL Server "Yukon,"
developers will have an unparalleled ability to build applications
(both smart client and Web applications) that integrate the most
powerful development tool with the most powerful data management
platform.

BizTalk Server 2002

Microsoft BizTalk® Server 2002 provides organizations with the
server, tools, adapters, and vertical accelerators needed to integrate
and automate their business. In today's global economy, companies
need to integrate with a number of heterogeneous applications
across platforms. To that end, Microsoft and its technology partners
offer BizTalk Adapters and BizTalk Accelerators:

 BizTalk Adapters. Microsoft BizTalk Adapters are

additional software components that enable BizTalk Server
to integrate with third-party applications from companies
like SAP, J.D. Edwards, and PeopleSoft. Microsoft
produces two adapters, one for MQSeries and one for SAP.
Third-party companies provide hundreds of additional
BizTalk Adapters.

 BizTalk Accelerators. Microsoft offers three BizTalk

Accelerators—Microsoft BizTalk Accelerator for HIPAA,
Microsoft BizTalk Accelerator for Suppliers, and Microsoft
BizTalk Accelerator for RosettaNet—that vastly reduce the
time, effort, and cost associated with application integration
for healthcare, manufacturing, and B2B networks.

BizTalk Server provides companies with three main benefits:

 Integration of enterprise applications. Today's agile

businesses need to make better decisions more quickly. By
achieving a unified view of their data and applications both
within their organization and with their partners, these
businesses can increase their revenues and decrease their
cost of operation. Data and transformation services and the
application integration features in BizTalk Server 2002 can
provide businesses with the tools they need to achieve this
unified view.

Microsoft .NET Framework Evaluation Guide lxxii

  Automation of business processes. To remain agile,
businesses must be able to integrate their data,
applications, and business partners in an automated,
predictable way so they can achieve the return on
investment that application integration can bring. BizTalk
Orchestration Designer and BizTalk Orchestration Engine
provide organizations with business process automation,
enabling their businesses to run predictably.

 Development of operational excellence. To realize real

return on investment, it must be possible to rapidly deploy
and easily manage an integration solution. This flexibility
can reduce the cost and complexity associated with
application integration. BizTalk Server 2002 introduces
SEED, a revolutionary new technology for automating the
integration of business partners over the Internet.

Exchange Server 2000

In today's business environment, success requires a powerful
infrastructure for creating, storing, and sharing information, as well
as tools for acting on that information with speed and intelligence.
Microsoft Exchange Server 2000 addresses these challenges by
seamlessly integrating with Windows 2000, incorporating more than
two years of customer input and feedback and combining industry-
leading reliability and scalability with unmatched ease-of-
management. Exchange Server 2000 enables application
developers to add collaboration to business applications using built-
in messaging, scheduling, and discussion components as well as
native support for XML. A comprehensive solution, Exchange
Server 2000 provides developers with next-generation messaging
and collaboration for businesses of all sizes.

Commerce Server 2002

Microsoft Commerce Server 2002 is the product for rapidly building
next-generation online businesses. Built using Microsoft .NET
technology, Commerce Server 2002 can extend a site's functionality,
drive profitability, and enhance the user experience globally.
Commerce Server 2002 provides powerful features for user profiling,
personalization, catalog management, order processing,
globalization, and advanced online business analytics.

Providing everything needed to engage and manage a global

network of customers and trading partners, conduct business in
multiple languages and currencies, and empower business users to
make smarter business decisions, Commerce Server 2002
maximizes the effectiveness of online business. Commerce Server
2002 delivers optimal flexibility and speed for building or extending

Microsoft .NET Framework Evaluation Guide lxxiii

 APPENDIX E:
GLOSSARY
powerful Web services-enabled online business solutions more
quickly and with fewer lines of code than ever before. A natural
complement to Visual Studio .NET, Commerce Server 2002 includes
new project types and pre-built business components and tools that
help developers create ASP.NET-based Web solutions.

Commerce Server 2002 builds on six years of experience delivering

the scalable, high-performance, mission-critical solutions enterprise
customers need. Numerous reliable online business solutions have
been delivered with powerful, easy to use management tools that
minimize maintenance time and total cost of ownership.

Host Integration Server 2000

Microsoft Host Integration Server 2000, the follow-up release to the
highly successful Microsoft SNA Server, extends Windows to other
systems by providing application, data, and network integration.
Host Integration Server enables quick adaptation to new business
opportunities while preserving existing infrastructure investments.
With its enterprise-class scalability, performance, and reliability,
Host Integration Server can support organizations' most demanding
business needs.

Microsoft Office
The Microsoft Office XP Web Services Toolkit brings the power of
XML Web services to Office XP by enabling developers to consume
XML Web services in Office XP solutions directly from within the
Office Visual Basic Editor.

The Office XP Web Services Toolkit contains the Web Service

References tool for Microsoft Visual Basic® for Applications plus a
series of technical articles and samples describing how to use the
tool.

Term Definition

.NET Framework The Microsoft .NET Framework is an integral Microsoft Windows® component that supports building
and running the next generation of software applications and XML Web services. It includes
technologies for XML Web services and Web applications (ASP.NET), data access (ADO.NET),
smart client applications (Windows Forms), and many others.

Active Directory The Windows directory service that provides a unified, hierarchical view of complex networks.

ADO.NET A class library in the .NET Framework for data access and manipulation.

ASP.NET A class library in the .NET Framework for building, deploying, and running Web applications and
XML Web services.

Microsoft .NET Framework Evaluation Guide lxxiv

Term Definition

Assembly The primary building block—also the unit of deployment and versioning—of a .NET Framework
application. An assembly includes an assembly manifest, which describes the contents of the
assembly.

C# A new ECMA-approved programming language designed for the .NET Framework. C#, which is an
evolution of C and C++, is type safe and object-oriented. Because it is compiled as managed code, it
benefits from the services of the common language runtime, such as language interoperability,
enhanced security, and garbage collection.

Class Library A library of classes, interfaces, and value types that are included in the .NET Framework and can be
used from any CLS-compliant language. Classes provide pre-packaged functionality that may be
used by developers in writing their own code.

Code access The .NET Framework introduces code access security. This enables administrators to set up
security policies granting different assemblies different security permissions based on evidence about the
assembly—such as from what site, security zone, or URL was an assembly obtained, what is its
strong name, and whether it has a digital signature and from whom.

Common language The core run-time engine in the .NET Framework for securely executing applications. The common
runtime (CLR) language runtime supplies managed code with services such as cross-language integration, code
access security, object lifetime management, and debugging and profiling support.

Common Language A subset of .NET Framework features that are supported by a broad set of compliant languages and
Specification (CLS) tools. CLS-compliant languages and tools are guaranteed to interoperate with other CLS-compliant
languages and tools.

ECMA The European Computer Manufacturers Association, a European standards body created in 1961.
Internationally accredited, ECMA has fast-track approval for ISO and is the forum for successful
standards such as ECMAScript.

Extensible Markup A subset of Standard Generalized Markup Language (SGML) that is optimized for delivery over the
Language (XML) Web. XML provides a uniform method for describing and exchanging structured data that is
independent of applications or vendors.

Garbage collection The process of transitively tracing through all pointers to actively used objects to locate all objects
(GC) that can be referenced and then arranging to reuse any heap memory that was not found during this
trace. The common language runtime garbage collector also compacts the memory that is in use to
reduce the working space needed for the heap.

HTTP Hyper Text Transfer Protocol is a standard Internet protocol for transfer of information between
servers and between clients and servers.

IDL Interface Definition Language. A language used by applications to specify the various interfaces they
intend to offer to other applications.

JIT An acronym for “just-in-time," a phrase that describes an action that is taken only when it becomes
necessary, such as just-in-time compilation or just-in-time object activation.

Loosely coupled A distributed application in which you can change the implementation of one tier without affecting
architecture any of the other tiers. Contrast tightly coupled architecture.

Managed code Code written using the .NET Framework that is then executed and managed by the .NET
Framework's common language runtime (CLR). Managed code must supply the information
necessary for the CLR to provide services such as memory management, cross-language
integration, code access security, and automatic lifetime control of objects. All code based on
Microsoft intermediate language (MSIL) executes as managed code.

Microsoft .NET Framework Evaluation Guide lxxv

Term Definition

Manifest An integral part of every assembly that renders the assembly self-describing via metadata. The
metadata describes which modules and resource files are part of a particular assembly, which types
are exported, and which other assemblies are referenced. It also specifies which security
permissions are required to run, what additional permissions are optionally requested, and what
permissions the assembly refuses.

Metadata Data (or information) about data. In the common language runtime, metadata is used to describe
assemblies and types. It is stored with them in the executable files, and is used by compilers, tools,
and the runtime to provide a wide range of services. Metadata is essential for run-time type
information and dynamic method invocation. Many different systems use metadata—for example,
Type Libraries in COM provide metadata.

Microsoft The CPU-independent instruction set that is consumed by the .NET Framework. Before MSIL can be
intermediate executed, it must be converted to native, CPU-specific code. The .NET Framework common
language (MSIL) language runtime handles that task. The .NET Framework language compilers generate MSIL.

Native code Code that has been compiled to processor-specific machine code.

N-tier System architecture that separates presentation, business logic, data access, and database (or other
persistence mechanism) tiers.

Reflection .NET Framework technology that allows you to examine metadata that describes types and their
members. Reflection can be used to create, invoke, and access type instances at run time.

Serviced component The name for a .NET Framework component that has been enabled for use with COM+ services.

Side-by-side The ability to run multiple versions of the same assembly simultaneously. This can be on the same
execution computer or in the same process or application domain. Allowing assemblies to run side-by-side is
essential to support robust versioning in the common language runtime. Side-by-side is also used to
describe to describe two versions of the .NET Framework running simultaneously on the same
computer.

SOAP A WC3 standard, SOAP is a lightweight protocol for the exchange of information in a decentralized,
distributed environment. It is an XML-based protocol for exchanging structured and type information
on the Web. The SOAP protocol contains no application or transport semantics, which makes it
highly modular and extensible.

Tightly coupled A distributed application where a change to any tier affects some or all the other remaining tiers.
architecture Contrast loosely coupled architecture.

UDDI Universal Description, Discovery, and Integration (UDDI) specification. An initiative that creates a
global, platform-independent, open framework to enable Web service providers to advertise the
existence of their Web services and for Web service consumers to locate Web services of interest.

Unmanaged code Code that was created without using the .NET Framework

Web Services An XML-based contract language for describing the functionality offered by an XML Web service.
Description
Language (WSDL)

Windows Forms A class library in the .NET Framework for building smart client applications

Windows A component of the Windows operating system that provides management information and control in
Management an enterprise environment using industry-wide standards
Instrumentation
(WMI)

WMI See Windows Management Instrumentation.

WSDL See Web Services Description Language.

Microsoft .NET Framework Evaluation Guide lxxvi

Term Definition APPENDIX F:
XHTML FOR
XML-conforming HTML document for use with MORE
an XML processor.
INFORMATION
XML See Extensible Markup Language.

XML Schema A W3C recommendation that specifies how to describe the elements of an XML document formally.
Definition (XSD) The schema can be used to verify the conformance of elements in an XML document.

XML Web services Components which facilitate integration by sharing data and functionality over the network through
standard, platform-independent protocols such as XML, SOAP, and HTTP.

XSD See XML Schema Definition.

For the latest information on the Microsoft .NET Framework, please

see http://www.microsoft.com/netframework.
Information for developers can be found at
http://msdn.microsoft.com/net.

Microsoft .NET Framework Evaluation Guide lxxvii