.NET Framework FAQ 作者Andy McMullan 译者 荣耀 更新日期： 2002-09-10 这篇FAQ试图回答关于.NET Framework基本原理的一些常见问题。说到基本原理，我是指.NET Framework底层运作机制的具体细节，讨论主题包括配件（assemblies）、垃圾收集机制、安全性、COM互操作以及远程化（remoting）等，并涵盖类库最常用的部分。至于.NET Framework的其它方面，比如ASP.NET、ADO.NET和WinForms，不在本FAQ讨论范围。 这篇FAQ的灵感来自于DOTNET邮件列表。假如你还没有成为这个邮件列表的成员，可以从此加入：http://discuss.develop.com/dotnet.html。在这儿还可以查阅邮件列表存档文件。 假如你有任何评注、建议、更正或批评，请给我写信（andy@andymcm.com）。 假如你对C#感兴趣，为什么不看看我的“C# FAQ for C++ programmers”呢？（英文：http://www.andymcm.com/csharpfaq.htm，中文：http://www.royaloo.com/articles/articles_2002/CSharpFAQ.htm） 声明1：这篇FAQ不过是我对从形形色色的渠道搜集到的信息的个人阐述而已，来源包括DOTNET邮件列表以及五花八门的微软文档。这些答案并非多么得完备，甚至可能不完全正确。即使这些答案今天是正确的，说不定明天就不再如此。 声明2：这篇FAQ和DOTNET邮件列表或Developmentor（把持这个列表的公司）或微软没有任何正式联系。 修订历史 2002-07-09 加入序列化一节 2002-06-07 修整“资源”部分，加入新的书籍推荐和Weblogs主题 2002-01-17 很小的更新，以反映版本1的来临 2001-08-20 更新所有代码样例，使其完全兼容于Beta 2。 2002-06-28 很小的更新，以反映Beta2的到来。 2000-11-18 向“类库”一节，加入“跟踪”子小节 2000-11-13 为Beta1的到来而更新 2000-11-09 着手编写“类库”一节 2000-11-03 加入“IL”一节 2000-10-14 加入“代码访问安全”一节 2000-08-29 开始维护“修订历史” 2000-07-29 至 2000-08-28 杂七杂八的更新（没作记录） 2000-07-29 公布本FAQ第一版 内容 2.6 在.NET环境下，“托管（managed）”一词的含义是？ 3.3 私有配件（private assembly）和共享配件（shared assembly）之间有什么区别？ 4.3 我能编写自己的.NET宿主（.NET host）吗？ 5.2 当对象最后一个引用被解除时，它也并不总是立即被销毁，真的吗？ 5.5 非确定性销毁机制对从托管代码（managed code）中使用COM对象有影响吗？ 5.6 我听说应该避免使用Finalize方法，我应该在我的类里实现Finalize方法吗？ 6.3 我想序列化我的类的实体，我应该使用 XmlSerializer、SoapFormatter和BinaryFormatter中的哪一种？ 6.6为什么当我试图序列化一个散列表（Hashtable）时报错？ 6.7 XmlSerializer抛出了一个一般性的错误：“在反射MyClass时出错”，我怎么才能查明出了什么问题？ 7.2 我可以创建我自己的元数据特性（metadata attributes）吗？ 7.3 我可以创建我自己的上下文特性（context attributes）吗？ 8. 代码访问安全（Code Access Security） 8.5 我怎么更改代码组的权限集（permission set）？ 8.7 我遇到了一些CAS麻烦，我如何才能诊断是什么地方出了差错？ 9. 中间语言（Intermediate Language，IL） 9.2 能从IL“反向工程”（reverse-engineered）出源代码来吗？ 11.1 .NET remoting（远程化）的工作机理是怎样的？ 11.2 我怎么才能从.NET程序中访问Win32 API？ 12.5.5 我怎么才能知道线程池工作项（work item）什么时候结束了？ 12.6.1 对跟踪/日志（tracing/logging）有内建支持吗？ 很难用一句话说清楚。按照微软的说法，.NET是一个“革命性的新平台，构建于开放的Internet协议和标准之上，并提供工具和服务，从而可以新的方式融合计算和通讯。” 更实在一些的定义应该是这个样子：.NET是一个用于开发和运行软件应用的新环境。特色有：开发基于Web的服务更加容易；具有丰富的标准运行时服务，可以被不同程序语言编写的组件所使用；具有跨语言和跨机器互操作能力。 注意，当术语“.NET”被用于此FAQ时，它只指新的.NET运行时以及与之相关的技术，有时称之为“.NET Framework”。这篇FAQ不涉及微软正往上贴.NET名头的任何其它五花八门的现有的和新的产品与技术（比方“SQL Server.NET”）。 非也。倘若你编写任何Windows软件（使用ATL/COM、MFC、VB甚至是原生的Win32 API），.NET可以为你目前行事方式提供一个可行的替代方案（或者说是一种额外的办法）。当然了，假如你在开发Web站点的话，.NET有许多可以勾起你兴趣的东西 — 不单单是ASP.NET。 比尔·盖茨在2000年6月22日举行的“论坛2000”上发表了一个演讲，描绘了.NET美景。在2000年7月召开的职业开发者大会期间，举行了许多关于.NET技术的会议。与会代表们还领到了包含有.NET framework/SDK和Visual Studio.NET预览版的光盘。 SDK 1.0和运行时的最终版公开发行于太平洋标准时间2002年1月15日下午6点左右，与此同时，Visual Studio.NET最终版也向MSDN订户开始发售。 有很多可用工具，下面以价格递增顺序加以描述： .NET Framework SDK：SDK是免费的，包括C++、C#和VB.NET命令行编译器，以及许多其它辅助开发工具（译注：印象中并不包含C++命令行编译器）。 ASP.NET Web Matrix：这是一个来自微软的免费ASP.NET开发环境。除了GUI开发环境外，下载文件中还包括一个简单的Web服务器，可以用来代替IIS作为ASP.NET应用的宿主（host）。这为Windows XP家庭版用户打开了ASP.NET开发之门 — 这个版本的Windows不能运行IIS。 微软Visual C# .NET标准版：这是一个廉价的（大约100美元左右）Visual Studio.NET版本，仅限于一种语言，并且只有有限的向导支持，比方说，没有提供对类库或自定义UI控件的向导支持。它对于初学者学习是有用的，对于有本事在缺乏向导的情况下进行开发的机灵鬼来说，也是有意义的。除了C#版，还有VB.NET和C++版。 微软Visual Studio.NET专业版：假如你有一个Visual Studio 6.0授权，你就可以获得升级版。在写这些文字的时候（2002年6月），微软正在对升级版提供300美元的邮寄折扣，因此，这是一个相当划算的买卖。Visual Studio.NET包括了对所有微软语言（C#、C++、VB.NET）的支持，它还包含广泛的向导支持。 位于“价格光谱”最高端的是Visual Studio.NET企业版和企业架构师版。它们提供了额外的功能，例如Visual Sourcesafe（用于版本控制）和性能与分析工具。可到这儿察看Visual Studio.NET功能比较：http://msdn.microsoft.com/vstudio/howtobuy/choosing.asp。 运行时支持Windows XP、Windows 2000、NT4 SP6a和Windows ME/98，不支持Windows 95。Framework的某些组成部分，并不是在所有平台上都能工作，比方说，ASP.NET只能运行于Windows XP和Windows 2000上，Windows 98/ME不能用作开发环境。 Windows XP家庭版不支持IIS，因此它不能用来作为ASP.NET的宿主。不过，ASP.NET Web Matrix Web服务器，可以运行于XP家庭版上。 Mono项目试图在Linux上实现.NET Framework。 微软提供了C#、C++、VB和JScript编译器，其它厂商已经宣称它们有意开发针对COBOL、Eiffel、Perl、 Smalltalk 和 Python等语言的.NET编译器。 以下是来自于http://msdn.microsoft.com/net/ecma/的一段话：“2001年12月13日，ECMA会员大会批准C#和通用语言基础设施（CLI）规范成为国际标准。在ECMA标准中，它们的名字将会是ECMA-334 （C#）和ECMA-335 （CLI）。” CLR = Common Language Runtime（通用语言运行时）。CLR是一套标准资源，（理论上）可以被任何.NET程序所利用，而不管使用哪种程序语言。Robert Schmidt（微软）在他的MSDN PDC#文章里，列举了如下CLR资源：
这对于.NET世界来说意味着什么？不同程序语言的能力将比过去任何时候更加趋同，尽管显然并非所有语言都能支持所有CLR服务。 CTS = Common Type System（通用类型系统）。这是.NET运行时能够理解的一大套类型，因此，.NET应用程序就可以使用它们。不过要注意，并不是所有.NET语言都支持CTS中所有类型的。CTS是CLS的一个超集。 CLS = Common Language Specification（通用语言规范）。它是CTS的一个子集，所有.NET语言都将支持它。任何使用CLS兼容的类型的程序，都可以和以任何语言编写的.NET程序进行互操作。 理论上，这允许在不同的.NET语言之间进行非常紧密地互操作。比方说，允许一个C#类从一个VB类继承下来。 IL = Intermediate Language（中间语言）。也称为MSIL（Microsoft Intermediate Language，微软中间语言）或CIL（Common Intermediate Language，通用中间语言）。所有.NET源代码（不管用哪种语言编写）都被编译成IL。当软件被安装时，IL转换为机器码，或在运行时被即时（Just-In-Time，JIT）编译器所处理。 C#是微软设计的一门新语言，用于和.NET framework协作。在它的白皮书《C#介绍》（“Introduction to C#”）中，微软是这么描述C#的： “C#是一门派生于C和C++的简单、现代、面向对象和类型安全的程序语言。C#（发音C sharp）坚实地植身于C和C++语言家族树中，并将很快为C和C++程序员所熟悉。C#目标是将Visual Basic的高生产力和C++的原生威力联合起来。” 把上面一段话中的“C#”用“Java”取而代之，你会发现这个说法依然挺好J 假如你是一名C++程序员，你可能乐意看看我的C# FAQ（英文：http://www.andymcm.com/csharpfaq.htm，中文：http://www.royaloo.com/articles/articles_2002/CSharpFAQ.htm）。 2.6 在.NET环境下，“托管（managed）”一词的含义是？ 术语“托管（managed）”是许多混乱产生的起因，在.NET中，它被用于许多不同的地方，所表达的东西有着细微的差别。 托管代码（Managed code）：.NET framewor为运行在它里面的程序提供了数个核心运行时服务，例如异常处理和安全。为了使这些服务能够运作起来，代码必须向运行时提供最起码的信息，这样的代码被称为托管代码。默认来说，所有C#和Visual Basic.NET代码都是托管的。VS7 C++代码缺省来说不是托管的，但可以通过指定命令行开关（/com+），使编译器生成托管代码。 托管数据（Managed data）：这些数据由.NET运行时垃圾收集器进行配置和清除。C#和VB.NET数据总是托管的，默认来说，VS7 C++数据是非托管的，即使使用/com+开关也是如此，但可以用__gc关键字将其标记为托管的。 托管类（Managed classes）：通常在C++托管扩展（Managed Extensions for C++）背景下谈及这个术语。当使用ME C++时，类别可标以__gc关键字。正如名字所暗示的，这意味着这个类的实体所占用的内存由垃圾收集器托管，但意思还不仅于此。这个类变成了一个完全交付给.NET大家庭的成员，它可享受.NET所带来的好处，同时也受.NET施加的有关制约。关于好处的一个例子是可以和其它语言编写的类很好地互操作，例如，一个managed C++类可以继承自一个VB类。关于约束的一个例子是，托管类只能继承自一个基类。 所有.NET编译器都为它们生成的模块（modules）中所定义的类型产生元数据（metadata），这些元数据和模块打包在一起（模块被打包于配件（assemblies）之中），并可通过反射机制（reflection）存取。System.Reflection名字空间中包含的类，可以用于“查询”模块/配件的类型。 使用反射来存取.NET元数据，非常类似于使用ITypeLib/ITypeInfo存取COM中的类型库数据，并且，它被用于类似的用途，比方说，决定数据类型尺寸，以用于跨越上下文/进程/机器边界列集（marshaling）数据。 反射还可以用于动态调用方法（methods）（参见System.Type.InvokeMember），或在运行时刻动态创建类型（参见System.Reflection.Emit.TypeBuilder）。 配件有时候被描述为一个逻辑.EXE或.DLL，可以是一个应用（application）（具有一个主入口点），也可以是一个库（library）。一个配件由一个或多个文件（dlls、exes以及html 文件等）构成，代表一组资源、类型定义以及对这些类型的实现。一个配件还可以包含对其它配件的引用。这些资源、类型和引用，描述于一个称为清单（manifest）的数据块之中。清单是配件的一个组成部分，从而使得配件具有自描述能力。 关于配件一个重要方面是，它们是类型身份（identity）的一个组成部分。类型的身份是由类型所处的配件和类型名字联合而成，这意味着，假如配件A导出一个叫T的类型，配件B也导出一个叫T的类型，.NET运行时会将它们视作两个完全不同的类型。此外，不要把配件和名字空间混为一谈。名字空间不过是一种用来按层次组织类型名字的方式，对于运行时来说，类型名字就是类型名字，不管用没用名字空间来组织名字。配件加上类型名字（不管这个类型名字是否属于一个名字空间），可向运行时标记一个唯一的类型。 对.NET安全来说，配件也非常重要，许多安全约束被强加于配件边界。 最后，在.NET中，配件是版本协调的单元。下面对此有更多描述。 生成配件最简单的办法是直接利用.NET编译器。例如下面C#程序： public class CTest { public CTest() { System.Console.WriteLine( "Hello from CTest" ); } } 可以这样将它编译成一个库配件（library assembly， dll）： csc /t:library ctest.cs 然后，可以运行“IL反汇编器（IL Disassembler）”来查看配件内容，这个工具是跟随.NET SDK一起分发的。 你也可以将源代码编译成模块（modules），然后使用配件连接器（assembly linker，al.exe）将模块连结成一个配件。对于C#编译器来说，可以使用/target:module开关生成一个模块，而不是生成一个配件。 3.3 私有配件（private assembly）和共享配件（shared assembly）之间有什么区别？ 位置和可见性：一个私有配件通常为单个应用所使用，并且存储于这个应用所在的目录之中，或此目录下面的一个子目录中。共享配件通常存储在全局配件缓存（global assembly cache）之中，这是一个由.NET运行时所维护的配件仓库。共享配件通常是对许多应用都有用的代码库，比如.NET framework类。 版本协调：运行时只对共享配件强加版本约束，对私有配件不起作用。 通过搜索目录路径来彼此发现。有几个因素会影响这个路径（比如应用域宿主（AppDomain host）和应用配置文件）。但对于私有配件来说，搜索路径通常是应用所在目录及其子目录，而对于共享配件来说，搜索路径通常和私有配件路径一样，外加共享配件缓存。 每一个配件都有一个称为兼容性版本的版本号，并且，对一个配件的每一个引用（从另外一个配件中进行引用），既包括被引用配件的名字，也包括版本号。 版本号由四个数字部分组成（例如：5.5.2.33）。前两个数字中，有任意一个不一样的配件，通常就被看作是不兼容的。假如前两个相同，但第三个不同，配件就被认为“可能兼容”。假如只有第四个数字是不一样的，配件就被认为是兼容的。不过，这只是默认的指导方针，是版本策略（version policy）决定了这些规则的强加范围。版本策略可经由应用配置文件来指定。 切记：版本协调只针对共享配件，对私有配件不起作用。 可将应用域想象为轻量级进程。多个应用域可以共存于一个Win32进程之中。应用域的首要用途是为了将应用程序彼此隔离开。 Win32进程通过占有截然不同的内存地址空间而提供隔离机制，这是很管用的，但它代价昂贵而且伸缩性不好。.NET运行时通过保持对内存使用的控制，来强制执行应用域隔离。应用域中的所有内存都由.NET运行时来托管，因此，运行时可以确保一个应用域里的东西不会存取别的应用域的内存。 应用域通常由宿主（hosts）创建。Windows外壳（Windows Shell）、ASP.NET和IE都是宿主的例子。当从命令行运行.NET应用时，宿主就是外壳。外壳为每一个应用创建一个新的应用域。 应用域还可以由.NET应用显式创建。这儿有一个C#例子，它创建了一个AppDomain，后者又创建了一个对象类的实体，然后执行这个对象的一个方法。注意，你必须将这段代码产生的可执行文件命名为appdomaintest.exe，以使其能够如期工作。 using System; using System.Runtime.Remoting; public class CAppDomainInfo : MarshalByRefObject { public string GetAppDomainInfo() { return "AppDomain = " + AppDomain.CurrentDomain.FriendlyName; } } public class App { public static int Main() { AppDomain ad = AppDomain.CreateDomain( "Andy's new domain", null, null ); ObjectHandle oh = ad.CreateInstance( "appdomaintest", "CAppDomainInfo" ); CAppDomainInfo adInfo = (CAppDomainInfo)(oh.Unwrap()); string info = adInfo.GetAppDomainInfo(); Console.WriteLine( "AppDomain info: " + info ); return 0; } } 4.3 我能编写自己的.NET宿主（.NET host）吗？ 垃圾收集是一种由运行时组件负责管理对象生命期以及它们所占用的堆内存（heap memory）的系统。对于.NET来说，这并不是什么新东西，Java以及很多其它语言/运行时使用垃圾收集机制已经有那么一段时间了。 5.2 当对象最后一个引用被解除时，它也并不总是立即被销毁，真的吗？ 没错。对于对象的销毁以及它所占用的内存的回收时机，垃圾收集器没有提供任何担保。 在档案库里有一个有意思的线索，由Chris Sells发起，是关于C#中对象的非确定性销毁的： http://discuss.develop.com/archives/wa.exe?A2=ind0007&L=DOTNET&P=R24819 2000年十月，微软Brian Harry投递了对这个问题的长篇分析： http://discuss.develop.com/archives/wa.exe?A2=ind0010A&L=DOTNET&P=R28572 可在这儿看到Chris Sells对Brian贴子的应答： http://discuss.develop.com/archives/wa.exe?A2=ind0010C&L=DOTNET&P=R983 这要归因于垃圾收集算法。.NET垃圾收集器的工作机理是，周期性地遍历被应用当前引用的所有对象的列表。在这个搜索过程中，凡是没有发现的对象，都将准备予以销毁，它们占用的内存也将被收回。这种算法暗示当对象的最后一个引用也被解除时，运行时并不会立即接到通知，只有下一次对堆（heap）进行清扫时，才能发现这个情况。 进一步而言，执行垃圾收集清扫次数越少，这类算法工作得越好。通常来说，堆的耗尽是收集清扫的触发条件。 当然是个问题，它影响了组件的设计。假如你的对象持有代价昂贵或稀缺的资源（比如数据库锁），你应该提供某种办法，使得客户程序可以在完事时，告诉对象释放掉这些资源。微软建议你提供一个叫Dispose()的方法来达到这个目的。然而，对于分布式对象来说，这将会导致问题。在一个分布式的系统中，谁来调用Dispose()方法？需要有某种形式的引用计数机制或所有权管理机制，来操纵分布式对象，不幸的是，运行时对此没有提供任何帮助。 5.5 非确定性销毁机制对从托管代码（managed code）中使用COM对象有影响吗？ 是的。当在托管代码中使用COM对象时，你大大依赖于垃圾收集器来调用终结方法，以释放你的对象。假如你的COM对象持有一个代价高昂的资源，而它只能在最终释放时得以清除的话，你可能要为你的对象提供一个新的接口，从而支持显式的Dispose()方法。 5.6 我听说应该避免使用Finalize方法，我应该在我的类里实现Finalize方法吗？ 一个具有Finalize方法的对象比没有这个方法的对象更适合于垃圾收集器。不存在关于对象终结顺序的保证，因此，从Finalize方法中去存取别的对象是有问题的。最后，不存在对一个对象调用Finalize方法的任何担保，因此，永远都不应该依赖它来清除对象所占用的资源。 微软推荐如下解决模式： public class CTest : IDisposable { public void Dispose() { ... // Cleanup activities GC.SuppressFinalize(this); } ~CTest() // C# syntax hiding the Finalize() method { Dispose(); } } 通常情况下，客户调用Dispose()，对象的资源得到了释放，垃圾收集器通过调用SuppressFinalize()，以免除履行终结义务。在最坏的情况下，也就是说，在客户忘记调用Dispose()的情况下，就有一个合情合理的机会，通过垃圾收集器对Finalize()的调用，对象的资源将最终得到释放。鉴于垃圾收集算法的局限性，这看起来象是一个相当合理的办法。 一点点。举例来说，System.GC类暴露了一个Collect方法，它强迫垃圾收集器立即去收集所有不再被引用的对象。
序列化是将对象转换为字节流的过程。反序列化是从字节流构建对象的反向过程。序列化/反序列化通常用于对象的传输（比方说，在远程化（remoting）的过程中），或者将对象持久化（比方说，存到文件中或数据库里）。 6.2 .NET Framework 对序列化有内建支持吗？ .NET类库提供了两类独立的机制：XmlSerializer和SoapFormatter/BinaryFormatter。微软将XmlSerializer 用于 Web Services，而将SoapFormatter/BinaryFormatter用于远程化。在你自己的代码里，两个随便你用。 6.3 我想序列化我的类的实体，我应该使用 XmlSerializer、SoapFormatter和BinaryFormatter中的哪一种？ 要视具体情况而定。XmlSerializer有些严格的限制，比方说，要求目标类有一个无参数的构造器，并且，只有公开的读/写属性和字段才可被序列化。不过，从好的一面来说，XmlSerializer对定制XML文档提供了良好支持。XmlSerializer的特性意味着，它最适合于用在跨平台的情况下，或者用于从现有的XML文档构建对象。 SoapFormatter和BinaryFormatter比XmlSerializer的限制要少，比如说，它们可以序列化私有字段。然而，它们都需要目标类标以[Serializable]特性，因此，象XmlSerializer一样，需要小心以序列化方式来编写类。有些诡异的东西也是要小心提防的，比方说，在反序列化时，新对象的构造器并不被调用。 对SoapFormatter和BinaryFormatter的选择，取决于应用。BinaryFormatter对于序列化和反序列化都是发生在.NET平台上并且执行性能很重要的情况大有用处。通常来说，在所有其它情况下，SoapFormatter更有意义，假如没出什么岔子的话，它更易于调试。 可以。XmlSerializer支持很多特性（attributes），它们可以用于为特定的类设定序列化方式。例如，可将某个字段或属性标以[XmlIgnore]特性，从而将其排除在序列化机制之外。另外一个例子是[XmlElement]特性，它可用于指定XML元素名称 — 这个元素名称可被用于特定的属性或字段。 对于经由SoapFormatter/BinaryFormatter的序列化，也可以使用特性进行某种程度的控制。例如，[NonSerialized]特性等价于XmlSerializer的[XmlIgnore]特性。对序列化过程的终极控制，可以通过在其实体打算被序列化的类上，实现ISerializable接口。 XmlSerializer有一个once-per-process-per-type负担。因此，当你在应用中第一次序列化或反序列化一个给定类型的对象时，会感觉到明显的延迟。通常来说，这不是个问题，但这或许意味对于GUI应用启动期间装载配置信息来说，XmlSerializer不是一个好的选择。 6.6为什么当我试图序列化一个散列表（Hashtable）时报错？ XmlSerializer不能用于序列化任何实现了IDictionary接口的类的实体，比方说Hashtable。但SoapFormatter和BinaryFormatter没有这个限制。 6.7 XmlSerializer抛出了一个一般性的错误：“在反射MyClass时出错”，我怎么才能查明出了什么问题？ 可查看抛出异常的InnerException 属性，以获得更详尽的出错消息。 至少有两类.NET特性。第一类我称之为元数据特性（metadata attribute），它允许将一些数据附在类或方法上，这些数据成为类的元数据的一部分，并（象类的其它元数据一样）可以反射（reflection）方式访问。关于元数据特性的例子之一是[serializable]，它可以附加在某个类上，表示这个类的实体可被序列化。 [serializable] public class CTest {} 另外一类是上下文特性（context attribute）。上下文特性和元数据特性使用类似的语法，但它们之间有着根本不同。上下文特性提供了一种截取机制，藉此，实体激活和方法调用就可被早一些或晚一些处理。假如你对Keith Brown的universal delegator印象深刻的话，你应该对这个思想感到熟悉。（译注：可访问http://www.develop.com/kbrown/，以了解关于universal delegator更多信息） 7.2 我可以创建我自己的元数据特性（metadata attributes）吗？ 可以。只需从System.Attribute派生一个类下来，并将其标以AttributeUsage特性即可。例如： [AttributeUsage(AttributeTargets.Class)] public class InspiredByAttribute : System.Attribute { public string InspiredBy; public InspiredByAttribute( string inspiredBy ) { InspiredBy = inspiredBy; } } [InspiredBy("Andy Mc's brilliant .NET FAQ")] class CTest { } class CApp { public static void Main() { object[] atts = typeof(CTest).GetCustomAttributes(true); foreach( object att in atts ) if( att is InspiredByAttribute ) Console.WriteLine( "Class CTest was inspired by {0}", ((InspiredByAttribute)att).InspiredBy ); } } 7.3 我可以创建我自己的上下文特性（context attributes）吗？ 可以。看看Don Box的例子（名叫CallThreshold）： http://www.develop.com/dbox/dotnet/threshold/，以及Peter Drayton 的 Tracehook.NET： http://www.razorsoft.net/。 8. 代码访问安全（Code Access Security） CAS是.NET安全模型的一个组成部分，它决定某段代码是否允许执行，以及它在运行时可以使用什么样的资源。例如，CAS可以防止.NET Web小程序（applet）格式化你的硬盘。 CAS安全策略（policy）围绕两个关键概念：代码组（code groups）和权限（permissions）。每一个.NET配件都是一个特定代码组的成员，每一个代码组都被授予在某个命名权限集（named permission set）里设定的权限。 例如，假如使用默认的安全策略，从某个Web站点上下载的控件属于“Zone – Internet”代码组，这个代码组就具有由“Internet”命名权限集所定义的权限。（自然而然，“Internet”命名权限集代表着一个非常有限的范围的权限） 微软定义了一些默认的代码组，但你可以修改它们，甚至创建你自己的代码组。要想看看机器上定义的代码组，可以命令行方式运行“caspol -lg”。我机器上是这样的： Level = Machine Code Groups: 1. All code: Nothing 1.1. Zone - MyComputer: FullTrust 1.1.1. Honor SkipVerification requests: SkipVerification 1.2. Zone - Intranet: LocalIntranet 1.3. Zone - Internet: Internet 1.4. Zone - Untrusted: Nothing 1.5. Zone - Trusted: Internet 1.6. StrongName - 0024000004800000940000000602000000240000525341310004000003 000000CFCB3291AA715FE99D40D49040336F9056D7886FED46775BC7BB5430BA4444FEF8348EBD06 F962F39776AE4DC3B7B04A7FE6F49F25F740423EBF2C0B89698D8D08AC48D69CED0FC8F83B465E08 07AC11EC1DCC7D054E807A43336DDE408A5393A48556123272CEEEE72F1660B71927D38561AABF5C AC1DF1734633C602F8F2D5: Everything 注意代码组的层次结构。最顶层的是最一般的（“All code”），然后被分成几个子组，每一个子组还可以再细分下去。还要注意的是（这有点违反直觉），子组可以关联有比其父组更放得开的权限集。 使用caspol。例如，假定你信任来自www.mydomain.com的代码，并且，你希望它能够完全访问你的机器，但你又希望对所有其它Internet站点保持默认限制，你就可以在“Zone - Internet”代码组下，加入一个新的子代码组，如下： caspol -ag 1.3 -site www.mydomain.com FullTrust 现在运行caspol –lg，你将会发现新代码组已经被作为组1.3.1而加入： ... 1.3. Zone - Internet: Internet 1.3.1. Site - www.mydomain.com: FullTrust ... 注意，数字标签（1.3.1）只是caspol自己生成的东西，目的是为了易于以命令行方式查看代码组，底层的运行时永远都看不到这些东西。 8.5 我怎么更改代码组的权限集（permission set）？ 使用caspol。假如你是机器的系统管理员的话，你可以在“机器”层进行操作，这意味着你做的更改不但会成为那台机器的默认设置，而且用户也不能够修改放大这些权限。假如你是一个普通用户（（不是系统管理员）），你仍然可以修改权限，但只能将权限缩小。例如，为了让Intranet代码能够做它想做的事，你可以这么做。 caspol -cg 1.2 FullTrust 注意，因为这比默认策略（在一个标准系统之中）的权限来得大，你只能在机器层做这个修改，在用户层做这样的修改没什么效果。 可以。使用caspol –ap，定义一个XML文件，它包含有权限集中所要包含的权限。为了节省你一点时间，这儿（http://www.eponymous.eclipse.co.uk/samplepermset.xml）有一个相应于“Everything”权限集的样例文件，你可以修改它以满足你的需要。改好以后，可以这样将它加入到可用的权限集之中： caspol -ap samplepermset.xml 接下来，为了将这个权限集施加于某个代码组上，可以这么做： caspol -cg 1.3 SamplePermSet （默认来说，1.3是“Internet”代码组） 8.7 我遇到了一些CAS麻烦，我如何才能诊断是什么地方出了差错？ Caspol有一些选项可能会派上用场。首先，你可以使用caspol –rsg，叫caspol告诉你配件所属的代码组是什么。同样地，你也可以使用caspol –rsg，来查询是什么样的权限施加于指定的配件之上了。 可以，只要你是一名系统管理员的话。运行caspol -s off 即可。 9. 中间语言（Intermediate Language，IL） 可以。微软提供了一个叫作Ildasm的工具，可以用于查看配件的IL和元数据。 9.2能从IL“反向工程”（reverse-engineered）出源代码来吗？ 可以。通常来说，从IL重新生成高级源码（比如C#）是相当容易的。 目前还没有什么简单的办法来阻止从IL“反向工程”出代码。将来或许可以利用一些IL混淆工具（IL obfuscation tools），它们可能来自微软，也可能来自第三方厂商。这些工具通过对IL进行特殊处理，使得“反向工程”变得大大困难。 当然，假如你编写web services的话，“反向工程”就不是个问题了，因为客户无法直接访问你的IL。 可以。Peter Drayton向DOTNET邮件列表中投递了这个简单的例子： .assembly MyAssembly {} .class MyApp { .method static void Main() { .entrypoint ldstr "Hello, IL!" call void System.Console::WriteLine(class System.Object) ret } } 将这段代码拷贝到一个叫hello.il的文件中，然后运行ilasm hello.il，将会生成一个exe形式的配件。 可以。举两个简单的例子：在IL中，你可以抛出不是从System.Exception派生出来的异常，你还可以使用下标不是从0开始的数组。 这个话题招致了大量的争论，假如你阅读了邮件列表档案资料你就知道了。看看下面这两条线索： http://discuss.develop.com/archives/wa.exe?A2=ind0007&L=DOTNET&D=0&P=68241 http://discuss.develop.com/archives/wa.exe?A2=ind0007&L=DOTNET&P=R60761 我是这么看的：COM内容丰富，对于不同的人它代表着不同的东西，但对我而言，COM从根本上来说，是小块代码之间如何彼此发现并相互通讯的机制。COM精确规定了如何定位和通讯。在一个纯粹的.NET世界里，一切全由.NET对象构成，小块代码仍然需要彼此发现和交流，但它们并非使用COM手段。它们使用一种从某些方面来说类似于COM的模型，比如以表格形式同组件一起打包存储的类型信息，非常类似于和COM组件一起打包存储的类型库信息，但它并非COM。 那么，这有什么要紧的吗？唔，我真的不关心大多数COM东西渐渐离去。我不会在意不需要跑到注册表里转一圈的组件查找方式，我也不在乎不使用IDL来定义我的接口。但是，有一件事情我不会放弃：我不想丢掉基于接口的开发思想。在我看来，COM最伟大的力量，就是它对接口和实现之间进行分离的铸铁般地坚持。不幸的是，.NET framework看来并没有如此坚持，它让你能够做基于接口的开发，但它并未坚持非这样不可。有人可能会争论多一种选择从来都不是一件坏事，或许他们是对的，但我无法不想像这可能是一个退步。 对于.NET开发人员来说，它已经濒临死亡了。.NET Framework 提供了一个不是基于DCOM的新的远程化模型，当然了，在互操作的情形下，还会用到DCOM的。 不然。第一版的.NET提供了对现有COM+服务的访问（通过一个互操作层），而不是使用一个本地.NET服务来取代它。有一些五花八门的工具和功能以试图使这种访问尽可能少一些苦痛。职业开发人员大会上发送的.NET SDK，包括对COM+核心服务的互操作支持（比如JIT激活、事务等），但尚未提供对某些更高层服务（例如COM+事件、队列组件等）的支持。 随着时间的推移，我们期望互操作能够变得更加无缝，这或许意味着某些服务将成为CLR的核心组成部分，并且（或者）这意味着某些服务将会以托管代码重写，以运行于CLR之上。 关于这个主题的更多讨论，可以到档案中心搜索Joe Long的帖子。Joe是微软COM+团队项目经理。可从下面这条消息开始： http://discuss.develop.com/archives/wa.exe?A2=ind0007&L=DOTNET&P=R68370。 可以。在.NET运行时中，可以经由运行时可调用包装器（Runtime Callable Wrapper，RCW）来访问COM组件。这个包装器将COM组件暴露的COM接口转换为.NET兼容的接口。对于OLE自动化接口而言，RCW可以从类型库自动生成。对于非OLE自动化接口来说，可能需要开发一个定制的RCW，以将COM接口暴露的类型以手工方式映射到.NET兼容的类型。 对于那些熟悉ATL的开发人员来说，这儿有一个简单例子。首先，创建一个实现了如下IDL的ATL组件： import "oaidl.idl"; import "ocidl.idl"; [ object, uuid(EA013F93-487A-4403-86EC-FD9FEE5E6206), helpstring("ICppName Interface"), pointer_default(unique), oleautomation ] interface ICppName : IUnknown { [helpstring("method SetName")] HRESULT SetName([in] BSTR name); [helpstring("method GetName")] HRESULT GetName([out,retval] BSTR *pName ); }; [ uuid(F5E4C61D-D93A-4295-A4B4-2453D4A4484D), version(1.0), helpstring("cppcomserver 1.0 Type Library") ] library CPPCOMSERVERLib { importlib("stdole32.tlb"); importlib("stdole2.tlb"); [ uuid(600CE6D9-5ED7-4B4D-BB49-E8D5D5096F70), helpstring("CppName Class") ] coclass CppName { [default] interface ICppName; }; }; 一旦创建好组件，你应该能够得到一个类型库，对这个类型库运行TLBIMP工具，如下： tlbimp cppcomserver.tlb 假如成功的话，你会看到如下消息： Typelib imported successfully to CPPCOMSERVERLib.dll 现在，你需要一个.NET客户程序，让我们使用C#来编写。创建一个包含有如下代码的.cs文件： using System; using CPPCOMSERVERLib; public class MainApp { static public void Main() { CppName cppname = new CppName(); cppname.SetName( "bob" ); Console.WriteLine( "Name is " + cppname.GetName() ); } } 注意，我们使用类型库的名字作为名字空间，并以COM类的名字作为类的名字。作为代替，我们也可以使用CPPCOMSERVERLib.CppName作为类的名字，并且不使用using CPPCOMSERVERLib语句。 可以这样编译这些C#代码： csc /r:cppcomserverlib.dll csharpcomclient.cs 注意，编译器被告知去引用我们先前使用TLBIMP从类型库生成的DLL。 现在应该可以运行csharpcomclient.exe，并在控制台上得到如下输出： Name is bob 可以。在COM中，可以经由COM可调用包装器（COM Callable Wrapper，CCW）来访问.NET组件。这类似于RCW（参见上一个问题），但作用相反。再一次，假如包装器不能由.NET开发工具自动生成，或者自动的生成行为不是你想要的，那你自己可以定制一个CCW。还有，要想让COM能够“看到”.NET组件，必须将.NET组件注册到注册表中。 这儿有一个简单的例子。先创建一个名为testcomserver.cs的C#文件，把下面代码放进去： using System; namespace AndyMc { public class CSharpCOMServer { public CSharpCOMServer() {} public void SetName( string name ) { m_name = name; } public string GetName() { return m_name; } private string m_name; } } 然后这么来编译这个.cs文件： csc /target:library testcomserver.cs 你应该能够得到一个dll，可以这样注册它： regasm testcomserver.dll /tlb:testcomserver.tlb /codebase 现在，需要创建一个客户程序来测试你的.NET COM组件，VBScript就可以。把下面代码放入一个叫comclient.vbs的文件中： Dim dotNetObj Set dotNetObj = CreateObject("AndyMc.CSharpCOMServer") dotNetObj.SetName ("bob") MsgBox "Name is " & dotNetObj.GetName() 然后，这么来执行这段脚本： wscript comclient.vbs 你应该马上就能看到一个消息框，上面写着“Name is bob”。 一个替代办法是使用由Jason Whittington 和 Don Box开发的dm.net moniker，可以到这儿看看：http://staff.develop.com/jasonw/clr/readme.htm 没错，假如你在编写运行于.NET framework里的应用的话。当然，有很多开发人员可能希望继续使用ATL来编写运行于framework之外的C++ COM组件，但是，假如你在framework之内的话，你将几乎可以肯定想使用C#。原生的C++（ATL的基础）在.NET世界中并没有太多的位置，它太接近于底层并且提供了太多的弹性，.NET运行时难以管制它。 11.1 .NET remoting（远程化）的工作机理是怎样的？ .NET remoting涉及沿着通道（channels）发送消息。有HTTP和TCP两个标准通道。TCP通道目的仅仅是为了用于局域网（LANs），而HTTP通道既可以用于局域网，也可以用于广域网（WANs，Internet）。 提供了多种消息序列化格式支持，例如SOAP格式（基于XML）和二进制格式。默认来说，HTTP通道使用SOAP格式（经由.NET运行时序列化SOAP格式器（Serialization SOAP Formatter）），TCP通道使用二进制方式（经由.NET运行时序列化二进制格式器（Serialization Binary Formatter）），其实两种通道都可以使用任一种序列化格式。 有如下一些远程存取风格： SingleCall：来自� |