Tài liệu C# .NET Web Developer`s Guide P2 pdf

Interoperability with Unmanaged Code As you can probably guess, unmanaged code is code that isn’t managed by the .NET Common Language Runtime.. COM components interoperate with the .NET

in use, these objects will always have a reference count greater than zero, so unless they are implicitly deconstructed, their memory may never be recovered

For a C or C++ programmer—accustomed to ensuring that objects are properly destroyed, essentially managing memory on their own—this sounds per-fectly normal, and a good reason for not trusting anyone else to take care of managing resources However, in the NET environment, Microsoft is striving to make developing software easier Later in this chapter, we cover a how NET garbage collection works, and the improvements that have been made over strict reference counting or manual memory management approaches

Versioning Support

Anyone who doesn’t understand the phrase “DLL Hell” hasn’t been developing (or at least supporting) software for Windows very long For the uninitiated, you’ll find yourself in DLL Hell someday when a customer installs a software package that uses one of the same DLLs as your application However, your appli-cation used version 1.0 of this DLL, and the new software replaces it with version 1.1.We developers all always make sure everything is 100% backwards-compat-ible, right? The new DLL makes your application exhibit some strange problem

or perhaps just stop working altogether After a lot of investigation, you figure out what the offending DLL is and have the customer replace the new one with the version that works with your software Now their new software doesn’t work… welcome to DLL Hell Many developers resort to simply installing every DLL their application requires in the application directory so that it will be found first when the application loads the libraries.This defeats the purpose of shared

libraries, but it is one way around the problem

COM was going to change this; one of its primary tenants was that you never changed a methods interface you simply add new methods Unfortunately, software developers are frequently perfectionists, and leaving a “broken” function alone just chafes some people Problem is, changing a components interface once it’s in use can have adverse affects on the client software that expected the old behavior Because COM objects are loaded using information in the Registry, simply placing the DLL or control in the application directory doesn’t work for this problem The NET architecture now separates application components so that an application always loads the components with which it was built and tested If the application runs after installation, the application should always run.This is done

with assemblies, which are NET-packaged components Although current DLLs

and COM objects do contain version information, the OS does not use this information for any real purpose Assemblies contain version information that the

.NET Common Language Runtime uses to ensure that an application will load the components it was built with.We cover more of the specifics of how assem-blies and versioning works later in the chapter

Support for Open Standards

In today’s world, not every device you may want to work with is going to be running a Microsoft OS or using an Intel CPU Realizing this, the architects of NET are relying on XML and its most visible descendant, SOAP, an emerging standard for sending messages across the Internet that activates programs or appli-cations regardless of their underlying infrastructure SOAP will provide the means for disparate systems to exchange information easily, but even more, SOAP allows you to invoke methods on remote systems and return the results Because SOAP

is a simple text-based protocol similar to HTTP, it can easily pass through fire-walls, unlike DCOM or CORBA objects

Other standards employed by the NET platform include Universal Description, Discovery, and Integration (UDDI), a directory of companies and their XML interfaces and the Web Services Description Language (WSDL), which describes what a piece of application code can do By basing much of NET on open standards and by submitting the proposed draft standards for C#

and the NET Common Language Infrastructure to ECMA, an international standards organization, Microsoft hopes to see its version of the future of software adopted beyond its own domain

Easy Deployment

Today, developing installations for Windows-based applications can be incredibly difficult, to the point that most companies use third party tools for developing their installation programs, and even then it’s not pleasant.There are usually a large number of files to be installed in several directories, various Registry set-tings, installation of required COM components, and shortcuts that need to be created, and so on Completely uninstalling an application is nearly impossible, most leave bits and pieces of themselves around even if they provide an uninstall feature.With the release of Windows 2000, Microsoft introduced a new installa-tion engine that helps with some of these issues, but it is still possible that the author of a Microsoft Installer Package may fail to do everything correctly Even with those third party tools specifically designed to make developing installation programs easier, it is still frequently a monumental task to correctly install a retrievial application

