2.8 简单管理控制（配置）

　　用户或管理员经常需要对应用程序执行时的一些方面进行控制。例如，管理员可能决定移动用户硬盘上的程序集文件，或者覆盖程序集清单中的一些信息。还有一些策略设计版本控制，详情请参见第3章。

　　为了实现对一个应用程序的管理控制，可在应用程序目录中放入一个配置文件。应用程序的发布者可创建并打包这个文件。这样一来，安装程序会将配置文件安装到应用程序的基目录中。另外，计算机管理员或最终用户也能创建或修改该文件。CLR会解析该文件的内容，从而更改程序集文件的定位和加载策略。

　　配置文件包含的是XML代码，它既能和某个应用程序关联，也能和整个机器关联。通过使用一个单独的文件（而不是注册表设置），用户可以方便地备份文件，管理员也能将应用程序方便地复制到另一台机器--只需复制必要的文件，管理策略就会被复制过去。

　　第3章将进一步更详细探讨这个配置文件，目前只需对它有一个基本的认识。例如，假定一个应用程序的发布者希望将JeffTypes程序集文件部署到与应用程序的程序集文件不同的目录中。要求的目录结构如下：

　　AppDir目录（包含应用程序的程序集文件）

　　　　Program.exe

　　　　Program.exe.config（在下面讨论）

　　　　AuxFiles子目录（包含JeffTypes的程序集文件）

　　　　　　JeffTypes.dll

　　　　　　FUT.netmodule

　　　　　　RUT.netmodule

　　由于JeffTypes这个程序集的文件不在应用程序的基目录中，所以CLR无法定位并加载这些文件。运行这个应用程序，会抛出一个System.IO.FileNotFoundException异常。为了解决这个问题，发布者创建了一个XML格式的配置文件，并把它部署到应用程序的基目录。该文件的名称必须是应用程序的主程序集文件的名称，并附加一个.config扩展名，也就是Program.exe.config。配置文件内容如下：

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="AuxFiles"/>
    </assemblyBinding>
  </runtime>
</configuration>

　　CLR尝试定位一个程序集文件时，总是先在应用程序基目录中查找。如果没有找到，就查找AuxFiles子目录。可以为probing元素的privatePath attribute指定多个以分号分隔的路径。每个路径都相对于应用程序的基目录。不能指定一个绝对或相对路径来表示应用程序基目录外部的一个目录。这个设计的出发点是应用程序能控制它的目录及其子目录，但不能控制其他目录。

探测程序集文件

　　CLR需要定位一个程序集时，会扫描几个子目录。以下是加载一个语言文化中性的程序集时的目录探测顺序（其中，firstPrivatePath和secondPrivatePath是通过配置文件的privatePath attribute来指定的）：

　　AppDir\AsmName.dll

　　AppDir\AsmName\AsmName.dll

　　AppDir\firstPrivatePath\AsmName.dll

　　AppDir\firstPrivatePath\AsmName\AsmName.dll

　　AppDir\secondPrivatePath\AsmName.dll

　　AppDir\secondPrivatePath\AsmName\AsmName.dll

　　...

　　在这个例子中，如果JeffTypes.dll程序集的文件部署到一个名为JeffTypes的子目录中，就不需要配置文件，因为CLR能自动扫描 与目标程序集的名称相符的一个子目录。

　　如果没有在上述任何一个子目录中找到目标程序集，CLR会从头再来，用一个.exe扩展名替换.dll扩展名。如果仍然找不到程序集，就抛出FileNotFoundException异常。

　　附属程序集（satellite assembly）遵循类似的规则，只是CLR会在应用程序基目录下的一个子目录中查找它，子目录的名称与语言文化的名称相符。例如，假定向AsmName.dll应用了“en-US”语言文化，那么会探测以下目录：　　

　　AppDir\en-US\AsmName.dll

　　AppDir\en-US\AsmName\AsmName.dll

　　AppDir\firstPrivatePath\en-US\AsmName.dll

　　AppDir\firstPrivatePath\en-US\AsmName\AsmName.dll

　　AppDir\secondPrivatePath\en-US\AsmName.dll

　　AppDir\secondPrivatePath\en-US\AsmName\AsmName.dll

　　AppDir\en-US\AsmName.exe

　　AppDir\en-US\AsmName\AsmName.exe

　　AppDir\firstPrivatePath\en-US\AsmName.exe

　　AppDir\firstPrivatePath\en-US\AsmName\AsmName.exe

　　AppDir\secondPrivatePath\en-US\AsmName.exe

　　AppDir\secondPrivatePath\en-US\AsmName\AsmName.exe

　　AppDir\en\AsmName.dll

　　AppDir\en\AsmName\AsmName.dll

　　AppDir\firstPrivatePath\en\AsmName.dll

　　AppDir\firstPrivatePath\en\AsmName\AsmName.dll

　　AppDir\secondPrivatePath\en\AsmName.dll

　　AppDir\secondPrivatePath\en\AsmName\AsmName.dll

　　AppDir\en\AsmName.exe

　　AppDir\en\AsmName\AsmName.exe

　　AppDir\firstPrivatePath\en\AsmName.exe

　　AppDir\firstPrivatePath\en\AsmName\AsmName.exe

　　AppDir\secondPrivatePath\en\AsmName.exe

　　AppDir\secondPrivatePath\en\AsmName\AsmName.exe

　　如你所见，CLR会探测具有.exe或.dll扩展名的文件。由于这个探测过程可能非常耗时（尤其是CLR需要通过网络来查找文件的时候），所以在XML配置文件中，最好指定一个或者多个culture元素，对CLR查找附属程序集的探测过程进行限制。

　　这个XML配置文件的名称和位置要取决于应用程序的类型：

　　对于可执行应用程序（EXE），配置文件必须在应用程序的基目录中，而且必须采用EXE文件的全名为文件名，在附加一个.config扩展名。

　　对于Microsoft ASP.NET Web窗体应用程序，文件必须在Web应用程序的虚拟根目录中，而且总是命名为Web.config。除此之外，子目录也可包含自己的Web.config文件，而且配置设置会得以继承。例如，位于http://Wintellect.com/Training的Web应用程序既会使用虚拟根目录中的Web.config设置，也会使用Training子目录自己的Web.config设置。

　　本节开头说过，配置设置可应用于某个程序或整个机器。安装.NET Framework时，它会创建Machine.config文件。机器上安装的每个版本的CLR都有一个对应的Machine.config文件。Machine.config文件位于以下目录：

　　%SystemRoot%\Microsoft.NET\Framework\version\CONFIG

　　其中，%SystemRoot%是Windows目录（一般是C:\Windows），version是.NET Framework的具体版本号（形如v4.0.#####）。

　　Machine.config文件中的设置是机器上运行的所有应用程序的默认设置，优先于应用程序专用配置文件中的设置。所以，管理员为了创建一个适用于整台机器的策略，修改一个文件即可。然而，管理员和用户一般应该避免修改Machine.config文件，因为该文件的许多设置都有着太多的牵连，使我们难免顾此失彼。另外，我们经常都要对应用程序的设置进行备份和还原，只有将这些设置保存到应用程序专用的配置文件中，才能方便地做到这一点。

　　更多管理控制（配置），请参见3.9节