Visual Studio .NET中.NET框架详解：权威黑皮书

需积分: 2 186 浏览量更新于2024-07-26 收藏 6.7MB PDF 举报

《Visual Studio .NET—The .NET Framework Black Book》是一本由Julian Templeman和David Vitter合著的专业书籍，版权归属于2002年的Coriolis Group, LLC。这本书专为深入理解Microsoft的.NET Framework而设计，是该领域的权威指南。书中涵盖了.NET框架的核心概念、设计原则、开发工具（Visual Studio .NET）的使用以及相关的编程技术。本书的主要内容包括但不限于以下几个方面： 1. **.NET Framework简介**：介绍.NET架构的基本概念，它是一个跨平台的软件开发框架，旨在提供一致的编程体验，支持Windows、Linux和Mac OS等操作系统。 2. **语言集成环境（IDE）—Visual Studio .NET**：详细讲解Visual Studio这个集成开发环境，包括其设计模式、工具集、调试器和版本控制系统的使用，这对于.NET开发者来说是不可或缺的一部分。 3. **类型系统和垃圾回收**：讨论.NET的面向对象特性，如类、接口、泛型和值类型与引用类型的区分，以及自动内存管理（Garbage Collection）的工作原理。 4. **公共语言运行时（CLR）和.NET Framework Class Library (FCL)**：剖析.NET的核心组件，包括通用语言运行时，它是所有.NET语言共享的基础，以及庞大的类库，提供了丰富的预定义类和方法供开发者调用。 5. **安全性与安全性模型**：介绍.NET的安全性策略，如代码签名、权限模型和安全策略，以确保应用程序在运行时的安全性。 6. **网络编程与Web服务**：涵盖如何使用.NET进行网络编程，包括HTTP、SOAP、XML Web Services以及WCF（Windows Communication Foundation）等技术。 7. **性能优化与调试技巧**：探讨如何通过性能分析工具和技术来优化.NET应用，以及如何有效地使用调试器进行问题排查。 8. **版权和法律限制**：强调版权的重要性，规定了未经出版商许可不得复制或商业使用本书内容的规定，以保护知识产权。 9. **法律责任和免责声明**：声明作者和出版商对书中内容的尽职调查，但不承担任何关于程序或文档的明示或暗示保修，强调了使用本书信息的个人性质，非商业用途下使用须获得出版商许可。《Visual Studio .NET—The .NET Framework Black Book》是一本深度探讨.NET技术的实用指南，不仅适合初学者系统学习，也对高级开发者提供了深入理解框架内部机制的窗口。在遵循版权和法律规范的前提下，读者可以从中获取丰富的.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页未读，继续阅读

txp914

粉丝: 22
资源: 703

Visual Studio .NET中.NET框架详解：权威黑皮书

visual studio 2005 extension for.net framework 3.0

.NET FRAMEWORK4.5.2开发工具包

.Net Framework 4.6.1.rar

C#编程入门：掌握.NET Framework 3.5与Visual Studio 2008

C#入门指南：掌握.NET Framework 3.5与Visual Studio 2008

C#入门经典第四版：探索.NET Framework 3.5与Visual Studio 2008

C#入门经典第四版：全面掌握.NET Framework 3.5与Visual Studio 2008

PROGRAMMING THE MS .NET FRAMEWORK WITH MS VISUAL C SHARP .NET DELIVERY GUIDE.pdf

Visual Basic.NET入门：.NET Framework与Visual Studio详解

借助.NET Compact Framework与Visual Studio 2003开发移动应用

最新资源