The NET design team must have felt the same way about this problem, because NET plans to do away with these issues for good .NET components are not referenced in the Registry, thanks to the use of metadata and reflection, components are self describing In fact, installing many NET applications will require no more than copying their files to a directory, and uninstalling an appli-cation will be as easy as deleting those files

Distributed Architecture

Today’s distributed applications are much different than those we will see in the future Microsoft certainly believes this; they say they are betting the company on the concept of distributed Web services

Using the Visual Studio.NET Setup Tools

Realizing that deploying applications and authoring installation pack-ages is frequently a monumental task, the Visual Studio.NET team inte-grated a number of setup tools into the Visual Studio.NET environment After you have completed your Visual Studio.NET project

develop-ment, start a new project from the File menu Choose Setup and

Deployment Projects from the selection list You’ll see a number of

setup project options listed:

■ Cab Project

■ Deploy Wizard

■ Merge Module Project

■ Setup Project

■ Setup Wizard

■ Web Setup Project Using the wizards, you can select the Visual Studio project you want

to use and have a setup or deployment project created automatically If the defaults are not sufficient for your needs, you can use the new setup project as a basis for creating your custom setup or deployment.

Developing & Deploying…

For example, today when a user is interacting with a portal site, it appears to them that they are working with one remote server Most of us know that is nor-mally not the case, at least for a site of any significant size.There are various servers and applications behind the scenes are accessing information on several remote sites, combining it with information from their user database and merging

it all into an integrated product that is delivered to the user via their browser

As useful as these types of applications are, they are all very complex to develop and maintain Each provider of information has developed different interfaces to access data and processes on their servers.This redundant develop-ment is grossly inefficient and for the most part fairly boring, so there has been a great deal of activity around three standards to streamline the process: XML, SOAP, and UDDI As we discussed earlier, these are used in NET and also in competing, less well known initiatives from IBM and Sun

Interoperability with Unmanaged Code

As you can probably guess, unmanaged code is code that isn’t managed by the NET Common Language Runtime However, this code is still run by the CLR,

it just doesn’t get the advantages that it offers, such as the Common Type System and Automatic Memory Management.You will probably end up using unman-aged code in a couple of different situations:

■ Calling DLL functions There is a lot of functionality locked inside DLLs today Not every company is going to rush to deliver a NET component version of their products, so if you need to interface with them, you’ll be calling unmanaged code

■ Using COM components This is likely to be for pretty much the same reasons you might be required to call DLL functions

■ Calling NET services from COM components Although this sounds a little odd, it is possible A COM client can be made to call a NET component as though it was a COM server

Here’s a little more information on the COM interoperability issue Microsoft didn’t want to force companies to abandon their existing COM components;

especially because many of Microsoft’s own products are COM-based today

COM components interoperate with the NET runtime through an interop layer that handles all the work required when translating messages that pass back and forth between the managed runtime and the COM components operating as unmanaged code

On the other side of the coin, companies with a vested interest in COM technology might want to use a few bits and pieces from the NET platform, sticking a toe in before taking the plunge COM clients can easily interface with

.NET components through the COM interop layer.

Security

Distributed component-based applications require security, and thus far Microsoft hasn’t had a lot of positive feedback about its products’ security features

Fortunately, the NET designers decided to take a new approach, different than traditional OS security, which provides isolation and access control based on user accounts, and also unlike the model used by Java, where code that is not trusted is run in a “sandbox,” with no access to critical resources.The NET Framework provides a fine-grained control of application security

Security for NET applications starts as soon as a class is loaded by the CLR Before the class loader instantiates a class, security information—such as accessi-bility rules and self-consistency requirements—are checked Calls to class methods are checked for type safety If you’ve ever heard of a security vulnerability caused

by a “buffer overrun,” you can understand why this is important.With verified code, a method that is declared as taking a 4-byte integer parameter will reject an attempt to call it with an 8-byte integer parameter.Verification also prevents applications from executing code at a random location in memory, a common tactic in buffer overflow exploits

Additionally, as code requests access to certain resources, the class credentials are verified .NET security crosses process boundaries and even machine boundaries to prevent access to sensitive data or resources in a distributed application environ-ment.The following are some of the basic elements of the NET security system:

