)

代码讨论

　　要启动此函数，请创建一个包含 5 个项目的线程数组。此数组将保持对所有线程的引用，以备将来使用。

　　MQListen 类的构造函数使用两个参数：包含消息队列的计算机名以及要侦听的队列的名称。构造函数使用文本框中的值来为这两个参数赋值。

　　要创建线程，您需要进入循环以初始化每个线程对象。Thread 构造函数要求您向其传递一个委托，该委托在调用线程的 Start 方法时指向要调用的函数。您希望线程开始使用 MQListen.Listen 函数，但该线程并不是一个委托。为了满足线程构造函数的要求，您必须传递一个 ThreadStart 对象，该对象将创建一个给定函数名称的委托。此时，请向 ThreadStart 对象传递一个对 MQListen.Listen 函数的引用。由于该数组元素已被初始化，请立即调用 Start 来开始线程。

　　所有线程开始后，请用相应的消息来更新窗体中的状态栏。随着线程的运行和侦听队列，主线程将等待用户请求应用程序停止侦听。为此，主线程将进入一个 while 循环，直至您单击 StopListening 按钮更改 StopListeningFlag 的值。在此等待循环中，将允许应用程序使用 Forms.Application.DoEvents 方法处理其他需要处理的工作。对于熟悉 Visual Basic 的读者来说，这一点与旧的 DoEvents 方法相同。对于熟悉 C++ 的读者来说，这等于编写一个 MSG 泵。

　　当用户单击 StopListening 按钮时，该循环将退出并进入线程关闭代码。要关闭所有线程，代码必须检查线程数组，并向每个线程发送一个中断信号。在此循环内部，请对数组中的每个线程调用 Interrupt 方法。调用此方法之前，MQListen 类中的代码将继续正常执行。因此，您可以对每个辅助线程调用 Interrupt ，而不必考虑线程是否正在处理其他事件。完成后，线程类将处理所有线程的清除。最后，请在退出前更新主窗体中的状态栏。

　　现在，您需要在按钮后添加代码。请向 StartListening 按钮的 Click 事件添加以下代码：

　　// C#

　　statusBar1.Text = "Starting Threads";

　　StartThreads();

　　这将更新状态栏并调用 StartThreads 方法。对于 StopListening 按钮，您只需使用以下代码将 StopListeningFlag 设置为 True ：

　　// C#

　　StopListeningFlag = true;

　　 最后一步是为 StopListeningFlag 添加窗体级的变量。请在窗体代码的顶部添加以下行：

　　// C#

　　private bool StopListeningFlag = false;

　　要测试应用程序，您可以下载 MQWrite，这是一个写入消息队列的示例应用程序。

　　多线程代码问题

　　您已经完成了示例代码，因此您已经具备编写自己的多线程应用程序所需的工具。线程可以显著提高某些应用程序的性能和可伸缩性。在功能增强的同时，您还必须了解线程有危险的一面。使用线程可能会破坏您的应用程序，这样的情况确实存在。线程可能会阻止运行，造成无法预料的后果，甚至会导致应用程序停止运行。

　　如果您有多个线程，请确保它们之间不存在互相等待以到达某一点或完成的情况。如果操作错误，可能会导致死锁状态，两个线程都无法完成，因为它们都在相互等待。

　　如果多线程要求访问不能轻易共享的资源（如软盘驱动器、串行端口或红外线端口），您可能需要避免使用线程或需要使用一种更高级的线程工具（如 synclocks 或 mutexes）来管理并发性。如果两个线程试图同时访问这些资源，其中一个线程将无法获得资源，或者会导致数据损坏。

　　使用线程的另一个常见问题是竞争状态。如果一个线程正在将数据写入文件，而另一个线程正在从该文件中读取数据，您将无法知道哪个线程先完成。这种情况称为竞争状态，因为两个线程都在竞相到达文件末尾。如果读取线程快于写入线程，则将返回无法预料的结果。

　　使用线程时，还应当考虑所有线程是否都能够完全独立地进行工作。如果确实需要来回传递数据，在数据相对简单的情况下，只要小心操作即可。传递复杂对象时，来回移动这些对象的封送代价将十分可观。这将导致操作系统管理的额外开销并且会降低总体性能。

　　另一个问题是将代码转交给其他开发人员的传递成本。虽然 .NET 确实使线程变得容易，但请注意，维护您代码的下一位开发人员必须了解要使用的线程。尽管这不是避免使用线程的理由，但是它充分说明了应该提供足够的代码注释。

　　这些问题本身并不能打消您使用线程的热情，但您在设计应用程序和决定是否使用线程时应该考虑到这些问题。遗憾的是，本文无法详细论述某些避免这些问题的方法。如果您已决定使用线程但遇到了上述某些问题，请检查 synclocks 或 mutexes 看是否能解决问题或引导您使用其他解决方案。

　　总结

　　有了上述信息，您就可以编写使用线程的应用程序。不过，在编写过程中，请记住上面提到的问题。如果使用得当，那么，与单线程相比，多线程应用程序将具有更好的性能和可伸缩性。但是，如果使用不当，使用线程会适得其反，并且会导致应用程序不稳定。

代码讨论

　　MQListen 类包含一个不同于构造函数的函数。该函数封装每个辅助线程要执行的所有工作。在主线程中，您向线程构造函数传递一个对此函数的引用，以便在启动线程时执行该函数。

　　Listen 所做的第一件事情是设置一个消息队列对象。 MessageQueue 构造函数通过三种实现进行重载。第一种实现使用两个参数：一个字符串参数，指定侦听队列的位置；一个布尔值参数，指示是否为访问队列的第一个应用程序赋予独占读取队列的权限。第二种实现只使用队列路径参数，第三种实现不使用参数。为了简便起见，您可以使用第三种实现，在下一行分配路径。

　　如果您引用了队列，则必须创建一个消息对象。消息构造函数也有三种实现方式。如果您想将消息写入队列，则可以使用前两种实现。这两种实现采用两个对象：一个是位于消息正文中的对象；一个是定义如何将对象序列化到消息正文的 IMessageFormatter 对象。在本例中，您将从队列中读取数据，以初始化空的消息对象。

　　初始化对象后，您需要输入执行所有工作的主循环。然后，当主线程调用 Interrupt 终止这些线程时，则只有在线程处于等待、睡眠或连接状态下才会被中断。如果没有处于上述三种状态，则要等到下次进入这三种状态中的一种时才会被中断。要确保辅助线程进入等待、睡眠或连接状态，请调用位于 System.Threading 名称空间的 Sleep 方法。对于使用过 Windows API 睡眠函数的 C++ 和 Visual Basic 开发人员而言， Sleep 方法并不陌生。它只使用一个参数：线程处于睡眠状态的毫秒数。如果您从未调用过 Sleep ，辅助线程将永远不会进入可以接收中断请求的状态，而会无限制地继续下去，除非您手动关闭进程。

