Home > Microsoft .NET Framework Reviewers Guide

Microsoft .NET Framework Reviewers Guide

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�������������

An Overview of the .NET FrAmeWork�������������

Common Language Runtime (CLR)�������������

Class Libraries�������������

.NET FrAmeWork Architecture�������������

.NET Framework-based Applications�������������

.NET Framework Design Goals�������������

Architecture Drilldown�������������

The Common Language Runtime�������������

The Unified Class Libraries�������������

ASP.NET�������������

XML Web Services�������������

Windows Forms�������������

Common System Namespaces�������������

Data Access with ADO.NET�������������

Directory Services�������������

Enterprise Services�������������

InteropServices�������������

Management�������������

Remoting�������������

Security�������������

.NET Framework Device Support�������������

.NET Compact Framework�������������

ASP.NET Mobile Controls�������������

Administration�������������

Tools for developing with the .NET Framework

Deploying the .NET Framework Redistributable

Microsoft's Application platform

Web Applications with ASP.NET�������������

Inside ASP.NET�������������

Tracing and Debugging�������������

Application Configuration�������������

Updating Applications�������������

Extensibility�������������

State Management�������������

Code Compilation�������������

Caching�������������

ASP and ASP.NET Co-existence�������������

Security�������������

Mobile Web Device Support�������������

XML Web Services�������������

Core XML Web Services Technologies�������������

Create XML Web Services Easily�������������

Testing an XML Web Service�������������

Access an XML Web Service�������������

Windows Server 2003�������������

What's New in IIS 6.0�������������

Building Smart Client Applications�������������

Advantages of Smart Client Applications�������������

Deploying Smart Clients from a Web Server�������������

Code Access Security: Making No-Touch Deployment Safe�������������

Smart Client Versus Browser-Based�������������

Work Offline�������������

Use Resources Efficiently and Safely�������������

Access Local APIs�������������

Use Peer-to-Peer Technology�������������

Consume XML Web Services�������������

A Minimal Windows Form�������������

Programming with Windows Forms�������������

Forms�������������

Controls�������������

Events�������������

Extending Forms�������������

Creating Controls�������������

Mobile Device Development

When to Implement Smart Clients�������������

Summary�������������

Loosely Coupled Designs Enable Scalability�������������

Leverage Operating System Services�������������

Multilanguage Support�������������

Operational Excellence

Developer Productivity�������������

Standards-Based�������������

Appendix A: Changes from �������������������������������� .NET Framework 1.0�������������

Native Support for Developing Mobile Web Applications

Granular Version Control: Side-by-Side Execution

Enable Execution of Windows Forms Assemblies Originating ���� from the Internet

Enable Code Access Security for ASP.NET Applications

Native Support for Communicating with ODBC and Oracle Databases

Unified Programming Model for Smart Client Application Development

Support for IPv6

Scalability, Performance, Documentation

Appendix B: Minimum Configuration Requirements�������������

Platform and Software Requirements�������������

Minimum Requirements

Recommended Software

Recommended Server Software

Hardware Requirements�������������

Minimum Hardware Requirements

Recommended Hardware Requirements

Appendix C: Standards and the .NET Framework�������������

ECMA C# and Common Language Infrastructure Standards�������������

Microsoft Shared Source CLI Implementation "Rotor"�������������

XML Standards�������������

Standards for XML Web Services�������������

Global XML Web Services Architecture (GXA)�������������

Appendix D: RElationship to other Microsoft Products�������������

Development Tools�������������

Enterprise Servers�������������

Windows Server 2003�������������

Windows 2000 Server�������������

SQL Server 2000�������������

BizTalk Server 2002�������������

Exchange Server 2000�������������

Commerce Server 2002�������������

Host Integration Server 2000�������������

Microsoft Office�������������

Appendix E: Glossary�������������

Appendix F: For More Information�������������

Microsoft .NET Framework Evaluation Guide������������� 1



Evaluation criteria

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 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.

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.
  • 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.

An Overview of the .NET FrAmeWork


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.
  • 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 Architecture


