AppDomain 和动态加载

　　在这个图表中，Loader 类创建一个名为 Functions 的新 AppDomain。创建 AppDomain 之后，Loader 在新的 AppDomain 中创建 RemoteLoader 的实例。

　　要加载程序集，请在 RemoteLoader 上调用加载函数。该函数打开新的程序集，找到程序集中的所有函数，将函数打包到 FunctionList 对象中，然后将该对象返回到 Loader。然后，就可以通过 Graph 函数使用此 FunctionList 中的 Function 对象。

　　第一项任务是创建 AppDomain。要以正确的方式创建 AppDomain，我们需要向 AppDomain 传递一个 AppDomainSetup 对象。一旦您理解了这一切的工作原理，关于这些的文档就足够使用了，但是如果您正在试图理解其工作原理，那么这些文档的帮助并不大。当关于该主题的 Google 搜索将上个月的专栏作为较高的匹配之一返回时，我怀疑我可能有点麻烦了。

　　必须处理的基本问题是如何在运行时加载程序集。默认情况下，运行时将查看全局程序集缓存或当前应用程序目录树。而我们希望从完全不同的目录中加载我们的外接程序。

　　当您查看 AppDomainSetup 的文档时，您将发现可以把 ApplicationBase 属性设置为要搜索程序集的目录。然而，我们也需要参考原始的程序目录，因为那是 RemoteLoader 类存在的地方。

　　AppDomain 的创作者们理解这一点，因此他们已经提供了额外的位置，用于从中搜索程序集。我们将使用 ApplicationBase 引用外接程序目录，然后将 PrivateBinPath 设置为指向主应用程序目录。

　　下面是来自 Loader 类的代码，可实现此功能：

　　创建 AppDomain 之后，使用 CreateInstanceFromAndUnwrap() 函数在新的应用程序域中创建 RemoteLoader 类的实例。请注意，需要使用类所在的程序集的文件名以及类的全名。

　　当执行此调用时，我们返回如同 RemoteLoader 一样的实例。实际上，它是一个小型代理类，将所有调用转发到其他 AppDomain 中的 RemoteLoader 实例中。这和 .NET Remoting 使用的是同一种结构。

　　当您编写代码实现此功能时，您会产生错误。本文档对如何调试应用程序并未提供什么建议，但是如果您知道该向谁询问，他们将告诉您有关程序集绑定日志查看器（名为“fuslogvw.exe”，因为加载子系统称为“fusion”）的信息。运行查看器时，您可以要求它记录故障，然后当您运行的应用程序出现加载程序集的问题时，您可以刷新查看器，获得当前情况的详细信息。

　　例如，您会发现 Assembly.Load() 的文件名末尾不需要 .dll，这一点非常有用。您可以从日志中获知这一点，因为它将告诉您它曾试图加载 f.dll.dll。

　　因此，既然我们已经创建了应用程序域，下一步应该搞清楚如何加载组件并从中提取函数。这需要两段相互独立的代码。第一段代码在目录中查找文件，然后加载找到的每个文件：

　　Graph 类中的函数在外接程序目录中查找所有的 dll 文件，删除它们的扩展名，然后告诉加载程序加载它们。返回的函数列表将并入当前的函数列表。

　　第二段代码在 RemoteLoader 类中，它实际加载程序集并查找函数：

　　这段代码只是对传入的文件名（实际是程序集名称）调用 Assembly.Load()，然后将所有有用的函数加载到 FunctionList 实例中返回给调用程序。

　　此时，应用程序可以启动，加载外接程序程序集，然后用户就可以引用它们。

　　下一项任务是能够按照需要重新加载这些程序集。最终，我们希望能够自动实现该任务，但是出于测试目的，我将 Reload 按钮添加到窗体中，以使程序集能够重新加载。该按钮的处理程序仅调用 Graph.Reload()，它需要执行以下操作：

1. 卸载 AppDomain。
2. 创建新的 AppDomain。
3. 在新的 AppDomain 中重新加载程序集。
4. 将图形线条挂钩到新创建的 AppDomain。

　　步骤 4 是必需的，因为 GraphLine 对象包含来自原 AppDomain 的 Function 对象。卸载 AppDomain 后，函数对象无法再被使用。

　　为解决此问题，HookupFunctions() 修改了 GraphLine 对象，使它们从当前应用程序域指向正确的函数。

　　代码如下：

　　只要执行重新加载操作，最后两行将引发一个事件。其作用是更新窗体上的重新加载计数器。