　　MQ Receive 方法有两种实现。第一种实现不使用参数，将一直等待接收消息。第二种实现（本例使用这种实现）使用 TimeSpan 对象指定一个超时值。 TimeSpan 构造函数包含四个参数：日、小时、分钟和秒。在本例中， Receive 方法在超时和返回前将等待一秒种。

　　收到的消息将被分配给先前创建的消息对象，然后，便可以对其进行处理了。本例打开一个带有标签的消息框，并删除了此消息。如果您想在实际使用中采用此代码，则可以在此处放置任何消息处理代码。

　　当辅助线程收到 Interrupt 请求后，将发出一个 ThreadInterruptedException 异常。要捕捉此异常，请在 try-catch 块中包含 Sleep 和 Receive 函数。您应当指定两个捕获：第一个用于捕获中断异常，第二个用于处理捕获到的错误异常。捕获到中断异常时，请首先将其写入线程正在退出的调试窗口。下一步，对队列对象和消息对象调用 Dispose 方法，以保证所有内存都被清空并发送到内存回收器。最后，中断 while 循环。

　　函数退出 while 循环后，关联的线程也将立即结束，代码为 0。在调试窗口，您将看到一则消息，例如“The thread ' ' (0x660) has exited with code 0 (0x0)”（线程 ' ' (0x660) 已经退出，代码为 0 (0x0)）。现在，线程已经退出该环境，并已自动被破坏。主线程和辅助线程都不需要执行专门的清除操作。
　　主窗体

　　下一步是向窗体添加代码以生成辅助线程并针对各辅助线程启动 MQListen 类。首先，请向窗体添加下列函数：

// C# private void StartThreads() { int LoopCounter; // 线程计数 StopListeningFlag = false; // 跟踪辅助线程是否应当 // 终止的标志。 // 将一个包含 5 个线程的数组声明为辅助线程。 Thread[] ThreadArray = new Thread[5]; // 声明包含辅助线程的所有代码的类。 MQListen objMQListen = new MQListen(this.ServerName.Text,this.QueueName.Text); for (LoopCounter = 0; LoopCounter < NUMBER_THREADS; LoopCounter++) { // 创建一个 Thread 对象。 ThreadArray[LoopCounter] = new Thread(new ThreadStart(objMQListen.Listen)); // 启动线程将调用 ThreadStart 委托。 ThreadArray[LoopCounter].Start(); } statusBar1.Text = LoopCounter.ToString() + " listener threads started"; while (!StopListeningFlag) { // 等待用户按下停止按钮。 // 在等待过程中，让系统处理其他事件。 System.Windows.Forms.Application.DoEvents(); } statusBar1.Text = "Stop request received, stopping threads"; // 向每个线程发送一个中断请求。 for (LoopCounter = 0;LoopCounter < NUMBER_THREADS; LoopCounter++) { ThreadArray[LoopCounter].Interrupt(); } statusBar1.Text = "All Threads have been stopped"; }

使用线程模式

　　为了使您对线程模式有一定的概念，我们可以将其想象为从一所屋子搬到另一所屋子。如果您采用单线程方法，则需要您自己完成从打包到扛箱子再到拆包的所有工作。如果您使用单元线程模式，则表示您邀请了好朋友来帮忙。每个朋友在一个单独的房间里工作，并且不能帮助在其他房间工作的人。他们各自负责自己的空间和空间内的物品搬运。如果您采用自由线程方法，您仍然邀请相同的朋友来帮忙，但是所有朋友可以随时在任何一个房间工作，共同打包物品。与此类似，您的房子就是运行所有线程的进程，每个朋友都是一个代码实例，搬运的物品为应用程序的资源和变量。

　　本示例解释了不同线程模式的优点和缺点。单元线程比单线程要快，因为有多个组件实例在工作。在某些情况下，自由线程比单元线程更快更有效，这是因为所有事情同时发生，并且可以共享所有资源。但是，当多线程更改共享资源时，这可能会出现问题。假设一个人开始使用箱子打包厨房用具，此时另一个朋友进来了，要使用同一个箱子打包浴室的东西。第一个朋友在箱子上贴上了“厨房用具”，另一个朋友用“洗漱用品”标签覆盖了原标签。结果，当您拆包时，就会发生将厨房用品搬到浴室的情况。
　　示例应用程序

　　第一步是要检查示例应用程序的设计。应用程序将生成多个线程，每个线程都侦听来自 MSMQ 队列的消息。本示例使用两个类，主 Form 类和自定义 MQListen 类。 Form 类将处理用户界面并创建，管理和破坏辅助线程。MQListen 类包含所有代码，包括辅助线程运行所需的消息队列因素。

　　准备应用程序

• 要启动应用程序，请打开 Visual Studio .NET 并创建一个名为 MultiThreadedMQListener 的新 C# Windows 应用程序。打开窗体的属性，将其命名为 QueueListenerForm。画出初始窗体后，将两个标签、两个按钮、一个状态栏和两个文本框拖放到窗体上。将第一个文本框命名为 Server ，第二个文本框命名为 Queue 。将第一个按钮命名为 StartListening ，第二个按钮命名为 StopListening 。可以保留状态栏的默认名称 statusBar1 。
• 下一步，单击 Project （项目）菜单并单击 Add Reference （添加引用），以向 System.Messaging 名称空间添加一个引用。在 .NET 组件列表中找到并选择 System.Messaging . Dll 。名称空间包含与 MSMQ 队列通信所使用的类。
• 下一步，单击 File （文件）菜单，然后单击 Add New Item （添加新项），以在项目中添加一个新类。选择 Class （类）模板并将其命名为 MQListen。在类的顶部添加下列 using 语句：

  // C#
  using System.Threading;
  using System.Messaging;

  System.Threading 名称空间允许您访问所有必要的线程功能，在本例中，您可以访问 Thread 类和 ThreadInterruptException 构造函数。该名称空间还包括许多其他高级功能，本文不作详细讨论。 System.Messaging 名称空间允许您访问 MSMQ 功能，包括向队列发送消息和接收队列消息。在本例中，您将使用 MessageQueue 类来接收消息。还必须在主窗体代码中添加 using System.Threading。

　　所有引用就位后，您就可以开始编写代码了

辅助线程

　　首先需要构建封装所有线程工作的 MQListen 类。将下列代码插入 MQListen 中。

