深入浅出Microsoft .NET Framework编程

需积分: 34 74 浏览量更新于2024-07-23 收藏 4.22MB PDF 举报

"Applied Microsoft .NET Framework Programming by Jeffrey Richter" 《应用微软.NET框架编程》是Jeffrey Richter撰写的一本专业书籍，由微软出版社出版。这本书深入探讨了微软的.NET框架，是关于互联网编程的重要参考资料。书中内容涵盖.NET框架的核心概念、设计原理以及实际开发中的应用方法。 .NET框架是微软公司推出的一个全面的开发平台，用于构建和运行各种应用程序。它包含了类库、编译器、运行时环境（即Common Language Runtime，CLR）和其他服务，为开发者提供了丰富的工具和API，以支持多种编程语言，如C#、Visual Basic .NET和C++/CLI等。这本书的重点可能包括以下几个关键知识点： 1. **CLR与类型系统**：介绍CLR如何管理和执行代码，包括内存管理（垃圾回收）、类型安全性和跨语言互操作性。同时，可能会讲解.NET中的元数据和反射机制，使开发者能够动态地检查和操作程序集。 2. **.NET类库**：详细解析BCL（基础类库），包括集合、线程、文件I/O、网络编程等常用类和接口。这有助于开发者高效地编写代码。 3. **组件模型与服务**：探讨Windows Communication Foundation (WCF)、Windows Presentation Foundation (WPF) 和 Windows Workflow Foundation (WF)，这些都是.NET框架提供的现代组件和服务模型。 4. **Asynchronous Programming**：解释异步编程模型，如Async/Await关键字和事件驱动编程，帮助开发者构建高性能、响应迅速的应用程序。 5. **安全性**：讨论.NET框架的安全特性，如代码访问安全、身份验证、授权和加密，确保应用程序的安全性。 6. **设计模式与最佳实践**：指导读者如何利用.NET框架实现常见的设计模式，并遵循最佳实践来提高代码的可维护性和可扩展性。 7. **调试与诊断**：介绍.NET框架提供的调试工具和技巧，以及性能分析方法，帮助开发者找出并解决代码中的问题。 8. **部署与更新**：讲述应用程序的安装、配置和更新策略，包括ClickOnce部署和其他发布技术。这本书不仅适合有经验的.NET开发者深入理解框架，也适合作为初学者的教程，引导他们逐步掌握.NET开发的关键技能。此外，书中包含的实例和代码示例将帮助读者将理论知识转化为实际操作，提升解决问题的能力。通过阅读本书，读者可以全面了解.NET框架的各个层面，从而更好地利用这一强大的开发工具来构建高效、稳定和安全的软件解决方案。

use the corresponding compiler to check the syntax and analyze the source code.

Regardless of which compiler you use, the result is a managed module. A managed module

is a standard Windows portable executable (PE) file that requires the CLR to execute. In the

future, other operating systems may use the PE file format as well.

Figure 1-1 : Compiling source code into managed modules

Table 1-1 describes the parts of a managed module.

Table 1-1: Parts of a Managed Module

Part Description

PE header The standard Windows PE file header, which is similar to the

Common Object File Format (COFF) header. This header

indicates the type of file: GUI, CUI, or DLL, and it also has a

timestamp indicating when the file was built. For modules that

contain only IL code, the bulk of the information in the PE header

is ignored. For modules that contain native CPU code, this header

contains information about the native CPU code.

CLR header Contains the information (interpreted by the CLR and utilities) that

makes this a managed module. The header includes the version of

the CLR required, some flags, the MethodDef metadata token of

the managed module’s entry point method (Main method), and the

location/size of the module’s metadata, resources, strong name,

some flags, and other less interesting stuff.

Metadata Every managed module contains metadata tables. There are two

main types of tables: tables that describe the types and members

defined in your source code and tables that describe the types and

members referenced by your source code.

Intermediate

language (IL)

code

Code that the compiler produced as it compiled the source code.

The CLR later compiles the IL into native CPU instructions.

Most compilers of the past produced code targeted to a specific CPU architecture, such as

x86, IA64, Alpha, or PowerPC. All CLR-compliant compilers produce IL code instead. (I’ll go

into more detail about IL code later in this chapter.) IL code is sometimes referred to as

managed code because the CLR manages its lifetime and execution.

In addition to emitting IL, every compiler targeting the CLR is required to emit full metadata

into every managed module. In brief, metadata is simply a set of data tables that describe

what is defined in the module, such as types and their members. In addition, metadata also

