Visual Studio .NET英文版：.NET Framework 黑书指南

需积分: 10 105 浏览量更新于2024-07-29 收藏 6.7MB PDF 举报

《Visual Studio .NET—The .NET Framework 黑皮书》是由Julian Templeman和David Vitter合作编著的一本专著，版权归属于2002年的Coriolis Group, LLC。本书主要针对Visual Studio .NET平台及其与.NET Framework的深入探讨，提供了全面的技术指导和实用信息。作为一本专业教材，它旨在帮助读者理解并掌握.NET架构的原理和实践。本书的核心内容包括但不限于以下知识点： 1. **Visual Studio .NET简介**：对Visual Studio .NET这款集成开发环境（IDE）进行详尽介绍，涵盖了其界面、工具集、调试器以及与.NET Framework的集成特性，如C#、VB.NET等语言支持。 2. **.NET Framework基础**：深入解析.NET Framework，包括其设计理念、组件模型（如类库、框架类和接口）、公共语言运行时（CLR）和垃圾回收机制。读者可以了解到.NET如何提供跨平台的能力，支持分布式计算和网络服务。 3. **架构与设计原则**：书中可能涉及面向对象编程、组件化、事件驱动编程等核心设计原则，以及如何利用.NET Framework实现高效、可扩展和可靠的应用程序。 4. **开发流程与最佳实践**：涵盖项目管理、代码编写规范、单元测试、性能优化和安全性策略等内容，帮助开发者构建高质量的.NET应用程序。 5. **技术案例分析**：书中可能包含多个实际项目的开发过程和解决方案，展示如何在Visual Studio .NET环境中应用.NET Framework解决复杂问题。 6. **版权与法律声明**：强调了未经许可不得复制或商业用途的版权要求，以及关于责任限制和免责声明的规定，确保用户合法使用和传播本书信息。 7. **安全与合规性**：讨论了如何确保.NET应用程序符合相关法规，包括数据保护、隐私和软件许可等方面。阅读《Visual Studio .NET—The .NET Framework Black Book》，开发者不仅能提升编程技能，还能深入理解微软.NET技术生态系统，从而在实际项目中做出高效且有竞争力的解决方案。然而，由于版权原因，未经许可，书中的部分信息不能随意复制或用于其他商业用途，否则将构成侵权。

Table 1.1: A comparison of the features of C++ Java, and C#.

ANSI C++ Java C#

by reference semantics for some types

Pointers and

references supported

Only references

supported

References supported; pointers

allowed in “unsafe” code blocks

Support for variable

argument lists

No direct support for

variable argument lists

No direct support for variable

argument lists

No support for

properties

Properties supported

through coding

conventions

Properties supported as first-class

language feature

No support for

events

Events supported through

coding conventions

Events supported as first-class

language feature

No delegate support No delegate support Support for delegates (class-

based function pointer equivalent)

How Does the .NET Architecture Work?

In this section, we look a little deeper into how the .NET architecture works. With .NET,

Microsoft has created a whole new programming and runtime environment with a large

number of completely new features and mechanisms. While it isn’t necessary at this stage to

understand how it all works in great detail, having a basic understanding of the architecture

will help you to get started with .NET.

IL and Metadata

In the .NET world, compilers still produce EXE and DLL files, but the content of these files is

different. As well as the IL that results from compiling the source code, executable files

contain metadata.

Metadata is a word you’ll hear a great deal when talking about .NET and how it works.

Metadata is data that is used to describe classes and what they can do, separate from the

code of the class itself. It’s important to understand that metadata isn’t part of the class in the

same way that variables and methods are, but instead is used to describe classes.

Why do you need metadata? When you’re dealing with components, there are properties

that need to be discovered at runtime and don’t really belong in the code. Take security as

an example: Suppose an application contains a component that only certain users are

allowed to access, and that the list of permitted users and groups can change over time. The

runtime obviously needs to check the list of permitted users in order to validate requests—

how is it going to do this? If the security data is provided in code, the runtime will need to

create an object and query it, which is awkward. And if the list of permitted users changes,

the developers will have to alter the code and rebuild the object.

The solution is to keep data like this separate from the object, so that it can be queried by

system tools and other applications. Microsoft’s existing component architecture, COM, uses

two mechanisms to store metadata, and each is used to store different types of metadata.

The first is the Windows Registry, which is used for identification and configuration data, and

COM uses this to locate components and find out how they should be created. The second

mechanism is the type library, which contains information about the internal structure of the

component itself including descriptions of the methods, attributes, and events that the

component supports.

The trouble with these approaches is that both mechanisms use storage external to the

component, and this raises the possibility of all sorts of problems. A component can get

separated from its type library, or associated with one that belongs to another version, or its

registry information can get overwritten or not written at all—the possibilities are (almost)

endless. .NET components, on the other hand, are self-contained, with the metadata being

held in the same file as the component itself. This makes them a lot more portable and a lot

less susceptible to configuration errors.

The CLR uses metadata for many purposes including:

§ Locating and loading classes

§ Laying out objects in memory

§ Finding out what methods and properties a class has

§ Enforcing security

§ Discovering a class’s transactional behavior

Most of the metadata associated with a class is provided by the compilation process, but it is

possible to create your own metadata items, called attributes, and attach them to your own

classes. This topic is covered in Chapter 2.

JIT Compilation

JIT compilation is performed by just-in-time compilers, also known as JITters.

Why not compile source code straight down to native code? There are two reasons—

portability and efficiency. Native code isn’t portable, but IL is designed to be. If .NET gets

ported to non-Windows platforms, it will be important that compiled modules can be run

elsewhere. For efficiency, IL code is only JIT compiled as it is needed, and there may be

parts of an application that are never used, so they will never take up machine resources by