■ Evidence-based security is a new concept introduced by the NET Framework. An assembly contains several important pieces of information that can be used to decide what level of access to grant the component Some of the information used includes what site the

com-ponent was downloaded from, what zone that site was in, (Internet, intranet, local machine, and so on) and the strong name of the assembly.

The strong name refers to an encrypted identifier that uniquely defines the assembly and ensures that it has not been tampered with

■ The NET Common Language Runtime further provides secu-rity using a Policy-Driven Trust Model Using Code Evidence.

It sounds worse than it really is Essentially this is a system of security policies that can be set by an administrator to allow certain levels of access based on the component’s assembly information.The policies are set at three levels: the enterprise, the individual machine, and the user

■ Calling NET Framework methods from the Base Class Library get the benefits of built in security. That is, the developer doesn’t have to make explicit security calls to access system resources However,

if your components expose interfaces to protected resources, you will be expected to take the appropriate security measures

■ Role-based security plays a part in the NET security scheme.

Many applications need to restrict access to certain functions or resources based on the user, and NET introduces the concepts of identi-ties and principals to incorporate these functions

■ Authentication and authorization functions are accessed through a single API.It can easily be extended to incorporate appli-cation-specific logic as required Authentication methods include basic operating system user identification, basic HTTP, ASP.NET forms, Digest and Kerberos, as well as the new NET service, Microsoft NET Passport

■ Isolated storage is a special area on disk assigned to a specific assembly by the security system. No access to other files or data is allowed, and each assembly using isolated storage is separated from each other Isolated storage can be used for a saving a components state, or saving settings, and can be used by components that do not have access

to read and write files on the system

■ A robust set of cryptographic functions that support encryp-tion, digital signatures, hashing, and random-number generation are included in the NET Framework. These are implemented using well-known algorithms, such as RSA, DSA, Rijndael/AES,Triple DES, DES, and RC2, as well as the MD5, SHA1, SHA-256, SHA-384, and SHA-512 hash algorithms Additionally, the XML Digital Signature specification, under development by the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C), is also available

The NET Framework uses these cryptographic functions to support various internal services.The cryptographic objects are also available in the Base Class Library for developers who require this functionality

Performance and Scalability

Let’s face it—there is no magic bullet that will allow a poorly designed applica-tion to scale well.What the NET Framework is giving you are tools to make it easier to design better performing software One big gain for Web development will come from ASP.NET’s improved support for keeping code, data, and presen-tation separate .NET offers features for transaction handling and component pooling, but makes them easier to use than they were in previous incarnations, so more development will be likely to take advantage of them.The NET Base Class Library has an enormous set of functionality, which means that you will have to write less basic code and spend more time refining the features and performance

of your applications

New versions of Microsoft software christened with the NET emblem offer improved performance over earlier versions SQL Server.NET offers quite an enhancement over earlier versions of the database engine, and other server prod-ucts offer enhanced scalability as well.When you redesign an application around the NET Framework, take advantage of the latest advances all around and see what the results are

Components of the NET Architecture

As we mentioned earlier, there is a lot to the NET Framework In this section,

we identify the individual components and describe their features and how they fit into the overall picture

.NET Runtime

The heart of the NET Framework is the CLR Similar in concept to the Java Virtual Machine, it is a runtime environment that executes MSIL code Unlike the Java environment, which is the concept of one language for all purposes, the NET platform supports multiple programming languages through the use of the Common Language Specification, which defines the output required of com-pilers that want to target the CLR

Managed/Unmanaged Code

Because all code targeted at the NET platform runs with the CLR environment,

it is referred to as managed code.This simply means that the execution of the code and its behavior is managed by the CLR.The metadata available with man-aged code contains the information required to allow the CLR to manage its safe

execution By safe execution we mean memory and security management, type

safety, and interlanguage interoperability Unmanaged code can write to areas of memory it does not own, execute instructions at arbitrary locations in memory, and exhibit any number of other bad behaviors that cannot be managed or pre-vented by the CLR Most of the applications running on Windows today are unmanaged

Intermediate Language