has tables indicating what the managed module references, such as imported types and

their members. Metadata is a superset of older technologies such as type libraries and

interface definition language (IDL) files. The important thing to note is that CLR metadata is

far more complete. And, unlike type libraries and IDL, metadata is always associated with

the file that contains the IL code. In fact, the metadata is always embedded in the same

EXE/DLL as the code, making it impossible to separate the two. Because the compiler

produces the metadata and the code at the same time and binds them into the resulting

managed module, the metadata and the IL code it describes are never out of sync with one

another.

Metadata has many uses. Here are some of them:

§ Metadata removes the need for header and library files when compiling since all the

information about the referenced types/members is contained in the file that has the IL

that implements the type/members. Compilers can read metadata directly from

managed modules.

§ Visual Studio .NET uses metadata to help you write code. Its IntelliSense feature

parses metadata to tell you what methods a type offers and what parameters that

method expects.

§ The CLR’s code verification process uses metadata to ensure that your code performs

only “safe” operations. (I’ll discuss verification shortly.)

§ Metadata allows an object’s fields to be serialized into a memory block, remoted to

another machine, and then deserialized, re-creating the object and its state on the

remote machine.

§ Metadata allows the garbage collector to track the lifetime of objects. For any object,

the garbage collector can determine the type of the object and, from the metadata,

know which fields within that object refer to other objects.

In Chapter 2, I’ll describe metadata in much more detail.

Microsoft’s C#, Visual Basic, JScript, J#, and the IL Assembler always produce managed

modules that require the CLR to execute. End-users must have the CLR installed on their

machine in order to execute any managed modules, in the same way that they must have

the Microsoft Foundation Class (MFC) library or Visual Basic DLLs installed to run MFC or

Visual Basic 6 applications.

By default, Microsoft’s C++ compiler builds unmanaged modules: the EXE or DLL files that

we’re all familiar with. These modules don’t require the CLR in order to execute. However,

by specifying a new command-line switch, the C++ compiler can produce managed modules

that do require the CLR to execute. Of all the Microsoft compilers mentioned, C++ is unique

in that it is the only language that allows the developer to write both managed and

unmanaged code and have it emitted into a single module. This can be a great feature

because it allows developers to write the bulk of their application in managed code (for type

safety and component interoperability) but continue to access their existing unmanaged C++

code.

Combining Managed Modules into Assemblies

The CLR doesn’t actually work with modules; it works with assemblies. An assembly is an

abstract concept that can be difficult to grasp initially. First, an assembly is a logical grouping

of one or more managed modules or resource files. Second, an assembly is the smallest unit

of reuse, security, and versioning. Depending on the choices you make with your compilers

or tools, you can produce a single-file or a multifile assembly.

In Chapter 2, I’ll go over assemblies in great detail, so I don’t want to spend a lot of time on

them here. All I want to do now is make you aware that there is this extra conceptual notion

that offers a way to treat a group of files as a single entity.

Figure 1-2 should help explain what assemblies are about. In this figure, some managed

modules and resource (or data) files are being processed by a tool. This tool produces a

single PE file that represents the logical grouping of files. What happens is that this PE file

contains a block of data called the manifest. The manifest is simply another set of metadata

tables. These tables describe the files that make up the assembly, the publicly exported

types implemented by the files in the assembly, and the resource or data files that are

associated with the assembly.

Figure 1-2 : Combining managed modules into assemblies

By default, compilers actually do the work of turning the emitted managed module into an

assembly; that is, the C# compiler emits a managed module that contains a manifest. The

manifest indicates that the assembly consists of just the one file. So, for projects that have

just one managed module and no resource (or data) files, the assembly will be the managed

module and you don’t have any additional steps to perform during your build process. If you

want to group a set of files into an assembly, you’ll have to be aware of more tools (such as

the assembly linker, AL.exe) and their command-line options. I’ll explain these tools and

options in Chapter 2.

An assembly allows you to decouple the logical and physical notions of a reusable,

deployable, versionable component. How you partition your code and resources into

different files is completely up to you. For example, you could put rarely used types or

resources in separate files that are part of an assembly. The separate files could be

downloaded from the Web as needed. If the files are never needed, they’re never

downloaded, saving disk space and reducing installation time. Assemblies allow you to

break up the deployment of the files while still treating all the files as a single collection.

An assembly’s modules also include information, including version numbers, about

referenced assemblies. This information makes an assembly self-describing. In other words,