　　下一步是能够检测在外接程序目录中显示的新的或修改过的程序集。该框架提供 FileSystemWatcher 类来实现此功能。下面是我添加到 Graph 类构造函数中的代码：

　　当创建 FileSystemWatcher 类时，我们告诉它要在什么目录中查找，要跟踪哪些文件。EnableRaisingEvents 属性表示当它检测到更改时，我们是否需要它发送事件。最后 3 行将事件挂钩到类中的某个函数。该函数仅仅调用 Reload() 以重新加载程序集。

　　这种方法有一些累赘的地方。在更新程序集时，我们必须卸载程序集才能够加载新的版本，但是添加或删除文件时不需要卸载程序集。在这种情况下，对所有更改执行此操作的成本并不是很高，而且它使代码更简单。

　　在构造此代码之后，我们运行该应用程序，然后尝试把新的程序集复制到外接程序目录中。正如我们所希望的那样，我们获得了文件更改事件，当重新加载完毕时，新的函数就可供使用。

　　然而，当我们试图更新现有的程序集时，我们遇到了一个问题。运行时已经锁定该文件，这意味着我们无法将新的程序集复制到外接程序目录中，我们收到一个错误。

　　AppDomain 类的设计人员意识到这是一个问题，因此他们提供一种不错的解决方法。当 ShadowCopyFiles 属性设置为 true（字符串 true，不是布尔常数 true。不要问我为什么……）时，运行时将把程序集复制到缓存目录中，然后打开该程序集。这样，原文件就不会被锁定，我们也就能更新正在使用的程序集。ASP.NET 使用了这种机制。

　　为了启用此功能，我在 Loader 类的构造函数中添加了以下行：

　　然后我重新生成了该应用程序，并得到相同的错误。我查看了 ShadowCopyDirectories 属性的文档，该文档明确指出 PrivateBinPath 指定的所有目录（包括 ApplicationBase 指定的目录）是阴影复制的（如果未设置此属性）。记得我是如何说该文档在这个方面不是很好的吗？

　　有关此属性的文档肯定是错了。我没有验证确切的表现方式，但是我可以告诉您 ApplicationBase 目录中的文件在默认情况下并不是阴影复制的。明确指定目录可以解决此问题：

　　搞明白这一点至少花了我半个小时。

　　现在我们可以更新现有文件并将其正确地加载进去。可我刚把这个理顺，又遇到了另外一个小的问题。当我们从窗体的按钮上运行重新加载函数时，重新加载总是和绘制发生在同一个线程中，这意味着在重新加载过程中我们不可能尝试绘制直线。

　　既然我们已经切换到文件更改事件，那么在卸载 AppDomain 之后和加载新的 AppDomain 之前，有可能会进行绘制。如果发生这种情况，我们会得到一个异常。

　　这是传统的多线程编程问题，使用 C# lock 语句很容易处理。我在绘图函数和重新加载函数中添加了 lock 语句，这就确保了它们不会同时发生。这就解决了该问题，添加程序集的更新版本将使程序自动切换到函数的新版本。这相当不错。

　　还有一个奇怪的现象。原来用于检测文件更改的 Win32® 函数发送的更改数量很大，因此对文件做一次更新将发送五个更改事件，程序集也将被重新加载五次。解决方法是编写更智能的、可以将这些操作组合在一起的 FileSystemWatcher，但是此版本中没有提供这种解决方法。

　　将文件复制到目录中不是很方便，因此我决定在该应用程序中添加拖放功能。实现该任务的第一步是把窗体的 AllowDrop 属性设置为 true，这将打开拖放功能。下一步，我将一个例程挂钩到 DragEnter 事件。当光标在对象上移动进行拖放操作以确定当前对象是否接受拖放时，将调用该事件。

　　在此处理程序中，我查看是否有可用的 FileDrop 数据（也就是说，文件被拖放到窗口中）。如果有，我把效果设置为“复制”，这将相应地设置光标，并且如果用户释放鼠标按钮，将发送 DragDrop 事件。该函数中的最后一行完全是出于调试目的，用于查看操作中有哪些可用信息。

　　下一项任务是为 DragDrop 事件编写处理程序：

　　此例程获得与此操作关联的数据（文件名数组），将其传递到图形函数，然后图形函数把文件复制到外接程序目录中，触发文件更改事件以便重新加载它们。

　　此时，您可以运行该应用程序，把新的程序集拖到程序上，程序将很快加载它们并保持运行。这相当不错。