// C# public class MQListen { private string m_MachineName; private string m_QueueName; // 构造函数接收必要的队列信息。 public MQListen(string MachineName, string QueueName) { m_MachineName = MachineName; m_QueueName = QueueName; } // 每个线程用来侦听 MQ 消息的一种唯一方法 public void Listen() { // 创建一个 MessageQueue 对象。 System.Messaging.MessageQueue MQ = new System.Messaging.MessageQueue(); // 设置 MessageQueue 对象的路径属性。 MQ.Path = m_MachineName + "\private$\" + m_QueueName; // 创建一个 Message 对象。 System.Messaging.Message Message = new System.Messaging.Message(); // 重复上述步骤，直到收到中断。 while (true) { try { // 休眠以在中断发出时捕捉中断。 System.Threading.Thread.Sleep(100); // 将 Message 对象设置为与接收函数的结果相等。 // 持续时间（天、小时、分钟、秒）。 Message = MQ.Receive(new TimeSpan(0, 0, 0, 1)); // 显示已接收消息的标签 System.Windows.Forms.MessageBox.Show(" Label: " + Message.Label); } catch (ThreadInterruptedException e) { // 从主线程捕捉 ThreadInterrupt 并退出。 Console.WriteLine("Exiting Thread"); Message.Dispose(); MQ.Dispose(); break; } catch (Exception GenericException) { // 捕捉接收过程中抛出的所有异常。 Console.WriteLine(GenericException.Message); } } } }

摘要： 本文论述了各种模式的线程（单线程、单元线程和自由线程）以及每种模式的使用方法。同时，还提供了一个使用线程的 C# 语言代码示例，以帮助您编写使用线程的应用程序。本文还讨论了多线程代码中的一些重要问题。

　　简介

　　编写多线程 Microsoft® 消息队列 (MSMQ) 触发器应用程序向来是一件让人畏惧的事情。不过，.NET 框架线程和消息类的出现使这项工作变得比以前容易了。这些类允许您使用任何适用于 .NET 框架的语言来编写多线程应用程序。以前，像 Microsoft Visual Basic® 之类的工具对线程的支持十分有限。因此不得不使用 C++ 来编写多线程代码，通过 Visual Basic 构建由多个过程或 ActiveX DLL 组成的解决方案（这种解决方案一点也不理想），或者干脆完全放弃多线程。使用 .NET 框架，您可以构建各种多线程应用程序，而不用考虑选择使用哪种语言。

　　本文将逐步介绍构建侦听并处理来自 Microsoft 消息队列的多线程应用程序的过程。本文将着重讨论两个名称空间 System.Threading 和 System.Messaging 。示例代码是用 C# 语言编写的，但您可以轻松地将其转换为您所使用的语言。

　　线程背景

　　在 Win32 环境中，线程有三种基本模式：单线程、单元线程和自由线程。

　　单线程

　　您最初编写的某些应用程序很可能是单线程应用程序，仅包含与应用程序进程对应的线程。进程可以被定义为应用程序的实例，拥有该应用程序的内存空间。大多数 Windows 应用程序都是单线程的，即用一个线程完成所有工作。

　　单元线程

　　单元线程是一种稍微复杂的线程模式。标记用于单元线程的代码可以在其自己的线程中执行，并限制在自己的单元中。线程可以被定义为进程所拥有的实体。处理时将调度该进程。在单元线程模式中，所有线程都在主应用程序内存中各自的子段范围内运行。此模式允许多个代码实例同时但独立地运行。例如，在 .NET 之前，Visual Basic 仅限于创建单元线程组件和应用程序。

　　自由线程

　　自由线程是最复杂的线程模式。在自由线程模式中，多个线程可以同时调用相同的方法和组件。与单元线程不同，自由线程不会被限制在独立的内存空间。当应用程序必须进行大量相似而又独立的数学计算时，您可能需要使用自由线程。在这种情况下，您需要生成多个线程使用相同的代码示例来执行计算。可能 C++ 开发人员是仅有的编写过自由线程应用程序的应用程序开发人员，因为像 Visual Basic 6.0 这样的语言几乎不可能编写自由线程应用程序。

具有内嵌字符数组的结构

某些函数接受具有内嵌字符数组的结构。例如，GetTimeZoneInformation() 函数接受指向以下结构的指针：

typedef struct _TIME_ZONE_INFORMATION {     LONG       Bias;     WCHAR      StandardName[ 32 ];     SYSTEMTIME StandardDate;     LONG       StandardBias;     WCHAR      DaylightName[ 32 ];     SYSTEMTIME DaylightDate;     LONG       DaylightBias; } TIME_ZONE_INFORMATION, *PTIME_ZONE_INFORMATION;

在 C# 中使用它需要有两种结构。一种是 SYSTEMTIME，它的设置很简单：

   struct SystemTime   {      public short wYear;      public short wMonth;      public short wDayOfWeek;      public short wDay;      public short wHour;      public short wMinute;      public short wSecond;      public short wMilliseconds;   }

这里没有什么特别之处；另一种是 TimeZoneInformation，它的定义要复杂一些：

[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]struct TimeZoneInformation{    public int bias;   [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 32)]   public string standardName;   SystemTime standardDate;   public int standardBias;   [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 32)]   public string daylightName;   SystemTime daylightDate;   public int daylightBias;}

此定义有两个重要的细节。第一个是 MarshalAs 属性：

   [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 32)]

查看 ByValTStr 的文档，我们发现该属性用于内嵌的字符数组；另一个是 SizeConst，它用于设置数组的大小。

我在第一次编写这段代码时，遇到了执行引擎错误。通常这意味着部分互操作覆盖了某些内存，表明结构的大小存在错误。我使用 Marshal.SizeOf() 来获取所使用的封送拆收器的大小，结果是 108 字节。我进一步进行了调查，很快回忆起用于互操作的默认字符类型是 Ansi 或单字节。而函数定义中的字符类型为 WCHAR，是双字节，因此导致了这一问题。

我通过添加 StructLayout 属性进行了更正。结构在默认情况下按顺序布局，这意味着所有字段都将以它们列出的顺序排列。CharSet 的值被设置为 Unicode，以便始终使用正确的字符类型。

经过这样处理后，该函数一切正常。您可能想知道我为什么不在此函数中使用 CharSet.Auto。这是因为，它也没有 A 和 W 变体，而始终使用 Unicode 字符串，因此我采用了上述方法编码。

具有回调的函数

当 Win32 函数需要返回多项数据时，通常都是通过回调机制来实现的。开发人员将函数指针传递给函数，然后针对每一项调用开发人员的函数。

在 C# 中没有函数指针，而是使用“委托”，在调用 Win32 函数时使用委托来代替函数指针。

EnumDesktops() 函数就是这类函数的一个示例：