the CLR knows everything about what an assembly needs in order to execute. No additional

information is required in the registry or in Active Directory. Because no additional

information is needed, deploying assemblies is much easier than deploying unmanaged

components.

Loading the Common Language Runtime

Each assembly that you build can be either an executable application or a DLL containing a

set of types (components) for use by an executable application. Of course, the CLR is

responsible for managing the execution of code contained within these assemblies. This

means that the .NET Framework must be installed on the host machine. Microsoft has

created a redistribution package that you can freely ship to install the .NET Framework on

your customers’ machines. Eventually, the .NET Framework will be packaged with future

versions of Windows so that you won’t have to ship it with your assemblies.

You can tell if the .NET Framework has been installed by looking for the MSCorEE.dll file in

the %windir%\system32 directory. The existence of this file tells you that the .NET

Framework is installed. However, several versions of the .NET Framework can be installed

on a single machine simultaneously. If you want to determine exactly which versions of the

.NET Framework are installed, examine the subkeys under the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy

When you build an EXE assembly, the compiler/linker emits some special information into

the resulting assembly’s PE file header and the file’s .text section. When the EXE file is

invoked, this special information causes the CLR to load and initialize. The CLR then locates

the application’s entry point method and allows the application to start executing.

Similarly, if an unmanaged application calls LoadLibrary to load a managed assembly, the

DLL’s entry point function knows to load the CLR in order to process the code contained

within the assembly.

For the most part, you don’t need to know about or understand how the CLR gets loaded.

For most programmers, this special information allows the application to just run, and there’s

nothing more to think about. For the curious, however, I’ll spend the remainder of this section

explaining how a managed EXE or DLL starts the CLR. If you’re not interested in this

subject, feel free to skip to the next section. Also, if you’re interested in building an

unmanaged application that hosts the CLR, see Chapter 20.

Figure 1-3 summarizes how a managed EXE loads and initializes the CLR.

Figure 1-3 : Loading and initializing the CLR

When the compiler/linker creates an executable assembly, the following 6-byte x86 stub

function is emitted into the PE file’s .text section:

JMP _CorExeMain

Because the _CorExeMain function is imported from Microsoft’s MSCorEE.dll dynamic-link

library, MSCorEE.dll is referenced in the assembly file’s import (.idata) section. MSCorEE.dll

stands for Microsoft Component Object Runtime Execution Engine. When the managed EXE

file is invoked, Windows treats it just like any normal (unmanaged) EXE file: the Windows

loader loads the file and examines the .idata section to see that MSCorEE.dll should be

loaded into the process’s address space. Then the loader obtains the address of the

_CorExeMain function inside MSCorEE.dll and fixes up the stub function’s JMP instruction

in the managed EXE file.

The process’s primary thread begins executing this x86 stub function, which immediately

jumps to _CorExeMain in MSCorEE.dll. _CorExeMain initializes the CLR and then looks at

the executable assembly’s CLR header to determine what managed entry point method

should execute. The IL code for the method is then compiled into native CPU instructions,

and the CLR jumps to the native code (using the process’s primary thread). At this point, the

managed application’s code is running.

The situation is similar for a managed DLL. When building a managed DLL, the

compiler/linker emits a similar 6-byte x86 stub function in the PE file’s .text section for a DLL

assembly:

JMP _CorDllMain

The _CorDllMain function is also imported from the MSCorEE.dll, causing the DLL’s .idata

section to reference MSCorEE.dll. When Windows loads the DLL, it will automatically load

MSCorEE.dll (if it isn’t already loaded), obtain the address of the _CorDllMain function, and

fix up the 6-byte x86 JMP stub in the managed DLL. The thread that called LoadLibrary to

load the managed DLL now jumps to the x86 stub in the managed DLL assembly, which

immediately jumps to the _CorDllMain function in MSCorEE.dll. _CorDllMain initializes the

剩余499页未读，继续阅读

txp914

粉丝: 22
资源: 709

深入浅出Microsoft .NET Framework编程

Applied Microsoft .Net Framework Programming

Applied Microsoft .NET Framework Programming 一本学习.NET编程的好书

Applied Microsoft+[1].Net Framework Programming(含源码)

Applied_Microsoft_.NET_Framework_Programming

精通Microsoft .NET Framework编程

深入解析Microsoft .NET Framework编程

深入理解Microsoft .NET Framework编程

深入浅出Microsoft .NET Framework编程

Applied XML Programming for Microsoft .NET

微软.NET开发者必读： Applied XML编程指南

最新资源