being compiled. It is important to note, though, that code is always JIT compiled before being

run, so that IL code is never directly executed.

Each method in a .NET executable file has a stub attached to it by the class loader. When a

method is first executed, the stub passes control to the JIT compiler, which converts the IL to

native code and then modifies the stub so that subsequent invocations will cause direct

execution of the native code. This means that methods are only JIT compiled when

necessary; therefore, the more an application is run, the more of it tends to be converted to

native code.

.NET code is JIT compiled in one of two ways. The normal way is for the code to be

compiled as it is executed, as I outlined in the previous paragraph. It is, however, also

possible for IL code to be JIT compiled when an application is installed.

The JIT compilation process, shown in Figure 1.3, is normally accompanied by verification,

during which the IL is examined to check that it is type safe, and that objects are only

performing legal operations. Note that not all code can be verified because some high-level

languages that may compile down to IL use constructs that can’t be checked, such as C

pointers.

Figure 1.3: CLR compilation a loading.

Managed Code and Garbage Collection

One of the problems with traditional C code is that programmers have to manually deallocate

memory that they have dynamically allocated. This manual memory management has led to

many problems. If a programmer forgets to deallocate memory, the program is subject to

memory leaks, whereas if he or she deallocates memory more than once, the program may

well crash.

The CLR implements dynamic memory management through the use of garbage collection.

The programmer is responsible for allocating memory, but it is the CLR that clears up

unused memory. Therefore, .NET programs never suffer from the problems traditionally

associated with manual memory management. The system knows how many clients are

referring to an object, and when that reference count drops to zero, the system knows that it

is safe to delete the object.

Code that is run under the garbage collection system is known as managed code. All VB and

C# code is managed, and C++ programmers have the option of compiling down to traditional

object code or to .NET managed code. There are some restrictions when using C++ to write

managed code, such as the limitation to single inheritance, but in many cases, the

advantages to C++ programmers are tremendous.

Note that the garbage collector only reclaims unused objects when it needs to because it

does not want to impact program performance unnecessarily. This means that it is not

possible to tell exactly when an object will be reclaimed; if the program does not run short of

resources, it may well be that objects are not reclaimed at all.

Namespaces

Namespaces are heavily used in .NET as a way to organize classes into a hierarchy. They

are also used to stop developers from having to think up arcane naming conventions in order

to ensure that the names they choose for their classes don’t clash with those chosen by

Microsoft or other developers.

The concept of a namespace is familiar to C++ programmers. They are used in a similar way

in .NET, but have extra functionality. Java programmers will find that namespaces are similar

to packages, but without the link to directory paths that packages impose.

Namespaces provide a way to group classes by providing an extra level of naming beyond

the class name. For example, if you had several classes having to do with banking, you

could wrap them in a namespace like this:

namespace Bank

{

There are two sorts of assembly—shared and private. A shared assembly is stored in the

global assembly cache, where everyone has access to it. A private assembly, on the other

hand, is used by a single application and is stored in the application’s directory or

somewhere else local to it. Assemblies are found by searching paths. For private

assemblies, the path includes the application’s directory and subdirectories. For shared

assemblies, the path consists of the same directories plus the global assembly cache.

Assemblies are important because the assembly it belongs to is part of a type’s identity. If

assembly A contains a type T and assembly B also contains a type called T, then these are

two different types as far as the CLR is concerned.

How do namespaces fit in with assemblies? The answer is that there’s no firm connection. It

may well be that all the classes belonging to a namespace—say Bank—may be built into an

assembly called Bank.dll, but this isn’t mandatory. In fact, all the standard System

namespaces supplied by Microsoft reside in mscorlib.dll, the central .NET assembly.

A system of versioning is enforced on shared assemblies, with each assembly possessing a

four part version number (known as a compatibility version) that looks like an IP address. A

typical version number might be 1.3.6.9. The CLR uses the version number to determine

whether the assemblies are compatible. There is a default policy for deciding compatibility,

but if you do not like the policy, you can define your own. The default policy states that if the

first two parts of the version are different, assemblies are viewed as incompatible. If the first

two parts are the same but the third is different, they may be compatible, and if only the

fourth part differs, they are most likely compatible.

Let’s explore assemblies and IL by writing a simple “Hello World” application, compiling it,

and then looking at the resulting executable. I’ll write the example in C#, to give you a

sample of what C# code looks like:

public class Hello {

public static void Main() {

System.Console.WriteLine("Hello World!");

}

Assuming that you’ve entered the source code into a file called Hello.cs, you can compile it

from the command line like this:

C:>csc Hello.cs

The result is an EXE file of about 3KB in size, which contains the IL code and a small loader

that loads the CLR in order to run the JIT compiler.

You can see what is inside the file by using the IL disassembler utility, ILDASM, which

comes as part of the .NET Framework SDK, and is located in the SDK’s bin directory along

with the other SDK tools. If you open the Visual Studio .NET Command Prompt you can run

it by typing “ildasm” on the command line. Once loaded, use the File menu to open the EXE

file; your screen should look like the display shown in Figure 1.4.

剩余641页未读，继续阅读

Darling__

粉丝: 3
资源: 7

Visual Studio .NET英文版：.NET Framework 黑书指南

Visual Studio .NET编程秘籍：2007中文版指南

Visual Studio .NET 2003企业模板部署指南

Visual Studio.NET编程秘籍：技巧与在线资源指南

Visual Studio.NET使用技巧手册中英文版

Visual Studio .NET企业版：ORM建模与Visio数据库设计详解

Visual studio 2003.net 英文版（002）

Visual studio 2003.net 英文版（003）

Visual studio 2003.net 英文版（004）

Visual studio 2003.net 英文版（001）

Visual studio 2003.net 英文版（006）

最新资源