The NET intermediate language, MSIL, is defined in the Common Language Specification It is an amalgam of a low-level language similar in many ways to a machine language and a higher object language.You can write applications directly

in MSIL, much as you can write directly in assembly language.Thankfully, this is not necessary for most purposes

Common Type System

.NET applications, regardless of their source languages all share a common type system.What this means is that you no longer have to worry when doing devel-opment in multiple languages about how a data type declared in one language needs to be declared in another Any NET type has the same attributes regardless

of the language it is used in Furthermore, all NET data types are objects,

derived from System.Object.

Because all data types derive from a common base class, they all share some basic functionality, for example the ability to be converted to a string, serialized,

or stored in a collection

.NET Base Class Library (BCL)

If I could have bought a library that offered everything the NET Base Class Library offers when I started programming, a year’s salary would have seemed reasonable—there really is that much to it Almost everything in the NET envi-ronment is contained within the BCL Let’s look at a “Hello World” example:

using System;

class Hello {

public static void Main() {

Console.WriteLine("Hello World");

} }

The only function contained in this simple program is a call to the WriteLine method of the Console class.What is really unique about the NET environment

is that NET languages don’t have to implement even the most basic functions; they are available in the BCL Because all NET languages share the same

common set of libraries, the code being executed by your C# program is the same code being executed by a program written in another language.This means that all languages that target the NET environment essentially share the same capabilities, except they have different syntax

Some people will wonder why we even have different languages if they all have the same capabilities A few reasons immediately spring to mind:

■ Programmers don’t like change

■ Programmers usually have a favorite language

■ Programmers don’t like change…

Imagine if Microsoft had come out with all the good things in NET, but said that in order to use it, we all had to learn a new language Lots of people might have never even given it an honest look unless forced by their employers Making

it available for all languages makes it seem less like the chore of learning a new language and more like the excitement of receiving a new library with tens of thousands of functions that will make your life as a developer easier

Assemblies

Assemblies are the means of packaging and deploying applications and compo-nents in NET Just like a compiled application or component today, assemblies can be made up of either single or multiple files An assembly contains metadata information (covered in the next section), which is used by the CLR for every-thing from type checking and security to actually invoking the components methods All of this means that you don’t need to register NET components, unlike COM objects

Metadata

Metadata is the feature that lets the CLR know the details about a particular component.The metadata for an object is persisted at compile time and then

queried at runtime so that the CLR knows how to instantiate objects, call their

methods, and access their properties.Through a process called reflection, an

appli-cation can interrogate this metadata and learn what an object exposes.This is

similar to the way IDispatch and type libraries work in COM.

Unlike COM, where the information about a component can be found in type libraries and the Registry, where it is only associated with the actual compo-nent, NET metadata is stored within the component itself in a binary format packaged inside the assembly.The metadata contains a declaration for every type and a declaration, including names and types, for all of its members (methods, fields, properties, and events) For every method implemented by the component, the metadata contains information that the loader uses to locate the method body It is also possible (but not required) for the creator of a class type to asso-ciate help text and comments with a method or parameter in the metadata, sim-ilar to the way that information can be associated with a component using information within the IDL in the COM world

Besides the low-level information described in this section, a component also includes information regarding its version and any culture information specific to the component.The culture information can be queried at runtime and used in

developing localized applications Look at the System.Reflection.AssemblyName class

as a place to get started, and check out the CultureInfo class to see how extensive

the culture support of NET components can be.You can also use reflection to determine a components version, which might be useful if your application is dynamically loading components and needs to make adjustments for different versions

Assemblies and Modules

.NET applications are deployed as assemblies, which can be a single executable or

a collection of components.When you create a NET application, you are actu-ally creating an assembly, which contains a manifest that describes the assembly

This manifest data contains the assembly name, its versioning information, any assemblies referenced by this assembly and their versions, a listing of types in the assembly, security permissions, its product information (company, trademark, and

so on), and any custom attribute

An assembly that is shared between multiple applications also has a shared name (also known as a strong name).This is a key pair containing a globally unique

name (think GUID from COM) as well as an encrypted digital signature to pre-vent tampering.This information is optional and may not be in a component’s manifest if it was not intended as a shared component