BOOL EnumDesktops(  HWINSTA hwinsta,            // 窗口实例的句柄  DESKTOPENUMPROC lpEnumFunc, // 回调函数  LPARAM lParam               // 用于回调函数的值);

HWINSTA 类型由 IntPtr 代替，而 LPARAM 由 int 代替。DESKTOPENUMPROC 所需的工作要多一些。下面是 MSDN 中的定义：

BOOL CALLBACK EnumDesktopProc(  LPTSTR lpszDesktop,  // 桌面名称  LPARAM lParam        // 用户定义的值);

我们可以将它转换为以下委托：

delegate bool EnumDesktopProc(   [MarshalAs(UnmanagedType.LPTStr)]   string desktopName,   int lParam);

完成该定义后，我们可以为 EnumDesktops() 编写以下定义：

[DllImport("user32.dll", CharSet = CharSet.Auto)]static extern bool EnumDesktops(   IntPtr windowStation,   EnumDesktopProc callback,   int lParam);

这样该函数就可以正常运行了。

在互操作中使用委托时有个很重要的技巧：封送拆收器创建了指向委托的函数指针，该函数指针被传递给非托管函数。但是，封送拆收器无法确定非托管函数要使用函数指针做些什么，因此它假定函数指针只需在调用该函数时有效即可。

结果是如果您调用诸如 SetConsoleCtrlHandler() 这样的函数，其中的函数指针将被保存以便将来使用，您就需要确保在您的代码中引用委托。如果不这样做，函数可能表面上能执行，但在将来的内存回收处理中会删除委托，并且会出现错误。

其他高级函数

迄今为止我列出的示例都比较简单，但是还有很多更复杂的 Win32 函数。下面是一个示例：

DWORD SetEntriesInAcl(  ULONG cCountOfExplicitEntries,           // 项数  PEXPLICIT_ACCESS pListOfExplicitEntries, // 缓冲区  PACL OldAcl,                             // 原始 ACL  PACL *NewAcl                             // 新 ACL);

前两个参数的处理比较简单：ulong 很简单，并且可以使用 UnmanagedType.LPArray 来封送缓冲区。

但第三和第四个参数有一些问题。问题在于定义 ACL 的方式。ACL 结构仅定义了 ACL 标头，而缓冲区的其余部分由 ACE 组成。ACE 可以具有多种不同类型，并且这些不同类型的 ACE 的长度也不同。

如果您愿意为所有缓冲区分配空间，并且愿意使用不太安全的代码，则可以用 C# 进行处理。但工作量很大，并且程序非常难调试。而使用 C++ 处理此 API 就容易得多。

属性的其他选项

DLLImport 和 StructLayout 属性具有一些非常有用的选项，有助于 P/Invoke 的使用。下面列出了所有这些选项：

DLLImport

CallingConvention

您可以用它来告诉封送拆收器，函数使用了哪些调用约定。您可以将它设置为您的函数的调用约定。通常，如果此设置错误，代码将不能执行。但是，如果您的函数是 Cdecl 函数，并且使用 StdCall（默认）来调用该函数，那么函数能够执行，但函数参数不会从堆栈中删除，这会导致堆栈被填满。

CharSet

控制调用 A 变体还是调用 W 变体。

EntryPoint

此属性用于设置封送拆收器在 DLL 中查找的名称。设置此属性后，您可以将 C# 函数重新命名为任何名称。

ExactSpelling

将此属性设置为 true，封送拆收器将关闭 A 和 W 的查找特性。

PreserveSig

COM 互操作使得具有最终输出参数的函数看起来是由它返回的该值。此属性用于关闭这一特性。

SetLastError

确保调用 Win32 API SetLastError()，以便您找出发生的错误。

StructLayout

LayoutKind

结构在默认情况下按顺序布局，并且在多数情况下都适用。如果需要完全控制结构成员所放置的位置，可以使用 LayoutKind.Explicit，然后为每个结构成员添加 FieldOffset 属性。当您需要创建 union 时，通常需要这样做。

CharSet

控制 ByValTStr 成员的默认字符类型。

Pack

设置结构的压缩大小。它控制结构的排列方式。如果 C 结构采用了其他压缩方式，您可能需要设置此属性。

Size

设置结构大小。不常用；但是如果需要在结构末尾分配额外的空间，则可能会用到此属性。

从不同位置加载

您无法指定希望 DLLImport 在运行时从何处查找文件，但是可以利用一个技巧来达到这一目的。

DllImport 调用 LoadLibrary() 来完成它的工作。如果进程中已经加载了特定的 DLL，那么即使指定的加载路径不同，LoadLibrary() 也会成功。

这意味着如果直接调用 LoadLibrary()，您就可以从任何位置加载 DLL，然后 DllImport LoadLibrary() 将使用该 DLL。

由于这种行为，我们可以提前调用 LoadLibrary()，从而将您的调用指向其他 DLL。如果您在编写库，可以通过调用 GetModuleHandle() 来防止出现这种情况，以确保在首次调用 P/Invoke 之前没有加载该库。

P/Invoke 疑难解答

如果您的 P/Invoke 调用失败，通常是因为某些类型的定义不正确。以下是几个常见问题：

• long != long。在 C++ 中，long 是 4 字节的整数，但在 C# 中，它是 8 字节的整数。
• 字符串类型设置不正确。

简单字符串

下面是一个接受字符串参数的函数的简单示例：

BOOL GetDiskFreeSpace(  LPCTSTR lpRootPathName,          // 根路径  LPDWORD lpSectorsPerCluster,     // 每个簇的扇区数  LPDWORD lpBytesPerSector,        // 每个扇区的字节数  LPDWORD lpNumberOfFreeClusters,  // 可用的扇区数  LPDWORD lpTotalNumberOfClusters  // 扇区总数);

根路径定义为 LPCTSTR。这是独立于平台的字符串指针。

由于不存在名为 GetDiskFreeSpace() 的函数，封送拆收器将自动查找“A”或“W”变体，并调用相应的函数。我们使用一个属性来告诉封送拆收器，API 所要求的字符串类型。

以下是该函数的完整定义，就象我开始定义的那样：

[DllImport("kernel32.dll")]static extern bool GetDiskFreeSpace(   [MarshalAs(UnmanagedType.LPTStr)]   string rootPathName,   ref int sectorsPerCluster,   ref int bytesPerSector,   ref int numberOfFreeClusters,   ref int totalNumberOfClusters);

不幸的是，当我试图运行时，该函数不能执行。问题在于，无论我们在哪个平台上，封送拆收器在默认情况下都试图查找 API 的 Ansi 版本，由于 LPTStr 意味着在 Windows NT 平台上会使用 Unicode 字符串，因此试图用 Unicode 字符串来调用 Ansi 函数就会失败。

有两种方法可以解决这个问题：一种简单的方法是删除 MarshalAs 属性。如果这样做，将始终调用该函数的 A 版本，如果在您所涉及的所有平台上都有这种版本，这是个很好的方法。但是，这会降低代码的执行速度，因为封送拆收器要将 .NET 字符串从 Unicode 转换为多字节，然后调用函数的 A 版本（将字符串转换回 Unicode），最后调用函数的 W 版本。

要避免出现这种情况，您需要告诉封送拆收器，要它在 Win9x 平台上时查找 A 版本，而在 NT 平台上时查找 W 版本。要实现这一目的，可以将 CharSet 设置为 DllImport 属性的一部分：

[DllImport("kernel32.dll", CharSet = CharSet.Auto)]

在我的非正式计时测试中，我发现这一做法比前一种方法快了大约百分之五。

对于大多数 Win32 API，都可以对字符串类型设置 CharSet 属性并使用 LPTStr。但是，还有一些不采用 A/W 机制的函数，对于这些函数必须采取不同的方法。

字符串缓冲区

.NET 中的字符串类型是不可改变的类型，这意味着它的值将永远保持不变。对于要将字符串值复制到字符串缓冲区的函数，字符串将无效。这样做至少会破坏由封送拆收器在转换字符串时创建的临时缓冲区；严重时会破坏托管堆，而这通常会导致错误的发生。无论哪种情况都不可能获得正确的返回值。

要解决此问题，我们需要使用其他类型。StringBuilder 类型就是被设计为用作缓冲区的，我们将使用它来代替字符串。下面是一个示例：

[DllImport("kernel32.dll", CharSet = CharSet.Auto)]public static extern int GetShortPathName(   [MarshalAs(UnmanagedType.LPTStr)]   string path,   [MarshalAs(UnmanagedType.LPTStr)]   StringBuilder shortPath,   int shortPathLength);

使用此函数很简单：

StringBuilder shortPath = new StringBuilder(80);int result = GetShortPathName(@"d:	est.jpg", shortPath, shortPath.Capacity);string s = shortPath.ToString();

请注意，StringBuilder 的 Capacity 传递的是缓冲区大小。

简单字符串

下面是一个接受字符串参数的函数的简单示例：

BOOL GetDiskFreeSpace(  LPCTSTR lpRootPathName,          // 根路径  LPDWORD lpSectorsPerCluster,     // 每个簇的扇区数  LPDWORD lpBytesPerSector,        // 每个扇区的字节数  LPDWORD lpNumberOfFreeClusters,  // 可用的扇区数  LPDWORD lpTotalNumberOfClusters  // 扇区总数);

根路径定义为 LPCTSTR。这是独立于平台的字符串指针。

由于不存在名为 GetDiskFreeSpace() 的函数，封送拆收器将自动查找“A”或“W”变体，并调用相应的函数。我们使用一个属性来告诉封送拆收器，API 所要求的字符串类型。

以下是该函数的完整定义，就象我开始定义的那样：

[DllImport("kernel32.dll")]static extern bool GetDiskFreeSpace(   [MarshalAs(UnmanagedType.LPTStr)]   string rootPathName,   ref int sectorsPerCluster,   ref int bytesPerSector,   ref int numberOfFreeClusters,   ref int totalNumberOfClusters);

不幸的是，当我试图运行时，该函数不能执行。问题在于，无论我们在哪个平台上，封送拆收器在默认情况下都试图查找 API 的 Ansi 版本，由于 LPTStr 意味着在 Windows NT 平台上会使用 Unicode 字符串，因此试图用 Unicode 字符串来调用 Ansi 函数就会失败。

有两种方法可以解决这个问题：一种简单的方法是删除 MarshalAs 属性。如果这样做，将始终调用该函数的 A 版本，如果在您所涉及的所有平台上都有这种版本，这是个很好的方法。但是，这会降低代码的执行速度，因为封送拆收器要将 .NET 字符串从 Unicode 转换为多字节，然后调用函数的 A 版本（将字符串转换回 Unicode），最后调用函数的 W 版本。

要避免出现这种情况，您需要告诉封送拆收器，要它在 Win9x 平台上时查找 A 版本，而在 NT 平台上时查找 W 版本。要实现这一目的，可以将 CharSet 设置为 DllImport 属性的一部分：

[DllImport("kernel32.dll", CharSet = CharSet.Auto)]

在我的非正式计时测试中，我发现这一做法比前一种方法快了大约百分之五。

对于大多数 Win32 API，都可以对字符串类型设置 CharSet 属性并使用 LPTStr。但是，还有一些不采用 A/W 机制的函数，对于这些函数必须采取不同的方法。

字符串缓冲区

.NET 中的字符串类型是不可改变的类型，这意味着它的值将永远保持不变。对于要将字符串值复制到字符串缓冲区的函数，字符串将无效。这样做至少会破坏由封送拆收器在转换字符串时创建的临时缓冲区；严重时会破坏托管堆，而这通常会导致错误的发生。无论哪种情况都不可能获得正确的返回值。

要解决此问题，我们需要使用其他类型。StringBuilder 类型就是被设计为用作缓冲区的，我们将使用它来代替字符串。下面是一个示例：

[DllImport("kernel32.dll", CharSet = CharSet.Auto)]public static extern int GetShortPathName(   [MarshalAs(UnmanagedType.LPTStr)]   string path,   [MarshalAs(UnmanagedType.LPTStr)]   StringBuilder shortPath,   int shortPathLength);

使用此函数很简单：

StringBuilder shortPath = new StringBuilder(80);int result = GetShortPathName(@"d:	est.jpg", shortPath, shortPath.Capacity);string s = shortPath.ToString();

请注意，StringBuilder 的 Capacity 传递的是缓冲区大小。

P>C# 用户经常提出两个问题：“我为什么要另外编写代码来使用内置于 Windows® 中的功能？在框架中为什么没有相应的内容可以为我完成这一任务？”当框架小组构建他们的 .NET 部分时，他们评估了为使 .NET 程序员可以使用 Win32 而需要完成的工作，结果发现 Win32 API 集非常庞大。他们没有足够的资源为所有 Win32 API 编写托管接口、加以测试并编写文档，因此只能优先处理最重要的部分。许多常用操作都有托管接口，但是还有许多完整的 Win32 部分没有托管接口。

平台调用 (P/Invoke) 是完成这一任务的最常用方法。要使用 P/Invoke，您可以编写一个描述如何调用函数的原型，然后运行时将使用此信息进行调用。另一种方法是使用 Managed Extensions to C++ 来包装函数，这部分内容将在以后的专栏中介绍。

要理解如何完成这一任务，最好的办法是通过示例。在某些示例中，我只给出了部分代码；完整的代码可以通过下载获得。

简单示例

在第一个示例中，我们将调用 Beep() API 来发出声音。首先，我需要为 Beep() 编写适当的定义。查看 MSDN 中的定义，我发现它具有以下原型：

BOOL Beep(  DWORD dwFreq,      // 声音频率  DWORD dwDuration   // 声音持续时间);

要用 C# 来编写这一原型，需要将 Win32 类型转换成相应的 C# 类型。由于 DWORD 是 4 字节的整数，因此我们可以使用 int 或 uint 作为 C# 对应类型。由于 int 是 CLS 兼容类型（可以用于所有 .NET 语言），以此比 uint 更常用，并且在多数情况下，它们之间的区别并不重要。bool 类型与 BOOL 对应。现在我们可以用 C# 编写以下原型：

public static extern bool Beep(int frequency, int duration);

这是相当标准的定义，只不过我们使用了 extern 来指明该函数的实际代码在别处。此原型将告诉运行时如何调用函数；现在我们需要告诉它在何处找到该函数。

我们需要回顾一下 MSDN 中的代码。在参考信息中，我们发现 Beep() 是在 kernel32.lib 中定义的。这意味着运行时代码包含在 kernel32.dll 中。我们在原型中添加 DllImport 属性将这一信息告诉运行时：

[DllImport("kernel32.dll")]

这就是我们要做的全部工作。下面是一个完整的示例，它生成的随机声音在二十世纪六十年代的科幻电影中很常见。

using System;using System.Runtime.InteropServices;namespace Beep{   class Class1   {      [DllImport("kernel32.dll")]      public static extern bool Beep(int frequency, int duration);      static void Main(string[] args)      {         Random random = new Random();         for (int i = 0; i < 10000; i++)         {            Beep(random.Next(10000), 100);         }      }   }}

它的声响足以刺激任何听者！由于 DllImport 允许您调用 Win32 中的任何代码，因此就有可能调用恶意代码。所以您必须是完全受信任的用户，运行时才能进行 P/Invoke 调用。

枚举和常量

Beep() 可用于发出任意声音，但有时我们希望发出特定类型的声音，因此我们改用 MessageBeep()。MSDN 给出了以下原型：

BOOL MessageBeep(  UINT uType   // 声音类型);

这看起来很简单，但是从注释中可以发现两个有趣的事实。

首先，uType 参数实际上接受一组预先定义的常量。

其次，可能的参数值包括 -1，这意味着尽管它被定义为 uint 类型，但 int 会更加适合。

对于 uType 参数，使用 enum 类型是合乎情理的。MSDN 列出了已命名的常量，但没有就具体值给出任何提示。由于这一点，我们需要查看实际的 API。

如果您安装了 Visual Studio® 和 C++，则 Platform SDK 位于 Program FilesMicrosoft Visual Studio .NETVc7PlatformSDKInclude 下。

为查找这些常量，我在该目录中执行了一个 findstr。

findstr "MB_ICONHAND" *.h

它确定了常量位于 winuser.h 中，然后我使用这些常量来创建我的 enum 和原型：

public enum BeepType{   SimpleBeep = -1,   IconAsterisk = 0x00000040,   IconExclamation = 0x00000030,   IconHand = 0x00000010,   IconQuestion = 0x00000020,   Ok = 0x00000000,}[DllImport("user32.dll")]public static extern bool MessageBeep(BeepType beepType);

现在我可以用下面的语句来调用它：

MessageBeep(BeepType.IconQuestion); 

处理结构

有时我需要确定我笔记本的电池状况。Win32 为此提供了电源管理函数。

搜索 MSDN 可以找到 GetSystemPowerStatus() 函数。

BOOL GetSystemPowerStatus(  LPSYSTEM_POWER_STATUS lpSystemPowerStatus);

此函数包含指向某个结构的指针，我们尚未对此进行过处理。要处理结构，我们需要用 C# 定义结构。我们从非托管的定义开始：

typedef struct _SYSTEM_POWER_STATUS {  BYTE   ACLineStatus;           BYTE   BatteryFlag;            BYTE   BatteryLifePercent;     BYTE   Reserved1;              DWORD  BatteryLifeTime;        DWORD  BatteryFullLifeTime;  } SYSTEM_POWER_STATUS, *LPSYSTEM_POWER_STATUS;

然后，通过用 C# 类型代替 C 类型来得到 C# 版本。

struct SystemPowerStatus{   byte ACLineStatus;   byte batteryFlag;   byte batteryLifePercent;   byte reserved1;   int  batteryLifeTime;   int  batteryFullLifeTime;}

这样，就可以方便地编写出 C# 原型：

[DllImport("kernel32.dll")]public static extern bool GetSystemPowerStatus(   ref SystemPowerStatus systemPowerStatus);

在此原型中，我们用“ref”指明将传递结构指针而不是结构值。这是处理通过指针传递的结构的一般方法。

此函数运行良好，但是最好将 ACLineStatus 和 batteryFlag 字段定义为 enum：

   enum ACLineStatus: byte    {      Offline = 0,      Online = 1,      Unknown = 255,   }   enum BatteryFlag: byte   {      High = 1,      Low = 2,      Critical = 4,      Charging = 8,      NoSystemBattery = 128,      Unknown = 255,   }

请注意，由于结构的字段是一些字节，因此我们使用 byte 作为该 enum 的基本类型。

字符串

虽然只有一种 .NET 字符串类型，但这种字符串类型在非托管应用中却有几项独特之处。可以使用具有内嵌字符数组的字符指针和结构，其中每个数组都需要正确的封送处理。

在 Win32 中还有两种不同的字符串表示：

• ANSI
• Unicode

最初的 Windows 使用单字节字符，这样可以节省存储空间，但在处理很多语言时都需要复杂的多字节编码。Windows NT® 出现后，它使用双字节的 Unicode 编码。为解决这一差别，Win32 API 采用了非常聪明的做法。它定义了 TCHAR 类型，该类型在 Win9x 平台上是单字节字符，在 WinNT 平台上是双字节 Unicode 字符。对于每个接受字符串或结构（其中包含字符数据）的函数，Win32 API 均定义了该结构的两种版本，用 A 后缀指明 Ansi 编码，用 W 指明 wide 编码（即 Unicode）。如果您将 C++ 程序编译为单字节，会获得 A 变体，如果编译为 Unicode，则获得 W 变体。Win9x 平台包含 Ansi 版本，而 WinNT 平台则包含 W 版本。

由于 P/Invoke 的设计者不想让您为所在的平台操心，因此他们提供了内置的支持来自动使用 A 或 W 版本。如果您调用的函数不存在，互操作层将为您查找并使用 A 或 W 版本。

通过示例能够很好地说明字符串支持的一些精妙之处。

C#的功能十分强大，用它可以轻松地做出属于自己的文件浏览器。下面简单地介绍一下文件浏览器的大致实现过程。其中涉及的有关这些控件的具体用法可参见C#的联机帮助。

　　你需要用到几个控件：

　　　TreeView(用于显示显示目录树)；

　　　ListView(用于显示文件和目录列表)；

　　　Splitter(用于允许用户调整TreeView和ListView的大小)；

　　　其它的如：MainMenu，ToolBar，StatusBar，ImageList等等就看你的实际需要了。

　　首先，新建一个C#项目(Windows应用程序)，命名为MyFileView，将窗口命名为mainForm，调整主窗口大小(Size)。添加MainMenu，ToolBar，StatusBar，ImageList等控件。

　　然后，添加TreeView控件，命名为treeView，Dock属性设为Left，再添加Splitter控件，同样将Dock属性设为Left。最后添加ListView控件，命名为listView，Dock属性设为Fill。如下图所示。

　　 界面做好了，那么怎样才能在这个界面里显示文件夹和文件呢？这需要我们添加代码来实现。

　　首先引用以下名字空间：

using System; using System.Drawing; using System.Collections; using System.ComponentModel; using System.Windows.Forms; using System.Data; using System.IO ; using System .Runtime .InteropServices ; 在mainForm_Load事件中添加以下代码，用于在treeView控件中显示目录树： private void mainForm_Load(object sender, System.EventArgs e) //获取逻辑驱动器 string[] LogicDrives=System.IO .Directory .GetLogicalDrives(); TreeNode[] cRoot =new TreeNode[LogicDrives.Length]; for (int i=0;i< LogicDrives.Length ;i++) { 　TreeNode drivesNode=new TreeNode(LogicDrives[i]); 　treeView.Nodes .Add (drivesNode); 　if (LogicDrives[i]!="A:\" && LogicDrives[i]!="B:\" ) 　　getSubNode(drivesNode,true); } }

　　其中，getSubNode为一方法，用于获取子目录，以创建目录树节点，参数：PathName为获取的子目录在此节点下创建子节点，参数isEnd：结束标志,true则结束。

private void getSubNode(TreeNode PathName,bool isEnd) { 　if(!isEnd) 　　return; //exit this 　　TreeNode curNode; 　　DirectoryInfo[] subDir; 　　DirectoryInfo curDir=new DirectoryInfo (PathName.FullPath); 　　try 　　{ 　　　subDir=curDir.GetDirectories(); 　　} 　　catch{} 　　　foreach(DirectoryInfo d in subDir) 　　　{ 　　　　curNode=new TreeNode(d.Name); 　　　　PathName.Nodes .Add (curNode); 　　　　getSubNode(curNode,false); 　　　} }

　　当鼠标单击目录节点左边的+号时，节点将展开，此时，应在AfterExpand事件中加入以下代码，以获取此目录下的子目录节点：

private void treeView_AfterExpand(object sender, System.Windows.Forms.TreeViewEventArgs e) { 　try 　{ 　　foreach(TreeNode tn in e.Node .Nodes ) 　　{ 　　　if (!tn.IsExpanded) 　　　　getSubNode(tn,true); 　　　} 　　} 　catch{;} }

　　当鼠标单击选中目录节点时，右边的listView控件应显示此目录下的文件和目录，代码如下：

private void treeView_AfterSelect(object sender,System.Windows.Forms.TreeViewEventArgs e) { 　listView.Items.Clear(); 　DirectoryInfo selDir=new DirectoryInfo(e.Node.FullPath ); 　DirectoryInfo[] listDir; 　FileInfo[] listFile; 　try 　{ 　　listDir=selDir.GetDirectories(); 　　listFile=selDir.GetFiles(); 　} 　catch{} 　foreach (DirectoryInfo d in listDir) 　　listView.Items .Add (d.Name,6); 　foreach (FileInfo d in listFile) 　　listView.Items .Add (d.Name); }

　　至此，一个简单的文件浏览器就做成了，当然，它还很初级，甚至不能用它打开一个文件，加另外，它也不能显示文件和目录的图标，没有进行错误处理，没有进行安全控制……它能给你的只是一个思路。

 查看全文

请不要将template方法写为虚方法，因为这将给最终用户修改template方法的能力从而改变了整个框架的基础。也就是说这仅是框架开发都需要完成的任务，最终用户要做的就是从框架基类继承并重写这些在框架中定义的抽象类以实现自己定制的功能。

// 从基类继承 class MyClass : AppFramework { 　 // 将抽象方法重写以实现定制的功能 　 override public void init() 　 { 　　 Console.WriteLine("MyClass::init"); 　 } 　 override public void run() 　 { 　　 Console.WriteLine("MyClass::run"); 　 } 　 override public void destroy() 　 { 　　 Console.WriteLine("MyClass::destroy"); 　 } 　 // the main method defined 　 public static void Main(String [] arg) 　 { 　　 MyClass myClass = new MyClass(); 　 } }

　　 尽管Main()函数与这些重写的函授放在一个类中是可行的，但最好是放在一个单独的类中。下面是全部的代码.

＜code＞ using System; abstract class AppFramework { 　 public AppFramework() 　 { 　　 templateMethod(); 　 } 　 public abstract void init(); 　 public abstract void run(); 　 public abstract void destroy(); 　 private void templateMethod() 　 { 　　 Console.WriteLine("Initializing Template Engine"); 　　 init(); 　　 run(); 　　 destroy(); 　　 Console.WriteLine("Ending Template Engine"); 　 } } class MyClass : AppFramework { 　 override public void init() 　 { 　　 Console.WriteLine("MyClass::init"); 　 } 　 override public void run() 　 { 　　 Console.WriteLine("MyClass::run"); 　 } 　 override public void destroy() 　 { 　　 Console.WriteLine("MyClass::destroy"); 　 } 　 public static void Main(String [] arg) 　 { 　　 MyClass myClass = new MyClass(); 　 } } ＜code＞

简介:
　　 框架是一种定制的通用的应用程序开发基础软件，在其基础上可以开发完整的关且功能完善的软件。在最近几年里，已经成功实现了某些应用领域的开发框架,比如说用户介面开发及数据访问开发等。如果能成功的开发出一个框架，这将是一个突破，因为这意味着开发将不再从头开始实现某个功能：比如一个框架如果可以成功的生成一个用户介面，哪么它也能生成做任意的用户介面。例如，假如我们使用java Applets 和servlets，我们仅仅需要重写某些方法，就可以实现我们自己的代码。这其中java Applets和servlets就是我们所使用的框架平台。Microsoft也实现了MFC类库存，还有本文涉及的.net Framework (当然还用Borland的vcl)。

先决条件：

　　 本文的读者应该有c#的使用经验，或者对java applet 和 servlet有基础的了解，以便可以理解本文所涉及的一些基本概念。

工具:

　　 本文所写代码在windows 2000+.net Framework 发行版下测试。因为本文不需要图形介面，所以我使用写字板及c#命令行编译器实现。

正文:

　　 在下面，你将看到如何实现一个应用程序框架模型的基础构造。开发应用框架时的基本核心就是template方法，它被隐藏在应用程序里面，控制应用程序的运行。它只在基类里面实现并且不能被改变。

　　 第一步就是构建框架的基类。在构建框架时基类是最重要的类。

　　 它里面有可以被重写的方法，最终用户可以重写这些方法以实现他们自己的应用程序。除了这些，这里还有一个template方法用于在框架进程中控制。我们将要构建的框架包括三个需要最终用户实现的抽象方法。他们是init,run和destroy.,它们必须要顺序实现。下面就是我们实现的代码：

// 这个类之所以被定义为抽象类，是因为用户方法还没有被实现 abstract class AppFramework { 　 // 构造器调用template方法 　 public AppFramework() 　 { 　　 templateMethod(); 　 } 　 // 下面的方法需要最终用户实现 　 public abstract void init(); 　 public abstract void run(); 　 public abstract void destroy(); 　 //template方法是框架的核心 　 private void templateMethod() 　 { 　　 Console.WriteLine("Initializing Template Engine"); 　　 // template 方法顺序调用所需要的方法 　　 init(); 　　 run(); 　　 destroy(); 　　 Console.WriteLine("Ending Template Engine"); 　 } }

反射(Reflection)

　　 在一个插件定义好之后,下一步要做的就是查看主程序是怎么加载插件的.为了实现这个目标,主程序使用了反射机制.反射是.NET中用于运行时查看类型信息的.在反射机制的帮助下,类型信息将被加载和查看.这样就可以通过检查这个类型以判断插件是否有效.如果类型通过了检查,那么插件就可以被添加到主程序的界面中,就可以被用户操作.

　　 示例程序使用了.NET框架的三个内置类来使用反射:System.Reflection.Assembly,System.Type,和System.Activator.

　　 System.Reflection.Assembly类描述了.NET的程序集.在.NET中,程序集是配置单元.对于一个典型的Windows程序,程序集被配置为单一的Win32可执行文件,并且带有特定的附加信息,使之适应.NET运行环境.程序集也可以配置为Win32的DLL(动态链接库),同样需要带有.NET需要的附加信息.System.Reflection.Assembly类可以在运行的时候取得程序集的信息.这些信息包括程序集包含的类型信息.

　　 System.Type类描述了类型定义.一个类型声明可以是一个类,接口,数组,结构体,或者枚举.在加载了一个类之后,System.Type类可以被用于枚举该类支持的方法,属性,事件和接口.

　　 System.Activator类用于创建一个类的实例.

　　 加载插件

　　 列表四展示了LoadPlugs方法.LoadPlugs方法在HostForm.cs中定义,是HostForm类的一个private的非静态方法.LoadPlugs方法使用.NET的反射机制来加载可用的插件文件,并且验证它们是否符合被主程序使用的要求,然后把它们添加到主程序的树形显示区中.这个方法包含了下面几个步骤:

　　 1.通过使用System.IO.Directory类,我们的代码可以用通配符来查找所有的以.plug为扩展名的文件.而Directory类的静态方法GetFiles能够返回一个System.String类型的数组,以得到每个符合要求的文件的物理路径.

　　 2.在得到路径字符串数组之后,就可以开始把文件加载到System.Reflection.Assembly实例中了.建立Asdsembly对象的代码使用了try/catch代码块,这样如果某个文件并不是一个有效地.NET程序集,就会抛出异常,程序此时将弹出一个MessageBox对话框,告诉用户无法加载该文件.循环一直进行直到所有文件都已遍历完成.

　　 3.在一个程序集加载之后,代码将遍历所有可访问到的类型信息,检查是否支持了HostCommon.IPlug接口.

　　 4.如果所有类型都支持HostCommon.IPlug接口,那么代码继续验证这些类型,检查是否支持那些已预先为插件定义好的属性.如果没有支持,那么一个HostCommon.PlugNotValidException类型的异常将会被抛出,同样,主程序将会弹出一个MessageBox,告诉用户出错的具体信息.循环一直进行直到所有文件都已遍历完成.

　　 5.最后,如果这些类型支持HostCommon.IPlug接口,也已定义了所有需要定义的属性,那么它将被包装为一个PlugTreeNode实例.这个实例就会被添加到主程序的树形显示区.

　　 实现

　　 主程序框架被设计为两个程序集.第一个程序集是Host.exe,它提供了主程序的Windows窗体界面.第二个程序集是HostCommon.dll,它提供了主程序和插件之间进行通信所需的所有类型定义.比如,IPlug接口就是在HostCommon.dll里面配置的,这样它可以被主程序和插件等价的访问.这两个程序集在一个文件夹内,同样的,附加的作为插件的程序集也需要被配置在一起.那些程序集被配置在plugs文件夹内(主程序目录的一个子文件夹).EmployeePlug类在Employee.plug程序集中定义,而CustomerPlug类在Customer.plug程序集中定义.这个例子指定插件文件以.plug为扩展名.事实上这些插件就是个普通的.NET类库文件,只是通常库文件使用.dll扩展名,这里用.plug罢了.特殊的扩展名对于程序运行是完全没有影响的,但是它可以让用户更明确的知道这是个插件文件.

　　 设计的比较

　　 并不是一定要像例子程序这样设计才算正确的.比如,在开发一个带有插件的C#程序时,并不一定需要使用属性.例子里使用了两个自定义的属性,其实也可以新定义两个IPlug接口的参数来实现.这里选择用属性,是因为插件的名字和它的描述在本质上确实就是一个事物的属性,符合规范.当然了,使用属性会造成主程序需要更多的关于反射的代码.对于不同的需求,设计者总是需要做出合理的决定.

　　 总结

　　 示例程序被设计为尽量的简单,以帮助理解主程序和插件之间的通信.在实际做产品的时候,可以做很多的改进以满足实用要求.比如:

　　 1.通过对IPlug接口增加更多的方法,属性,事件,可以增加主程序和插件之间的通信点.两者间的更多的交互操作使得插件可以做更多的事情.

　　 2.可以允许用户主动选择需要加载的插件.
　　 源代码

　　 示例程序的完整的源代码可以在这里下载.

ftp://ftp.cuj.com/pub/2003/2101/walchesk.zip

　　 图片一:


　　 列表一:The IPlug interface

public interface IPlug { IPlugData[] GetData(); PlugDataEditControl GetEditControl(IPlugData Data); bool Save(string Path); bool Print(PrintDocument Document); }

　　列表二:The PlugDisplayNameAttribute class definition

[AttributeUsage(AttributeTargets.Class)] public class PlugDisplayNameAttribute : System.Attribute { private string _displayName; public PlugDisplayNameAttribute(string DisplayName) : base() { _displayName=DisplayName; return; } public override string ToString() { return _displayName; }

　　列表三:A partial listing of the EmployeePlug class definition

[PlugDisplayName("Employees")] [PlugDescription("This plug is for managing employee data")] public class EmployeePlug : System.Object, IPlug { public IPlugData[] GetData() { IPlugData[] data = new EmployeeData[] { new EmployeeData("Jerry", "Seinfeld") ,new EmployeeData("Bill", "Cosby") ,new EmployeeData("Martin", "Lawrence") }; return data; } public PlugDataEditControl GetEditControl(IPlugData Data) { return new EmployeeControl((EmployeeData)Data); } public bool Save(string Path) { //implementation not shown } public bool Print(PrintDocument Document) { //implementation not shown } }

　　列表四:The method LoadPlugs

private void LoadPlugs() { string[] files = Directory.GetFiles("Plugs", "*.plug"); foreach(string f in files) { try { Assembly a = Assembly.LoadFrom(f); System.Type[] types = a.GetTypes(); foreach(System.Type type in types) { if(type.GetInterface("IPlug")!=null) { if(type.GetCustomAttributes(typeof(PlugDisplayNameAttribute), false).Length!=1) throw new PlugNotValidException(type, "PlugDisplayNameAttribute is not supported"); if(type.GetCustomAttributes(typeof(PlugDescriptionAttribute), false).Length!=1) throw new PlugNotValidException(type, "PlugDescriptionAttribute is not supported"); _tree.Nodes.Add(new PlugTreeNode(type)); } } } catch(Exception e) { MessageBox.Show(e.Message); } } return; }