.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.

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 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 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, delegate-based event management, dynamic binding, and reflection dramatically reduce the amount of code a developer must write in order to turn business logic into reusable components.

Runtimes are nothing new for languages; virtually every programming language has a runtime. Microsoft Visual Basic� has the most well known runtime (the aptly-named VBRUN), but Microsoft Visual C++� also has one (MSVCRT), as do Microsoft 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 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…

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.

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 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 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 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 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 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 changed its format.

XML Web services are components which facilitate integration across platforms by sharing data and functionality over the network through standard, platform-independent protocols such as XML, SOAP, and HTTP.� XML Web services provide a low-cost, scalable, and flexible solution to the challenges of integration.�

XML Web services solve the challenges facing Web developers by combining the tightly coupled, highly productive aspects of n-tier computing with the loosely coupled, message-oriented concepts of 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)
  • 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:

  • 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 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 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:

  • 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 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 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.

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.

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.

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 demand that their code not be loaded or that it behave differently (by 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 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, such as memory management, code reliability, and 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 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-defined intervals. Many of the reliability features in the .NET 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 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 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 development projects.� A number of Starter Kits are available, 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 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'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 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 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:

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 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 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 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:

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, 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.MobilePage" %>

<%@ Register TagPrefix="Mobile" Namespace="System.Web.UI.MobileControls" Assembly="System.Web.Mobile" %>

<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

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.

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 particular, communicating applications need to have a set of rules for how they are going to represent different data types (such as 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.

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.

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, share, and re-use XML Web services and other programmable resources. With UDDI Services, companies can build and deploy smarter, more reliable applications. For more about UDDI Services in Windows Server 2003, see: http://www.microsoft.com/windows.netserver/evaluation/overview/dotnet/uddi.mspx.

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 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:

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:

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.

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 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 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.

Building Smart Client Applications


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 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 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.

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" 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 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

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.

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 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.

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 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 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.

Summary


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

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 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.

Appendix A: Changes from .NET Framework 1.0


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 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 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 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 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 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 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.

Appendix B: Minimum Configuration Requirements


This section describes the minimum configuration requirements for a computer where the Microsoft� .NET Framework redistributable 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:

  • 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 faster

96 MB or higher

Server

Pentium 133 MHz or faster

256 MB or higher

.

Appendix C: Standards and the .NET Framework


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 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/

  • 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 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

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 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 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.
  • 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 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.

Appendix E:�� Glossary


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.

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 security

The .NET Framework introduces code access security.� This enables administrators to set up 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 runtime (CLR)

The core run-time engine in the .NET Framework for securely executing applications. The common 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 Specification (CLS)

A subset of .NET Framework features that are supported by a broad set of compliant languages and 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 Language (XML)

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

Garbage collection (GC)

The process of transitively tracing through all pointers to actively used objects to locate all objects 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 architecture

A distributed application in which you can change the implementation of one tier without affecting 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.

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 intermediate language (MSIL)

The CPU-independent instruction set that is consumed by the .NET Framework. Before MSIL can be executed, it must be converted to native, CPU-specific code.� The .NET Framework common 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 execution

The ability to run multiple versions of the same assembly simultaneously. This can be on the same 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 architecture

A distributed application where a change to any tier affects some or all the other remaining tiers. 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 Description Language (WSDL)

An XML-based contract language for describing the functionality offered by an XML Web service.

Windows Forms

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

Windows Management Instrumentation (WMI)

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

WMI

See Windows Management Instrumentation.

WSDL

See Web Services Description Language.

XHTML

XML-conforming HTML document for use with an XML processor.

XML

See Extensible Markup Language.

XML Schema Definition (XSD)

A W3C recommendation that specifies how to describe the elements of an XML document formally. 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.

Appendix F: For More Information


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������������� 1

Search more related documents:Microsoft .NET Framework Reviewers Guide

Set Home | Add to Favorites

All Rights Reserved Powered by Free Document Search and Download

Copyright © 2011
This site does not host pdf,doc,ppt,xls,rtf,txt files all document are the property of their respective owners. complaint#downhi.com
TOP